On Thu, Aug 13, 2009 at 11:52 AM, C. Michael Pilato <cmpilato_at_collab.net>wrote:
> Bill Tutt wrote: > I've always thought that a pending "replace" when
> reverted should
> > decompose into the underlying operations and only revert the non-delete
> > operation.
> >
> > That way the svn status command in your above example would output:
> > [[[
> > svn st
> > D alpha
> > ]]]
> >
> > The idea behind this behavior is the svn command line shouldn't mind
> > read the user's intention behind issuing the revert command.
> > svn doesn't know if the user wants to revert the delete as well as the
> add.
>
>
> 'svn revert' has a very clear meaning today, though, which would be muddled
> by the behavior you suggest: "restore TARGET to an unmodified state".
> It's
> for this reason that we didn't name the command 'svn undo', which would
> imply a stack of reversible operations.
>
>
>
The alternative would be to not allow the replace in the first place. Then
you'd never have a stacked operation in this particular context. However,
that makes merging much more annoying. You'd have to break the merge into
two halves one including the deletes, and the other the replaces (add,
copy, or move). Ugh. However, you wouldn't have replaces and thus no
stacking. The standard 'be consistent' argument would say pick one or the
other. ;)
Multiple pending directory moves can also create an implied stack of
operations as well with regard to their repository path. Admittedly, this is
a different kind of stack of operations... IF Subversion supported something
like this then:
directory tree A\B\C\D
svn mv A\B\C\D A\B\D
svn mv A\B B
svn revert B
resulting path for items contained by D: A\B\D
Reverting B didn't restore B to its original state because it still
contains the pending move of D. i.e. stacking operations
Or an even simpler:
svn mv a.cs temp.cs
svn mv b.cs a.cs
svn mv temp.cs a.cs
This is also an operation stack, but again of a different sort. In this case
life is simple because 'svn revert a.cs' would hopefully produce something
along the lines of:
'Error: Cannot revert a.cs because a pending move is currently at b.cs'
To sum up:
It seems kind of odd you can't undo a portion of the merge before submitting
your changeset with 'delete/(add, copy, move)' changes. So maybe you
shouldn't think of it as muddling revert, but allowing the user preforming a
merge (or individual command lines) to get the resulting changes they want
in the easiest way possible. The user pain in redoing the merge for just
that item seems high enough to at least consider it.
Food for thought,
Bill
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383394
Received on 2009-08-13 20:03:19 CEST