Re: Switching from CVS to GIT

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Mon, 15 Oct 2007, Eli Zaretskii wrote:

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

Almost...

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

... not quite, ah ...

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

... yes!  There you have it.  Absolute filenames, resolved by readlink() 
are assumed to be the unique (!) identifiers for the contents.

_Note:_ absolute paths _without_ readlink() resolving are _still_ unique 
identifiers; this time for files/symlinks.

Things like this utter rubbish that two different file names (which are 
the keys in the keystore that a filesystem really is) make Windows' 
filesystem operations so slow.

I wonder when Windows heads will realise that this "convenience" is just 
another reason why Windows is easily outperformed by other OSes (yes, the 
last one is a plural).

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

No, I cannot.  I will not go and buy a copy of Windows just to show you 
the numbers.

Since quite some time I only run Linux on my machine(s), and the reason 
was a very unscientific experiment: I kept with the OS that did not freeze 
and let me do nothing for more than one second.

Now, that is my _personal_ decision.  If _you_ have no problem with 
Windows, just stick with it.  (I always thought this goes without saying, 
but Windows users tend to be very religious about this issue, thinking 
just because I hate Windows that I want to make them switch.  Hahaha, no.)

Ciao,
Dscho