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

Re: [RFC] v2 Tree conflict resolver spec.

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 10 Feb 2010 11:03:59 +0000

On Wed, 2010-02-10, Neels J Hofmeyr wrote:
> Julian Foad wrote:
> > Yup. And with merge, --accept=mine should be identical to 'svn revert'.
> Hey, wait a minute. That's not true when there were local modifications
> before the merge. I see it like this:

Oh yes. Sorry for the confusion. I forgot about local mods at the moment
I was writing that.

> Merge tree-conflicts, when they are encountered, should change neither the
> checked-out nor the check-in states other than flagging a conflict and
> storing some info with it.
> --accept=mine should then simply remove the conflict marker and done.
> --accept=theirs should be identical to 'revert' plus pulling in 'their'
> changes into the check-in state. In other words, --accept=theirs should
> reset the check-in state to the incoming action. The info stored with the
> conflict must somehow convey the incoming action. Oh my, *that's* the hard
> part ;)
> Or am I twisting things now?

Sounds totally right.

> I am thinking incrementally with merge. Local mods are allowed to exist
> before the merge, and I want to be able to go back to exactly those with
> --accept=mine.

Yup. Definitely.

> That's simple enough for a two-URL merge. But for a number of partitioned
> revision ranges (e.g. with a --reintegrate), that may be a problem. What if
> only the third or fiftieth revision range that is merged causes a tree
> conflict? Does merge combine them before passing the resulting changes to
> the merge_editor? Either case, recording or indicating those changes in
> tree-conflict information is a tricky question on its own...

I have some thoughts on this. Later.

> Have I left orbit?
> Still, I think it's quite insane to equal --accept=mine with a *revert*, of
> all things :) Revert *loses* mine, which is dangerous. Right?

Yup, sorry for writing that.

- Julian
Received on 2010-02-10 12:04:51 CET

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.