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