I appreciate your zealot for a different workflow. However, I've found a
substantial improvement in productivity and tracking by adopting the workflow
we use now over the workflow you suggest - we did start with an almost
identical workflow. Granted, the small commercial and open source environment
(most users of Subversion?) is very different from our work environment
(aerospace - we're not one of the big 3). However, I don't wish to pollute the
mailing list with pedantic squabbles over which is 'better' and will leave it
at this: our needs are just different.
For those that have run into this same problem: it took me most of the day to
realize the small (but important!) mistake that I had made: 'svn merge' is not
the way to create a branch, 'svn copy' is the way to create a branch.
C:\TestProject\branches\software1\issue34>svn MERGE
https://localhost/svn/TestProject/branches/integration/relea...@head .
should have been:
C:\TestProject\branches\software1\issue34>svn COPY
https://localhost/svn/TestProject/branches/integration/relea...@head .
Once I switched to using 'svn copy' for branch creation, our workflow works
just fine in Subversion 1.6 and this product appears to meet our needs. This
revision graph shows a that a branch-heavy works just fine:
http://img801.imageshack.us/i/65330015.jpg
Thanks,
Brian
Date: Fri, 17 Dec 2010 13:39:01 -0500
Subject: Re: branch creation - merge not working?
From: qazw...@gmail.com
To: linda...@hotmail.com
CC: users@subversion.apache.org
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
qazw...@gmail.com
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
