make-w32
[Top][All Lists]
Advanced

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

Re: Switching from CVS to GIT


From: Johannes Schindelin
Subject: Re: Switching from CVS to GIT
Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)

Hi,

On Mon, 15 Oct 2007, Eli Zaretskii wrote:

> Alex Riesen said:
> 
> > - no proper VFS
> 
> I'm not sure what you are talking about.  What VFS do you use on 
> GNU/Linux that cannot work on Windows, and why do you use it?

The problem is that on Windows, you cannot keep a file open and delete it 
at the same time.  This is an issue in Windows' equivalent of VFS.

A neat trick to work with temporary files without permission issues is to 
open the file and delete it right after that.  This does not work on 
Windows.

> > - no proper filename semantics (case-insensitivity and stupid rules for
> >   allowed characters in filenames, like ":" in filenames in
> >   cross-platform projects)
> 
> There's a flag on Windows to open files case-sensitively, if you need
> that.

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.

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

Sure, git kicks ass on Windows, but only as compared to other programs _on 
Windows_.

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

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

Hth,
Dscho





reply via email to

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