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

Re: relocate doesn't check arguments - may screw up working copy

From: SteveKing <steveking_at_gmx.ch>
Date: 2004-05-13 21:52:50 CEST

Max Bowsher wrote:

> The problem here is that Ben and I have been attempting to help you
> to understand the current functionality whilst you seem to be
> simultaneously proposing new functionality.
>
> We can all agree that invalid input to svn switch --relocate should
> cause an error, not break the working copy.
>
> If you really think that the syntax for switch --relocate should be
> changed, it would be best to start a new thread with a more
> appropriate subject, as that would require discussion of the design
> and thoughts about compatibility guarantees.

Oops. Sorry. First I just tried to think about ways how to overcome the
lack of sanity checking, but I guess I went a little too far and came to
a new feature. You're right. Sorry.

So then I'd like to propose a way to do the sanity checking:

right now, the relocate command checks if the "to" URL has the same
repository uuid as the working copy. You can see that in the source and
by trying to relocate to a nonexisting "to" URL or to a "to" URL which
has a completely different repository there.
So I think it would be best if the uuid comparison isn't done with the
"to" URL but with the *resulting* URL of the string replacement.
Or would that break the way this command is supposed to work?

Stefan

--
"The whole problem with the world is that fools and fanatics are always 
so certain of themselves, but wiser people so full of doubts." - 
Bertrand Russell
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 13 21:55:44 2004

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.