RE: branch creation - merge not working?

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/release2@HEAD .
should have been:
C:\TestProject\branches\software1\issue34>svn COPY https://localhost/svn/TestProject/branches/integration/release2@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: qazwart_at_gmail.com
To: lindahlb_at_hotmail.com
CC: users_at_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
qazwart_at_gmail.com
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------