On Thu, Aug 13, 2009 at 2:31 PM, Neels J Hofmeyr <neels_at_elego.de> wrote:
> Hi Bill,
> to keep the replace indivisible serves clarity and integrity of code
> semantics. You can always revert the whole replace and do a delete yourself
> after that.
>
>
The revert would remove the merge history information if the replace came
from a merge, right?
(Keep in mind I have no mental model for how Subversion merge history is
implemented. I'm dealing (unfortunately) only with what I think might
happen, and being a bit of a devils advocate to encourage discussion.)
Wouldn't a subsequent merge between the two trees produce the replace again?
That seems unfortunate.
> After a revert, the user should be sure that what is seen in the working
> copy corresponds with BASE, the state from last `update'.
>
> So, in the case where an incoming replace was downloaded during the update
> (which caused a tree-conflict) and I then `revert' the node in question,
> the
> working copy should show the new file from the repos.
>
> etc., I don't think splitting that up is a good idea. That would be better
> implemented as a separate command like `svn undo'. Patches welcome :P
>
> ~Neels
>
>
>
Heh. Shouldn't 'svn undo' be an backward-3 way merge so you could 'svn undo'
changeset (tip) and have as a result (tip-1)?
Differentiating between 'undo' and 'revert' like you suggest seems like a
very bad idea. If someone were to do anything like I'm suggesting then maybe
it would be an additional option for 'svn revert'.
Munching on all of this thought food,
Bill
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383419
Received on 2009-08-13 22:56:41 CEST