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: Alex Riesen
Subject: Re: Switching from CVS to GIT
Date: Mon, 15 Oct 2007 00:14:46 +0200
User-agent: Mutt/1.5.15+20070412 (2007-04-11)

Johannes Schindelin, Sun, Oct 14, 2007 22:14:25 +0200:
> On Sun, 14 Oct 2007, Andreas Ericsson wrote:
> > Johannes Schindelin wrote:
> >
> > > I do not see any reason why libification helps the user experience on 
> > > Windows.
> > 
> > I was under the impression that the windows port suffers from Windows' 
> > lack of a proper fork() and friends and that a proper library would help 
> > solving those problems. Perhaps I was misinformed.
> 
> It suffered.  Until Hannes Sixt did a very fine job which cumulated in the 
> patch series he posted yesterday.  Of course, this work is the reason 
> msysGit is functional.
> 

Re "functional". Have to remind something (besides the fork):

Filesystem:

- no proper VFS (can't do anything with files opened elsewhere, and we
  have not enough error handling and diagnostic output to detect the
  problems)

- no proper filename semantics (case-insensitivity and stupid rules for
  allowed characters in filenames, like ":" in filenames in
  cross-platform projects)

- no acceptable level of performance in filesystem and VFS (readdir,
  stat, open and read/write are annoyingly slow)

- 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) and
  multi-cwd, which hasn't had formed itself into a problem yet, but
  surely will

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

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)






reply via email to

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