Re: Switching from CVS to GIT

[Eli Zaretskii]

> Date: Mon, 15 Oct 2007 00:14:46 +0200
> From: Alex Riesen <address@hidden>
> Cc: Andreas Ericsson <address@hidden>, Benoit SIGOURE <address@hidden>,
>       git list <address@hidden>, Eli Zaretskii <address@hidden>,
>       Make Windows <address@hidden>
> 
> Re "functional". Have to remind something (besides the fork):

That's a 20-20 hindsight: if you deliberately write a program to rely
heavily on Posix-isms, don't be surprised when you discover that it
cannot be easily ported to other platforms.

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

> - 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.  In any case, I don't see how this can be of any real relevance
to porting GIT.  As for ":" in file names, simply don't use it, like
you don't use white space or characters below 32 decimal: it's
inconvenient, even if it's allowed.

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

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

>   and multi-cwd

No longer a problem on Windows versions since 2000.

> - no real "mmap" (which kills perfomance and complicates code)

You only need mmap because you are accustomed to use it on GNU/Linux.

> Interprocess communication:
> 
> - no reliable text environment (I'm programming in the damn thing for
>   10 years and I still don't know how to pass an environment variable
>   _for_sure_)
> 
> - it has only one argument (limited in size) passed to started
>   programs, which means that there is no possible way to safely pass
>   file and text arguments on command line (more than one, that is)

Not enough context, so I cannot talk intelligently about this.  Why do
you need interprocess communication in the first place? why not simply
give birth to a subsidiary process and pass it a command line (which
can be up to 32KB)?