Re: Windows support

["Shawn O. Pearce" <spearce@spearce.org>]

Stephen Cuppett <cuppett@gmail.com> wrote:
> On 7/25/07, Steffen Prohaska <prohaska@zib.de> wrote:
> 
> >Is it just that windows developer hate cygwin because it's to
> >complex to install or is there any severe limitation?
> >functionality? stability? performance?
> 
> I actually have no problems with cygwin and find it works pretty well
> with git repositories.  Starting the xserver to run git-gui is pretty
> annoying though.

I've never even tried to run it that way.  I know the Cygwin packages
have two different Tcl/Tk binaries: one that is actually a hacked
up native Tcl/Tk (which uses native Win32 graphics) and one that
is a straightup recompile of the UNIX Tcl/Tk (which uses X11 only).
I only have the native Win32 Tcl/Tk installed, and thus run native
graphics.

An advantage of the native Tcl/Tk is just that, its native.
A downside is it is native.  It doesn't use the Cygwin APIs for exec,
it directly goes through CreateProcess().  It doesn't use the Cygwin
APIs for file IO, it goes directly through the native Win32 stuff.
Which means it sometimes has a difficult time with Cygwin paths.
There are a few places in git-gui where I run `cygpath -w` just to
handle this.

I've also recently tested git-gui under the ActiveState Tcl
distribution.  It ran, but for reasons unknown to me (I didn't
research it yet) the .git/info/exclude rules didn't apply when
git-gui spawned a `git ls-files --others` helper process.

I have considered doing a starkit of git-gui, msys based git
executables/dlls, and the ActiveState Tcl engine.  That should give
users a single git-gui.exe that they can just download and launch,
no installation required.  Haven't started it yet, partly because
I haven't finished removing the need for shell scripts to support
git-gui.  I'm almost there, especially with Daniel Barkalow's work
on a native C fetch.

> Windows-based development teams are going to expect
> easy access to those kinds of tooling.  Otherwise, the champion will
> be pushing a type of workflow change that would hinder adoption anyway
> and leave a sour taste for a long time.

I agree.  They also want this thing called "explorer integration" or
something like that.  I've never had good luck with cra^H^H^Hpackages
that install themselves into the Windows explorer UI.  I would
probably never develop such a thing myself.

> I don't know if the performance problems are cygwin or not.  More
> knowledgeable people might be able to answer, it's just what I'm
> observing right now.  It could be more fundamental to the types of
> access being performed en masse on inode-based versus NTFS systems.

As Linus described its NTFS/Windows that is horrid here, and not
really Cygwin.  Linux is just fast.  Almost all modern UNIXes are.
At least when compared to the Windows kernel running on a crappy
4500 RPM IDE drive that is also hampered with a virus scanner that
wants to scan 12 GiB of data every 30 minutes, even when the volume
has only 8 GiB of files on it.  ;-)

Git is fast.  Its faster than SVN on the same hardware.  Even under
Windows.  About the only thing that I think is "slow" is two areas:

  * status.  Doing lstat() on 8,000+ files takes a little while.
  Hooking into the OS' native file monitoring facility and having
  that tell us which files are stat-dirty would reduce the need
  for these massive lstat() runs.

  * for-each-ref.  Opening 400 ref files to read their current SHA-1
  values is not fast on Windows.  More aggressively packing refs
  (at least on Windows) may actually be worthwhile.  Another option
  might be to have the same process that is watching the OS' file
  monitoring interface cache the ref values, so we can get to them
  via say shared memory or a pipe instead of file IO.

Neither feature is really necessary on a good UNIX however, as most
kernel development teams have just made sure their system has good
file IO throughput.  Oh, and they don't have to run virus scanners
that get higher IO priority than everything else.

-- 
Shawn.