With Subversion 1.7 released, our company is considering more active use
of merging with the help of svn:mergeinfo. Upon reading some
tutorials/articles and thinking a bit, I can see how awareness of
svn:mergeinfo improves certain workflows, but also I see some potential
problems. I'd like to hear your comments and suggestions on the following.
We have 1 large repository of the following layout (not exactly, but
quite isomorphic):
trunk/
release/
1.0/
1.1/
2.0/
...
branches/
We have ~30 programmers, about 50 commits go to the trunk daily, from
which about one half goes to at least one release branch. Some
programmers also use private branches. Till now, most merges were done
with --ignore-ancestry (because of slowness of svn:mergeinfo in <=1.6,
among other reasons). Now we want to encourage the usage of merge
tracking. Here is the description of used workflows and my
considerations on pros and cons of merge tracking:
1) Feature branches.
User creates private branch, works on her task while merging from trunk
periodically, then reintegrates the changes to the trunk.
Pro: merge tracking allows to sync from trunk with great ease.
Cons: nothing I can think of (svn:mergeinfo is compact and consolidated,
no conflicts possible in svn:mergeinfo)
2) Merge from trunk (cherrypicking).
User works on trunk, then merges some changes to one or more branches.
Pro: svn:mergeinfo allows to see what has been merged to particular
release branch, and what wasn't.
Cons: svn:mergeinfo soon becomes bloated (even single task commits
almost never make a contiguous range), svn:mergeinfo is scattered (some
users only have access to a subtree of a release branch), svn:mergeinfo
conflicts seem very possible (many users can do merge at the same time).
3) Merge from release branch.
User debugs and fixes a bug in a release branch, then merges the bugfix
to trunk.
Pro: nothing I can think of (except no need to type --ignore-ancestry ;-)
Cons: svn:mergeinfo soon becomes bloated and scattered, svn:mergeinfo
conflicts seem very possible, very confusing svn:mergeinfo for release
branches (it might tell someone merged code from one release branch to
another, however in reality you just cut the branch after merge to trunk).
I now tend to think that merge tracking is definitely a win for 1), but
would introduce many problems for 2) and 3), without gaining us much
value. What confuses people most now is the scattered svn:mergeinfo
("Oh, why that dir has modified status, my merge shouldn't have changed
it!"). But people can be persuaded that it's "Ok". What bothers me more
is svn:mergeinfo bloated (slowness) and conflicting (major annoyance).
Maybe I'm missing something?
Your comments greatly appreciated,
Andrey Paramonov
