[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: tree conflicts with replace

From: Neels Janosch Hofmeyr <neels_at_elego.de>
Date: Fri, 14 Aug 2009 04:16:30 +0200

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.