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

Re: Re: Move problem with Win Filesystem

From: Erik Anderson <erikba_at_teamworkgroup.com>
Date: 2004-09-01 22:45:12 CEST

At the minimum, could we have the "svn move Hello.TXT hello.txt" succeed on
"case-insensitive comparison" filesystems, with a successful rename of the
file?

----- Original Message -----
From: "Erik Huelsmann" <e.huelsmann@gmx.net>
To: "Ian Brockbank" <Ian.Brockbank@wolfsonmicro.com>
Cc: <nathan@hummingbird.com>; <Michael.Gaehwiler@griesser.ch>;
<users@subversion.tigris.org>
Sent: Wednesday, September 01, 2004 1:36 PM
Subject: RE: Re: Move problem with Win Filesystem

> > Erik Huelsmann wrote:
> > >
> > > > Michael Gaehwiler wrote:
> > > >
> > > > > the renaming of files to only change capitals does not
> > > > > work on windows filesystem. example:
> > > > >
> > > > > create file 'Hello.TXT' (e.g. copied from DOS filesystem)
> > > > > svn add Hello.TXT
> > > > > svn move Hello.TXT hello.txt
> > > > > svn: Cannot move path 'Hello.TXT' into itself
> > > >
> > > > See http://subversion.tigris.org/project_faq.html#case-change
> > > >
> > > > > so my question is: could somebody resolve this problem?
> > > >
> > > > The above FAQ isn't a proper solution, in my view. The
> > > client should
> > > > know it's on a case-insensitive system and work with that.
> > >
> > > How do you propose to solve the problem that 2 different
> > > files map to the
> > > same filesystem object?
> >
> > Recognise this is a case-blind filesystem, and deal with it. It's
> > special-case code, but then it is a special case.
>
> I was actually not asking you to tell me to deal with it, but I was asking
> what you consider good behaviour for the Subversion client when dealing
with
> it. I can't feed "Deal with it" to a C compiler and expect a working
> program.
>
> >
> > On updates, if the delete is done before the add (talking about effects
> > on the WC here - I know they map on to copy+delete as repository
> > operations), the old object wouldn't be in the way.
>
> Ok. That is something to work with. But it leaves the problem of checking
> out FOO.c and foo.c to the same directory unaddressed.
>
> > Having just hit this recently it is a HUGE pain, particularly if you're
> > trying to go backwards and forwards through revisions searching for
> > where a bug was introduced. Maybe I did it incorrectly, but every time
> > I tried to update to a revision on the other side of the change I got a
> > "file in the way" error, so I had to update in two steps.
>
> I don't deny that it's a pain, but implementing something which doesn't
work
> won't get you off my back, so that is why I was asking what you consider a
> good algorithm. The "file in the way" error is the best error we can
> generate (until we have a good algorithm to 'deal with this'), since there
> really is a 'file in the way'.... Sorry.
>
> > Ian Brockbank
> > Senior Applications Software Engineer
> > e: ian.brockbank@wolfsonmicro.com / apps@wolfsonmicro.com
> > scd: ian@scottishdance.net
>
>
> bye,
>
>
> Erik.
>
> --
> NEU: Bis zu 10 GB Speicher für e-mails & Dateien!
> 1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 1 22:44:40 2004

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

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