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

Re: Issue 2897 revisited. Really.

From: Branko ─îibej <brane_at_xbc.nu>
Date: 2007-11-30 05:39:35 CET

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

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

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.