> ...via merging from a single source URL into a WC. This requires that
> your merge source URL and WC are ancestrally-related.
>
>
> Use cases
> =========
>
> Easily allow merging of all (ancestrally-related) outstanding changes
> from one line of development to another, while accurately recording a
> mergeinfo audit trail.
>
> By "easily", the default behavior (merge algorithm) must support the
> use case encountered most often by the user: "bring un-cherry-picked
> branch WC up to date with its mainline". At the same time, the
> ability to merge a cherry-picked branch back into a mainline WC must
> also be easily accessible, and require the barest minimum of
> parameters. This latter case is important for avoiding repeated
> conflict resolution on long-lived/heavily cherry-picked branches.
>
>
> Proposal
> ========
>
> * Subversion 1.5, unlike previous versions, will let you specify one URL
> and an optional WC, via:
>
> svn [options...] merge URL [WC]
>
> * If you specify no revision range, or specifiy -c/-r options, you get a
> "cherry-picking" (or "unlumped") style merge, which potentially performs
> multiple editor drives, but will merge all eligible changes regardless of
> the state of your WC with respect to the line of development that you're
> merging from.
>
> * If you specify the --reintegrate option (bikeshed painting contest open
> for business), you get a "lumped" style merge, which merges the differences
> between the youngest revision from the WC that has been merged into the URL,
> and any peg revision specified for the URL (otherwise HEAD).
>
>
> Relation with Mike Pilato's recent 2-URL merge changes
> ======================================================
>
> The --reintegrate portion of the above proposal is basically a special
> case of Mike's recent changes (r28315 on trunk, r28303 on the
> mo-betta-two-url-merges branch), which requires some additional code
> from the whole-branch-merge branch. In terms of modularization, the
> proposal is to retain the code from the whole-branch-merge's
> libsvn_client/merge.c's ensure_wc_reflects_repository_subtree() and
> svn_client_merge_whole_branch() functions (renaming the latter to
> reflect whatever we name what I'm thinking of as the --reintegrate
> option).
What I don't understand yet is:
What is the need for the --reintergrate option at all?
The point is:
In both cases (with and without --reintergrate), the intention
of the user is exactly the same:
"Please merge all missing changes from URL into my wc!"
If the URL is already up-to-date, then it is just an an implementation
detail that Subversion can use a "lumped" style merge.
What about Subversion detecting that case automatically
without extra option?
When having a perfect merge-tracking some day, then an "unlumped" style
merge and an "lumped" style merge must/should give exactly the same
result anyway.
It is "only" a limitation of the current merging implementation
that it cannot handle the general case yet, so that the current
implementation has to handle different special cases
differently to handle the standard use cases.
But I think that this should be an implementation detail,
which should be not exposed to the user.
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 11 12:02:15 2007