On Fri, 30 Nov 2007, C. Michael Pilato wrote:
> Vlad Georgescu wrote:
> > David Glasser wrote:
> >> How bad of an idea is making "svn merge" with reverse ranges default
> >> to the target and with forward ranges default to the other branch?
> > +1. That would minimize the number of URLs you need to type.
I favor this, assuming we can work out any UI kinks. +1
> Here again, though:
> $ svn merge -c -SOME_REV
> Oh! Shoot! Better undo that:
> $ svn merge -c SOME_REV
In this model, where forward and reverse merges have different behavior,
the second 'svn merge' to do a rollback is inappropriate. If you hadn't
performed a commit of the previous merge, you'd use 'svn revert'. If you
had performed a commit which, say, created NEW_REV, you'd do:
$ svn merge -c -NEW_REV
...which would rollback the reverse merge and mergeinfo changes of SOME_REV
from the WC's branch.
Alternately, you could use:
$ svn merge -c SOME_REV SOME_REV_SOURCE_URL
While I agree with Mike that the UI offers some potential for confusion,
this model would be at least deterministic, meaning the users who don't
read the documentation (read: everyone) would at least be able to learn the
sub-command flavor's behavior. This is a reasonable trade-off because it
better matches the typical user usage model.
Received on Sun Dec 2 00:38:38 2007
- application/pgp-signature attachment: stored