[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.


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.