[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Switching from CVS to GIT

From: Eli Zaretskii
Subject: Re: Switching from CVS to GIT
Date: Mon, 15 Oct 2007 06:06:42 +0200

> Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)
> From: Johannes Schindelin <address@hidden>
> cc: Alex Riesen <address@hidden>, address@hidden, address@hidden, 
>     address@hidden, address@hidden
> 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.

> > > - 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.

> > > - 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.

> > > - 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]