Mark Phippard wrote:
> On Nov 29, 2007 10:10 AM, Kamesh Jayachandran <kamesh@collab.net> wrote:
>
>>> Ah, right, so Ph.Marek's suggestion won't work for cherry-picking. So
>>> you'll have to investigate one of the other two methods: either
>>> subtract r51 from r60 and merge the resulting patch back to trunk, or
>>> force r60 to be split into r60 and r61 when the user does the
>>> cherrypicking.
>>>
>>>
>> Forcing the commit to fail if it has some local mod along with merge
>> could be easy I think, though I would prefer having something like
>> non-reflective merge editor, which I am investigating.
>>
>
> I do not think anyone is suggesting you could not do the commit. Just
> that commit would somehow "magically" perform two commits instead of
> one. I honestly do not see how that is possible, but that is the
> suggestion.
>
If you don't want to go head-first into patch algebra confusion ... and
I somehow suspect that you don't ... there is indeed a "simple" and
"correct" way to magically get two commits from a merge + local change.
* "simple": the solution involves touching libsvn_wc in non-trivial
ways ...
* "correct": will produce consistent but not necessarily sane results.
Add two assumptions:
* The user should still see conflict markers for source-level conflicts.
* You do *not* want to commit any conflict markers ever.
Stir, season to taste, and serve:
* during the merge, squrrel away a whole revision's worth of raw
merge-result text bases (c.f. "local checkpoint' in two-stage
commit terminology);
* since conflict markers are forbidden in the raw merge result,
resolve all conflicts in the squirreled-away text bases
automagically by using "theirs" -- i.e., the bits from trunk, not
from the branch;
* present the same conflict markers and trappings to the user as usual.
The user will resolve the conflicts, and commit ... at that point,
create one revision from the squirreled-away raw merge results, rebase
the WC to that revision, and commit any remaining differences in the
working files. Notice how the user's conflict resolution will have just
caused you to commit useful diffs from "theirs" to "valid" in the
conflicted regions -- said diffs should mostly do the right thing during
a merge back to trunk.
Some interesting edge cases:
* Local modifications in the WC prior to the merge: checkpoint the
local mods; merge (creating a second checkpoint); resolve; commit
-> creates 3 new revisions.
* Repeated merges without intermediate commit: checkpoint every
merge in sequence, and upon commit, create as many revisions as
necessary.
And so on.
As an additional bonus, teach the repository to combine several txns
into a single revision, and put txn IDs into merge info instead of
revision numbers ... (/me ducks)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 30 05:40:02 2007