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

Re: [PATCH] Allow copy files that already copied

From: <kfogel_at_collab.net>
Date: 2005-12-19 21:18:26 CET

Molle Bestefich <molle.bestefich@gmail.com> writes:
> Scenarios:
> 1.) You accidentally rename 'abc' to 'dex' instead of 'def'.
> 2.) You accidentally rename 'abg' to 'def' instead of 'abc' to 'def'.
> 3.) You accidentally copy 'abc' to 'dex' instead of 'def'.
> 4.) ... etc ...
> We'll start with 1).
> # svn mv abc dex
> Oops, should've been 'def'. It now seems very obvious (user POV) to
> undo the move by 'svn mv'ing the file to a correct filename:
> # svn mv dex def
> svn: Use --force to override this restriction
> svn: Move will not be attempted unless forced
> svn: 'dex' has local modifications
> That fails, with an unrelated and therefore very poor error message
> (local mods?!).
> The user might then try to 'svn revert'. He's a bit confused now,
> because which file should be the target of svn revert - the renamed
> one or the original one?
> He tries the renamed one first since it actually exists in his filesystem:
> # svn revert dex
> Reverted 'dex'
> Only to find that it does not accomplish what he expects (renaming the
> file back). Judging from the above output, it actually looks like it
> reverted 'half' of the rename, eg. the addition of dex, but did not
> undo the removal of 'abc'. If he has local mods, he'll be very
> worried, but let's assume for now that he hasn't and it's OK that
> 'dex' is gone. He now does a regular 'ls' but sees that 'dex' is
> still there:
> # ls
> dex

If we fixed revert to Do The Right Thing, would that solve the

> He's getting more confused. Then he tries to svn revert the original
> file instead:
> # svn revert abc
> Reverted 'abc'
> Only to find that now he has TWO files - both the original and the
> moved-to file:
> # ls
> abc
> dex

And this should do the same thing, IMHO.

In other words, if we made these recovery steps work right, that would
solve most of the problem, no?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 19 23:45:30 2005

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.