It is the Windows version.
I'm currently in the process of commiting a new 0 byte file to an existing 2GB
repo and Windows task manager says that the fossil process has read >3GB of
data since I issued the commit command several minutes ago, and it's still
running.
First it read the the entire
Interesting...
I failed to mention in my post that my version of fossil was from
'trunk' sometime this afternoon, build with MSVC 2008. I also made one
minor change to fix handling for repos > 2gig (MSVC build version
only...patch was sent to drh).
Now I will have to build fossil.exe tomorrow usi
Are you using the Windows Version of fossil which Richard had build with VC?
I had a similar issue. It went away after I have switched to a fossil
version build with mingw and gcc.
You can clone the fossil repository for test. With this repository it
should work really snappy.
Chers
Hein
A
This is pretty relevant to my day today because I sat out to load test
Fossil to make sure it will be a good fit for our future projects. I
took our existing source and asset folders (so, not importing from
Perforce, just taking the current 'head') of our recent project and put
them into Fossil.
F
Switching to wal mode hasn't made any difference. There is still a huge
amount of disk read activity.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On Wed, Sep 28, 2011 at 7:06 PM, Stephan Beal wrote:
> Mainly @DRH, but anyone who happens to know...
>
> is it technically possible (without changing anything major) to initiate a
> rebuild from an HTTP request? Are there any initialization-order or
> chicken/egg problems involved with that? e.g
Mainly @DRH, but anyone who happens to know...
is it technically possible (without changing anything major) to initiate a
rebuild from an HTTP request? Are there any initialization-order or
chicken/egg problems involved with that? e.g. is it even possible to verify
the login cookie when the repo n
On Wed, Sep 28, 2011 at 8:53 AM, Dmitry Chestnykh
wrote:
> Richard wrote:
>> I already checked in a change that sets the timestamp based on the check-in
>> time. But I like your patch better (since it is simpler).
>
> Anyway, your change is better in case the are ungzip implementations that do
On 9/28/2011 1:19 PM, Stephan Beal wrote:
But from the wording it sounds like only the "fossil extra" command is
affected.
I think this used to be the case, but since some time, the ignore-glob
also affects fossil add, which is very helpful. I still type fossil add
`fossil extras` most of the
ignore-glob definitely works on directories. Putting in something like
"Debug/*" will ignore all files in the debug folder. If you want to use
something like git has, you could probably use the "versionable" settings
for that field, which allows a file with a line for each file / folder to
ignore,
On Wed, Sep 28, 2011 at 7:09 PM, Erlis Vidal wrote:
> Do fossil has a syntax to exclude all files in certain folder? Example:
> exclude all files in the
folder bin/ This option has the scenario when I want any bin/ folder to be
> excluded, or a specific folder /dev/project/files-to-be-excluded-f
Hi guys,
I'm start using fossil and at this moment I'm just playing with it. One
thing I'm doing is migrating some .git repositories and see how it goes.
With git I tend to put all files I want to keep out of the repo in the
.gitIgnore file. I see in the documentation that fossil uses a command
a
On Wed, Sep 28, 2011 at 2:53 PM, Dmitry Chestnykh
wrote:
> Anyway, your change is better in case the are ungzip implementations that
> do not handle 0 time correctly, plus we get a nice proper timestamp when
> gunzipping.
>
FWIW: +1
--
- stephan beal
http://wanderinghorse.net/home/stephan/
On Wed, 28 Sep 2011 23:40:11 +0800
Mike Buckler wrote:
> I have noticed that fossil reads the entire database file (in 1024
> byte increments) several times during the commit process, even when
> committing a single file locally with no remote server.
> While this doesn't matter for small repos
On 9/28/2011 11:40 AM, Mike Buckler wrote:
my test repo at 40 MB is border line unusable even when run from a
fast solid state disk.
I have a 1 GB repo that has some irritating lag on my netbook with 5400
RPM drive. But I regularly use 4 repos between 30 and 90 MB and they're
all quite snappy.
I have noticed that fossil reads the entire database file (in 1024 byte
increments) several times during the commit process, even when
committing a single file locally with no remote server.
While this doesn't matter for small repos (<10 MB), my test repo at 40
MB is border line unusable even w
On Wed, Sep 28, 2011 at 02:53:18PM +0200, Dmitry Chestnykh wrote:
> > I already checked in a change that sets the timestamp based on the check-in
> > time. But I like your patch better (since it is simpler).
>
> Hehe, I started writing something similar, but was scared away by many
> changes re
> I already checked in a change that sets the timestamp based on the check-in
> time. But I like your patch better (since it is simpler).
Hehe, I started writing something similar, but was scared away by many changes
required to do this, and was not sure if I the manifest time was the correct
On Wed, Sep 28, 2011 at 8:31 AM, Dmitry Chestnykh
wrote:
> > The zlib compressor adds a timestamp at the beginning. If you gunzip the
> tarballs, you'll find that they are identical.
>
>
> If I read gzip specs correctly, it allows zero timestamp:
>
> > MTIME (Modification TIME)
> > This gives the
> The zlib compressor adds a timestamp at the beginning. If you gunzip the
> tarballs, you'll find that they are identical.
If I read gzip specs correctly, it allows zero timestamp:
> MTIME (Modification TIME)
> This gives the most recent modification time of the original file being
> compre
On Wed, Sep 28, 2011 at 06:10:16AM -0400, Richard Hipp wrote:
> 2011/9/28 Lluís Batlle i Rossell
>
> The zlib compressor adds a timestamp at the beginning. If you gunzip the
> tarballs, you'll find that they are identical.
Hello,
Can we set the timestamp at will, for example, based on the chec
2011/9/28 Lluís Batlle i Rossell
> Hello,
>
> downloading a tarball for a fossil checkin, gives different file contents
> at
> every download I try.
>
> I'd like the tarball contents to be fixed for every checkin. Do you know if
> this
> can be done? Do you all would prefer having fixed contents?
Hello,
downloading a tarball for a fossil checkin, gives different file contents at
every download I try.
I'd like the tarball contents to be fixed for every checkin. Do you know if this
can be done? Do you all would prefer having fixed contents? What makes the
contents change at every download?
23 matches
Mail list logo
