Wow! Were you once a ClearCase user? This is exactly how ClearCase or a
distributed version control system would work.
Subversion merges are problematic. In fact, I know many sites that simply
refuse to merge stuff. Instead, they just manually apply the changes. You
have to know when to use and not to use the --reintergrate parameter.
That said, when you merge from branch "A" to branch "B" and then merge
branch "B" to Branch "C", new files are not always created because of the
way Subversion tracks changes. What you need to do is merge Branch "A" to
branch "B" and then merge Branch "A" to branch "C".
What you might want to understand is how Subversion's branching scheme was
designed to work. Subversion is built to borrow the CVS workflow. It works
somewhat like this:
* All users work on a single branch. In many sites, this is "trunk".
* When you are nearing release time, many sites will branch from "trunk" to
a "release branch". This way, one group of users can continue working on new
features of your project on trunk while another group of users can work on
getting the branch ready for release. If there is merging, it is usually bug
fixes that were discovered on the branch, implemented in the trunk, then
merged to the release branch. Subversion handles this type of merging
with aplomb. You can merge your changes the other way, but you'll need to
use that --reintegrate command line switch.
* When the software is released, the tagging is done, the release branch
(not the trunk) is copied to the tags directory.
The reason I said it sounds like your a ClearCase user is that you describe
more or less the way it is done via ClearCase UCM and how most sites
implement base ClearCase. I've joked that ClearCase combines all the
problems of a distributed version control system (developers working in
their merry ol' world with lots of patching/merging going on), and all the
disadvantages of a centralized version control system (heavy network
traffic, single point of failure of the repository, etc.).
For example, why do you merge everything back to trunk? It contains nothing.
No one does any work on it. What does trunk represent to you? The latest
release? That's what the tags directory is for. But, I've seen so many sites
do the same thing. The answer they give is always the same: "This way trunk
only has released code on it." But, no one can explain to me how is this
important.
I blame PowerPoint. Someone comes up with some goofy branching scheme
because it looks good in PowerPoint, and then realizes that trunk isn't
doing anything. So, they draw one arrow back from the branch to trunk. All
the arrows line up nice and neat and all the little boxes are in order.
I was trained as a CM on ClearCase, and I bought the idea of development and
integration branches because that's how it is suppose to be done! Sure, I
spent a ton of time running around and pestering developers to merge their
work back into the "integration branch", and we always had big merge
conflicts and someone always delivers a few gigabytes of changes in the last
minute, but that's how development is suppose to work. Right?
When I started working for a shop with about 4 dozen developers spread out
all over the world using CVS, I was shocked. There's no way this would work.
Everyone using trunk? What about developer branches? How can a developer
make changes if other developers are changing trunk all the time?
When I saw how the whole process worked, I was in an immediate funk because
I suddenly realized that this group really didn't need me running around any
more and pestering them. What is a CM suppose to do besides be a pain in the
butt?
It took me a while to learn that if I'm not spending 8 hours each day
pestering developers and trying to fix broken merges, I can do all the other
CM things I never had time to do. Since then, I've been an advocate of
the Benign Neglect school of CM management: Do things the easy way. The
simpler the better. Why branch? Be happy!
--
David Weintraub
qazwart_at_gmail.com
Received on 2010-12-17 19:39:40 CET