> I'd like to take a step back first, and ask:
> Why do you need to merge back and forth between two branches?
I've often asked the same question :) So, with the partial info I've managed to
obtain and a with good bit of guesswork thrown in...
We'll have a trunk containing core code reused for many products. Each
product will have a branch based off the trunk (and hopefully few-to-zero
branches off branches). We'll be adding new core features to the trunk,
and currently have a product which requires a core feature which isn't
ready yet, so we'll need to merge from trunk to product branches as core
features become available. Also, I expect that after new core features
are added, the product requirements for active projects will expand to
include the new core features and a trunk-to-branch merge would occur
again.
For the reverse case, there has been discussion about how to add useful
product-specific features back into the core, so we can find ourselves
wanting to merge from branch to trunk. I think this is likely if a product
dev team adds a cool feature but hard-coded it in the branch. So the core
dev team would later merge the feature from the product branch to the trunk
then add customizations to allow build-time scalability and possibly other
changes. Also, project management may want a feature available as part of
the core so they can plan future products on specific features and to help
avoid the need for new products to branch off of existing product branches
solely to include a previous product feature yet having the side effect of
ignoring bug fixes/feature enhancements made to the core in the meantime.
>
> If you can simplify your process such that you only ever merge in one
> direction for a given branch (either into the branch or out of the branch,
> with the special exception of re-integration which causes a branch to die),
> flow of change will be much easier to understand for developers and it
> is much less likely that you'll run into merging issues in the first place.
Agreed. I'm hopeful we'll not need two-way merges often but I'm planning
for them based on the roles we've assigned to the branches and mgmt's desire
to have the capability to merge in the core-to-product and product-to-core
directions.
We've considered a no-branch approach by creating per-product directories in
the trunk and restricting product teams to changes only their directories to
remove the need for merging. However, it seems impractical since the product
teams generally work independently from the core team and have different
schedule
constraints. The idea floating around is that product teams need to
independently
make quick mods to the core areas which are valid for their product
requirements,
but not useful for every product team, and probably would be considered "changed
in the wrong place" from the core team's perspective (especially when changed
hastily during product QA and bug fixing cycles). So branches can allow our
product teams to work independently of our core teams and other product teams on
other active projects. Would be interesting to hear other ideas.
> Could you draw a diagram showing one instance of each type of line of
> history you need (e.g. release branch, main line, feature branch) and
> different kinds of arrows indicating types of merges you need to do (e.g.
> catch-up/rebase merge, cherry-pick merge, reintegrate merge)?
> Then we could work with that and think it through.
> Of course, the less lines and arrows you can get away with, the better :)
It'd be very incomplete - Translated: I'll find out what we need to do when
mgmt wants to do it :). But I'm definitely of the opinion that the fewer merges
we need to do the better.
Cheers,
Shaun
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2416858
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-12 03:16:53 CET