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