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

Re: [merge tracking] Merging all outstanding changes between ancestrally related branches

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-12-10 23:12:50 CET

"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

   $ 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!


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

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.