"Daniel L. Rall" <dlr@finemaltcoding.com> writes:
> ...via merging from a single source URL into a WC. This requires that
> your merge source URL and WC are ancestrally-related.
So (being fast-and-loose with notation here) this is for the following
case, right?:
$ svn cp ^/trunk ^/branches/B
$ svn co ^/branches/B Bwc
$ cd Bwc
$ [... do work in Bwc, commit changes, develop the branch, etc ...]
$ svn merge ^/trunk
$ [... resolve conflicts, commit ...]
$ [... do more work in Bwc ...]
$ svn merge ^/trunk
$ [... resolve conflicts, commit ...]
$ [... do more work in Bwc ...]
$ svn merge ^/trunk
$ [... lather, rinse, repeat ...]
(Just making completely sure I'm on the same page as you.)
> 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.
E.g. from trunk to branch, in the above example, although it would
work as well for a branch off another branch, etc.
> 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.
*Very* well said! This language should get folded into the
merge-tracking req/design docs.
> 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.
Excellent (and again, well-expressed).
> * 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).
Okay, I was confused for a moment, but now I think I understand. This
option is for merging the branch into a *trunk* wc, right? So you'd
run:
$ cd up-to-date-trunk-wc
$ svn merge --reintegrate url_to_branch_B[@PEG]
Am I still with you?
This description doesn't say what happens with mergeinfo, but I guess
that's appropriate: you're talking about the user-level view of how
things work. The mergeinfo should do whatever is necessary to make
this behavior happen.
> 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).
This has to count, overall, as one of the most comprehensible mails on
a normally incomprehensible topic that we've ever seen on this list.
+1 to the proposal!
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 10 23:13:04 2007