Re: Switching from CVS to GIT

From: Eli Zaretskii <eliz@gnu.org>
Date: Oct 16, 2007, 07:03 UTC
Message-ID: <E1IhgT2-0000bg-O6@fencepost.gnu.org>
In-Reply-To: <Pine.LNX.4.64.0710160032020.7638@iabervon.org>

Show 9 quoted lines

> Date: Tue, 16 Oct 2007 01:56:46 -0400 (EDT)
> From: Daniel Barkalow <barkalow@iabervon.org>
> cc: raa.lkml@gmail.com, Johannes.Schindelin@gmx.de, ae@op5.se, 
>     tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org
> 
> Ah, that's helpful. We don't actually care too much about the particular 
> info in stat; we just want to know quickly if the file has changed, so we 
> can hash only the ones that have been touched and get the actual content 
> changes.

As I wrote in my other message, using native APIs improves performance by at least a factor of two.

> The tricky thing is that, while the optimization 
> process is running, other programs may be reading the database, so (1) the 
> files that are no longer needed, because better-optimized versions are in 
> place, may be open in another task

Is this because another user might be accessing the database, or are there other popular use cases that cause this? If the former, then this is not terribly important on Windows, since the situation when more than one user is logged and actively works is quite rare, basically limited to some scheduled task (the equivalent of a cron job) running for some user while another one is logged in interactively.

This might be different on machines that use Cygwin, though.

Show 8 quoted lines

> Now, it's entirely possible that a completely different database 
> implementation would be better on Windows, but our current one does a lot 
> of creating files under different names, moving them to names where 
> they'll be seen (since this is atomic under POSIX, and partial files are 
> never seen by other tasks). Also, once we have new files in place, we 
> unlink the files that they replace, so that new tasks will use the new 
> ones and tasks that already have old ones open can still get the data out 
> of them. Also, the files generally get mmaped,

Perhaps mmap introduces complications (I simply don't know), but in general, as I show elsewhere in this thread, you can do similar things on Windows, if you use native APIs (as opposed to emulations of Posix, like `open'), although you may need to rename the old file to get it out of the way of the new one with the same name, because otherwise the old file will still be seen, even if deleted, as long as it's open in some process.