I cannot find that email in
http://svn.haxx.se/dev/archive-2007-11/
Did it get lost?
-------- Original Message --------
Subject: Re: Issue 2897 revisited. Really.
Date: Fri, 30 Nov 2007 13:37:57 +0100
From: Folker Schamel <schamel23@spinor.com>
To: Branko Čibej <brane@xbc.nu>
CC: Mark Phippard <markphip@gmail.com>, Kamesh Jayachandran <kamesh@collab.net>, Ben Collins-Sussman <sussman@red-bean.com>, dev@subversion.tigris.org
References: <53c059c90711281346r46855cfn1f0b8fd3a144dfd1@mail.gmail.com> <873auqvxb7.fsf@red-bean.com> <474E65C3.3030702@collab.net> <53c059c90711290503x1de44453k36afc7cf2448f1db@mail.gmail.com> <474ECC46.8010904@collab.net> <53c059c90711290706y3eecabaew5329a1d47bf38b37@mail.gmail.com> <474ED658.1010501@collab.net> <ff892c5d0711290711nb5eb2e9ubb28273670206b6d@mail.gmail.com> <474F9407.6020208@xbc.nu>
Branko Čibej wrote:
> 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)
I don't know other VC systems, but I don't see how splitting the merge
into two commits can work at all for Subversion.
Sample:
r1: Trunk has one file containing just one line "a".
r2: Branch is created from trunk.
r3: Branch changes manually "a" to "aa" and commits.
r4: Trunk changes manually "a" to "b" and commits.
Trunk is merged (with merge-tracking, "a" -> "b") into branch (currently: "aa").
This gives a conflict.
r5: Branch: Auto-commit of that conflict.
r6: Branch: The conflict is resolved manually as "bb" and committed.
r7: Trunk changes manually "b" to "c" and commits.
Trunk is merged (with merge-tracking, "b" -> "c") into branch (currently: "bb").
This gives a conflict.
r8: Branch: Auto-commit of that conflict.
r9: Branch: The conflict is resolved manually as "cc" and committed.
Ok, now we want to merge branch into a trunk wc.
Because of merge-tracking, this effectively will merge
changes r2:3, r5:6, and r8:9.
Obviously the overall result of all these merges must be "cc".
However, mering r2:3 ("a" -> "aa") into the trunk wc ("cc") will cause a conflict.
Now, r5 is somehow the merge-conflict.
Now, what is r5 supposed to be, so that merging r5:6 (something -> "bb")
can be successfully applied to the conflict state of the previous merge?
Branko, you suggest that r5 contains "b", right?
Then how do you want to apply r5:6 ("b" -> "bb") to the previous conflicted state?
Maybe there is some magic trick, but I don't see it yet.
I suppose that there is no way of avoiding "patch algebra"
including subtracting changes.
However:
I bet my cat that your current mergeinfo schmele is a dead end already now,
and that you will have to change it sooner or later anyway.
See my previous emails for a more detailed information.
Short summary:
The current mergeinfo scheme can be used to fix reflected merges correctly.
It can be also used to implement merging between multiple branches correctly.
However, it cannot be used for supporting both at the same time.
The problem is:
The current mergeinfo scheme simply does not contain enough information
about the merge graph structure:
Currently, when merging branchA -> branchB -> branchC,
then mergeinfo of C stores both A and B.
But in order to implement a solution solving BOTH above problems,
mergeinfo of C should store just B, and B stores A, representing the graph
A -> B -> C, which is needed to handle both above issues at the same time.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 4 21:43:55 2007