Bill Tutt wrote:
>
>
> On Thu, Aug 13, 2009 at 2:31 PM, Neels J Hofmeyr <neels_at_elego.de
> <mailto: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?
If I understand merge right, it should remove all the local changes, so, yes.
Different for update: update wants to pull the BASE to HEAD, so that it can
resolve conflicts later without having to contact the repos. So with a
conflict during update, a revert should ideally revert local changes _and_
update to the repository's state, right? That's how I understand revert:
"wipe my local changes, get me back to the most recent committed state I
have downloaded." Can you think of a use case where it is necessary/helpful
to be able to half-revert a local change?
> (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.
So, someone merges from a branch, gets a conflict with an incoming replace.
The 'revert' step is then useful as a resolving strategy of "wipe, get a
clean slate, re-apply local changes manually". In that case, the merge would
be carried out and recorded correctly.
> 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'.
Yes, you're right. It's not good to have different granularity. -- So I am
thinking, when the replace was issued as a delete and an add that were a
couple of revisions apart, a three-way merge can still separate the two
operations. And it can be a meaningful choice to do a replace in a single
revision. Such a replace shouldn't be broken down into a fantasy half
revision, right?
But, sorry, what exactly are you suggesting, is it this?
[[[
$ svn st
R foo
$ svn revert --split-replace foo
partly reverted foo
$ svn st
D foo
]]]
My argument with tree-conflicts goes more like this:
[[[
$ svn st
R foo
$ svn up
C foo
$ svn st
C foo
> local replace, incoming replace upon update
$ svn revert foo
<foo now is on par with HEAD>
$ svn st
]]]
Partly reverting this case should probably split into four steps: revert
local add, revert local del, apply incoming del, apply incoming add. I think
it's not worth the trouble, really.
...above case currently fails in that, while `status' looks like everything
is as I intend it (it's empty), unfortunately `foo' is missing from the WC
and will only come back when passed as an explicit target to update.
Are we still talking about the same thing?
Thanks for the input, BTW.
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383507
Received on 2009-08-14 04:19:28 CEST