On Wed, Nov 11, 2009 at 06:14:30PM -0800, Shaun Pinney wrote:
> > 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.
This is not gonna work. Well, it can be made to work, but you and your
team will have to do the heavy lifting. It will be a time sink.
The reason is that Subversion's merge isn't a magic device that can
pull entire features from one branch to another for you.
This may be what management thinks it is, but it's not.
Subversion's merge...
1) ... assumes that tree structures on both sides match -- if they don't
you get conflicts flagged and you have to sort them out *yourself*
(we want to add auto-resolution for trivial cases but it will still
take us time). You wanna do refactoring for your new feature? You'd
better talk to the other teams first, and try to break down the
refactoring into several steps that fit into a human brain, and which
you can merge to other branches without disrupting them.
Once you do a merge which says
Tree conflicts: 245
at the end, it's already too late. Even more than 10 is already
really annoying to sort out.
2) ... distributes merge tracking information across the entire tree.
This makes it very powerful because it allows you to do very
fine-grained merges and still have them tracked. E.g. you can merge
changes made in rX to foo/bar.c on monday and changes made in rX to
bloo/baz.c on wednesday, and Subversion will automatically track what
you've done. Not even merge-focused distributed version control
tools like git support this, you can only track entire-revision-merges
there. But this flexibility comes at a price.
If you use it too much, you get a lot of meta data everywhere and it
tends to travel from one branch to another as you do your merges.
with all the mergeinfo everywhere it gets hard to understand what
happened, both for users and for Subversion. User errors can cause
holes in the meta data, causing more confusion down the road. People
do merges which modify meta data on files they've never even touched
on their own branch. If they do commit those property changes, they
cause more subtree merginfo noise, if they don't, they cause holes in
the meta data. Performance drops sharply. To avoid these situations
you need to educate users (sometimes this is the hardest part), and
regard any merge that creates subtree mergeinfo (i.e. anywhere except
at branch roots) with great suspicion. It should be the exception rather
than the norm, and there should be a really good reason for it.
We're avoiding this ourselves, e.g. see the NB note here:
http://svn.collab.net/viewvc/svn?view=revision&revision=40458
There are many who fall into these traps, and they end up hating
Subversion. The problem is that you aren't using the tool correctly
if you don't recognize its constraints and adjust your own use of the
tool to these constraints. Just because the tool allows you do to
diverge from best practices does not mean that you should do so on
a regular basis.
> 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.
Don't push this complexity into the version control tool.
Put it into a build tool like Maven, or into program/library
relationships. If you can't understand what code is where and why,
your version control tool probably won't understand that either.
> > 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.
Why does management have that desire? Because "merge the feature from
core to product" sounds so much more 2009 than "make core a library
with a separate release cycle and design your products as a consumer of
this library"? The latter sounds like more work for the engineers on the
surface if you assume that merge works magically. But it is *less* work,
not more, in the long run.
The version control tool exists to track file content for you.
It does not exist to track "features".
> 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.
Stop treating core as something special. It's just another component of
your systems, with its own release cycle.
Just take an extreme example that goes against your current plans:
What about putting core into a separate repository?
You can design a development process that works great even if you do this!
Just imagine what that really means for a second. You cannot merge from
core to product, just like you cannot merge to or from code you get
from third party suppliers. This can be a good thing because it reduces
complexity, since everyone knows what code is where and why.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2416990
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-12 12:31:57 CET