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

Re: Renaming files on win32

From: <kfogel_at_collab.net>
Date: 2004-12-24 02:15:06 CET

Philip Martin <philip@codematters.co.uk> writes:
> No major difficulty? In other words "you overlooked something
> obvious". You are becoming *very* annoying.
> I'll give it one last go: if you want to help fix this you need to
> work out what to do. That's not just some vague hand waving about
> setting properties to control the client/server behaviour. You need
> to examine how the libsvn_wc library handles files in the physical
> filesystem, you need determine what goes wrong when the filesystem is
> case-insensitive, you can ask questions about the current code if you
> need to, and then you need to propose some changes to the library.
> So far your contributions have been little more than noise.

Yeah. I can understand why Philip is getting annoyed :-(.

Gili, the reason I asked you to post here was so we could remember why
the seemingly-obvious solutions had not been done, not so we could be
accused of having "placed this issue as a lower priority" despite it
being "no major difficulty". If only things were that easy!

Now we have the information, thanks to Philip Martin and Greg Hudson:

   * 'svn mv ABC abc' is hard because the two files have to live in
     .svn/text-base/ simultaneously for a while. There are solutions
     to this, but they involve making notoriously complex libsvn_wc
     even more complex. This is always something we approach with

   * Receiving case-only changes via update is hard because add of the
     new file arrives before the delete of the old file. Again, there
     may be solutions to this, but a lot of thought and testing is
     required. The order in which things happen during an update is
     hardly random, so it's not like we can just change that order and
     assume everything's going to be fine.

A constructive thing you could do would be to annotate issue #667 with
this information, and with a pointer to this thread, and ideally
pointers to the specific messages within this thread that contain hard
technical information.

(An even more constructive thing would be a patch, of course, or the
type of code-questioning discussion that precedes a patch. But I
completely understand if you don't have time for that; updating the
issue would be the next best thing.)


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 24 02:20:17 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.