[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
of
> > > fresh
> > > air, allowing the use of emacs, bash, even Xfree86.. not to
mention
> > about
> > > another 500+ really useful unix tools and libraries.
> > >
> >
> > For things that don't port well to Windows, then yes it does, and
all
> > power to folks who like such things.
> >
> > However, for projects like Subversion that have been ported to work
on
> > Windows, cygwin just shouldn't be used. It makes the maintainer's
job
> > 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
bugfree.
>
>
> Not strictly true, we use cygwin as a development environment even
though
> we
> aren't developing cygwin apps, this is because it supports things such
as
> 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
things.

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
the
> 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
has
> become nowadays) so what do you suggest to replace Cygwin? Cygwin is
an
> 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,
etc...)

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

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
though!

Thanks,
Bill

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