Karl Fogel wrote:
> Molle Bestefich 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 ...
[snip explanation]
> If we fixed revert to Do The Right Thing,
> would that solve the problem?
For the scenarios mentioned, yes.
To be helpful towards newbies, it (c/sh)ould be decided that:
# svn mv a b
# svn mv b a
(eg. rename, rename back) is not an action that anyone would like to
actually record in their repository. So while we're making 'svn
revert' Do The Right Thing, we might as well make this action do the
same.
Then the scenarios mentioned would be elegantly fixed, both for those
who knows 'svn revert' and for newbies who think "I'll just move the
file back" as a first impulse.
> > 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.
Agree.
> In other words, if we made these recovery steps work right, that would
> solve most of the problem, no?
That would definitely be a lot prettier than what's there now :-).
Michael Brouwer wrote:
> Disallowing multiple svn cp or svn mv commands on already copied or
> moved files is still not orthogonal to how the normal cp and mv
> commands work.
Agree.
> So to truly solve the problem of people seeing
> unexpected errors you'd need to allow for those types of operations in
> a wc.
Agree.
> it might not be worth the effort by itself, but from a consistency and
> ease of use point of view allowing what Molle outlined would make
> sense.
Agree.
> That said this might be a lot more work than just changing revert, and
Ivan has already coded it up it seems.
I think his approach is sane, except that:
1. svn cp a b
2. echo "Now here's a change to file B" >> b
3. svn cp b c
4. echo "And here's a change to file C" >> c
5. svn ci
6. svn diff c -rPREV:HEAD
The diff on C will be wrong. It will show the change performed in
step 2 as a change to file C, while the change was actually to file B.
The user will never want this.
If Ivan's patch is accepted, an added restriction should be that the
source file must not be an already copied file with local
modifications.
(If a user really wants (?!), --force could be considered an option.)
I realize that the same problem exists with current svn. Consider:
1. echo "Here's a change to the WC file A" >> a
2. svn cp a b
3. echo "Here's a change to the WC file B" >> b
4. svn ci
5. svn diff b -rPREV:HEAD
This is currently allowed and will not do what a regular user expects.
The copy-from will be file A at the revision *before* the commit in
step 4 and thus the changes made in step 1 will appear both as changes
to A, and as separate changes to B.
The reason that this hasn't been explicitly disallowed is (I think)
that few people actually modify a file and then copy it around because
there's currently not much use of doing so.
But I think there's a high risk that more people are going to do this
if multiple consecutive svn cp/mv is allowed as by Ivan's patch.
So this problem should probably be addressed now too.
I'm not trying to overreact or anything, just think ahead :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 25 03:28:26 2005