[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 01:56:39 -0400

> 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 not so much opening, but determining if an existing file 
> and a file in the index have the same name.
> For example, "README" in the index, but "readme" in the working directory, 
> will be handled as "deleted/untracked" by the current machinery.  IOW git 
> will not know that what it gets from readdir() as "readme" really is the 
> same file as "README" in the index.

That's because you think file names are simple strings and can be
compared by simple string comparison.  This naƬve view is not true
even on POSIX systems: "foo/bar" and "/a/b/foo/bar" can be the same
file, as well as "/a/b/c/d" and "/x/y/z", given the right symlinks.
But for some reason that eludes me, people who are accustomed to POSIX
stop right there and in effect say "file names are strings, if we only
make them absolute and resolve links".  Instead, recognize that file
names are not strings (although they inherit some of the strings'
traits), and think in terms of "file-name comparison" abstraction;
then everything will fall in place just fine.

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

Can you show a test case where this penalty is clearly visible?  I'm
curious to see the numbers.  TIA

reply via email to

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