> I'd like to reopen the renaming issue. Please read the original
> discussion below...
> ==================BEGIN FORWARDED MESSAGE==================
> "Gili" <firstname.lastname@example.org> writes:
>> Ufortunately Subversion is only one of a dozen open-source
>> tools I use. I've gotten bogged down over the past month doing exactly
>> what you have suggested, contributing patches, and now I would like to
>> finally concentrate on what I am trying to do in the first place: build
>> my product. There is only so much one person can do :(
>> At the very least, why not open an enhancement request against
>> Subversion? Is there really any dispute as to the correct behavior of
>> Subversion "rename" under win32?
> No, there's no dispute.
> Anyway, I think it's time to revive this issue. Either we should
> remember why it's so hard to solve, and say that in the issue, or we
> should fix it!
I've been collecting guts for a few weeks to email something like Gili
have so let me just add my views, for what they're worth, and be done with
I've seen the importance of this issue diminish as different work arounds
have been developed and implemented. However, at least in my case two
major usability problems remain unsolved as the original problem is not
It's my believe that these work arounds have somehow given ppl the
impression that this issue isn't so severe as it used to be. My oppinion
is quite different and I hope to be able to prove, or at least demonstrate
Assume (for whatever reason) that the repository must have the ability to
change the case of files, but not have the same file name differing only
in case (this is what win32 is mostly wanting).
1. A name change will corrupt parts of every checked out WC unless you can
first remove the file, then have all WC to 'update' before finally adding
the file anew with the correct case.
2. A build server (Say i.e. CCNet) is running providing continous
integrations and it has a WC of it's own where clean builds take place. A
case rename will render that build server inoperative since 'update' won't
work. It would require manual intervention and the admin might end up
having to checkout the entire WC anew if the change was made high up in
In normal day-to-day development this is a very real and serious problem
(at least for me), especially not being able to have a WC consistent on
the build server(s) I would almost consider denial of service (build
service in this case).
As it turns out it's almost impossible to train users to see this problem
and to handle it correctly. This has ended up in many users loosing hours
of work time as they remove large portions or the entire WC (which is
I remeber the old threads and that the solution wasn't as trivial as one
might be tempted to think, but from a win32 users point of view I think
it's safe to say they need to be fixed sooner or later somehow.
For server builds (which I believe isn't only connected to the case issue)
I was considering suggesting a --force option to 'update', tailor made for
those of us that needs to have automated build bots that requires no
Can't wait to see the resolution :)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Dec 21 14:49:43 2004