[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: Re: "same inode" problems with cygwin svn client

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-09-06 13:15:51 CEST

> From: Dylan Cuthbert [mailto:dylan@q-games.com]
> "Bill Tutt" <rassilon@lyra.org> wrote in message
> >
> >
> > > From: Dylan Cuthbert [mailto:dylan@q-games.com]
> > >
> > > Hey, cygwin isn't quite that evil, it gives windows users a breath
> > > fresh
> > > air, allowing the use of emacs, bash, even Xfree86.. not to
> > about
> > > another 500+ really useful unix tools and libraries.
> > >
> >
> > For things that don't port well to Windows, then yes it does, and
> > power to folks who like such things.
> >
> > However, for projects like Subversion that have been ported to work
> > Windows, cygwin just shouldn't be used. It makes the maintainer's
> > more annoying by introducing the machinery cygwin uses to accomplish
> > some of the API calls used in Unix programs. Usually to a perf
> > detriment, not to mention assuming the users cygwin install is
> Not strictly true, we use cygwin as a development environment even
> we
> aren't developing cygwin apps, this is because it supports things such
> symbolic-linking and a decent shell environment and decent scripting.
> Mingw
> is ok, but it has none of the shell or scripting stuff, simply being a
> decent compiler in a crap environment.

You do know that Windows 2000 on does have "symbolic links" (aka NTFS
reparse points) don't you? APR's file stat routine even groks these

I just write Python if I want scripting code to happen. With tab
completion in Win32's shell, I never need a decent shell except for Unix
oriented reasons. (i.e. a bash script that needs to get run)

> We can, of course, use the Windows SVN tools but they don't know about
> symlinks and directory paths of our environment which can be very
> frustrating sometimes.

Yet another reason why cygwin is so annoying. APR doesn't grok cygwin
symlinks out side of cygwin for example. I'm sure you might be able to
submit a patch for such support though.

> We are not going to start using Visual Studio or MSDOS (or whatever it
> become nowadays) so what do you suggest to replace Cygwin? Cygwin is
> important tool and no longer just a porting tool as it used to be IMO.

Cygwin is always a porting layer, it is nothing more. Having said that,
it doesn't mean that you can't just deal with a cygwin ported legacy
Unix application. With the associated perf hits, and Win32 system
interaction overhead. (Nobody else understanding those cygwin symlinks,

You certainly can't develop a seriously focused Win32 application using
cygwin, and indeed mingw. Mingw still can't get a subset of the COM ABI
implemented correctly. (Although it's not gcc's fault, MS patented the

I was just suggesting using mingw to compile Subversion, not about
anything else you might want to be do with cygwin/gcc.

Glad you're willing to pitch in and try and help figure things out


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 6 13:16:38 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.