Re: Switching from CVS to GIT
- From
- Eli Zaretskii <eliz@gnu.org>
- Date
- Oct 15, 2007, 04:06 UTC
- Message-ID
- <u6419ja25.fsf@gnu.org>
- In-Reply-To
- <Pine.LNX.4.64.0710150039120.25221@racer.site>
Show 7 quoted lines
> Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST) > From: Johannes Schindelin <Johannes.Schindelin@gmx.de> > cc: Alex Riesen <raa.lkml@gmail.com>, ae@op5.se, tsuna@lrde.epita.fr, > git@vger.kernel.org, make-w32@gnu.org > > The problem is that on Windows, you cannot keep a file open and delete it > at the same time.
That is no longer true, for quite some time. NT4 and later versions support that almost exactly like Posix filesystems.
Show 12 quoted lines
> > > - no acceptable level of performance in filesystem and VFS (readdir, > > > stat, open and read/write are annoyingly slow) > > > > With what libraries? Native `stat' and `readdir' are quite fast. > > Perhaps you mean the ported glibc (libgw32c), where `readdir' is indeed > > painfully slow, but then you don't need to use it. > > No, native. > > Once you experienced the performance of git on Linux, then rebooted into > Windows on the same box, you will grow a beard while waiting for trivial > operations.
Maybe GIT assumes too much about `readdir' and `stat', and should refactor its code into better abstractions.
Show 10 quoted lines
> > > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c > > > can be not the same, depending on what current "drive" is) > > > > So what? on Unix "a/b/c" can be not the same. Both cases are simply not > > complete file names, that's all. No one said there must be a single > > root for all volumes, it's the Posix jingoism creeping in again. > > I think Alex means this: you can have C:\a\b\c and D:\a\b\c. So depending > on which drive you are, you mean one or the other. Just comparing the > paths is not enough.
What _I_ meant is that the C: part is part of the full file name, exactly like the leading / is on Unix.
Show 5 quoted lines
> > > - No real "mmap" (which kills perfomance and complicates code) > > > > You only need mmap because you are accustomed to use it on GNU/Linux. > > Yes. And we rely on the performance very much.
There's no need for mmap to get memory performance, except if sbrk and friends are too slow.