Ryan - thanks for the help. I had read the manual from cover to cover,
but I had read an older version which didn't contain this information. I
really appreciate the references.
John
-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.
>>> Ryan Schmidt <subversion-2006Q1@ryandesign.com> 3/9/2006 2:43 am
>>>
On Mar 9, 2006, at 07:09, John Calcote wrote:
> I'm sure this question has been answered on this list before, but I
> can't get the archive search to work (at least it said there were
> NO messages in the 40000+ message archive that contained the word
> "branch" in the subject!), so I've decided to just ask:
The Tigris archive search feature doesn't work very well. Everyone
uses the Haxx archive whose search uses Google:
http://svn.haxx.se/users/
> I work on a team where we have been using CVS and are now
> converting to SVN. In the past, we used CVS branches to manage
> multiple versions of a product. Developers would continue to update
> and enhance each release of the product on its own branch.
> Occasionally, when a version was end-of-lifed, or for other
> reasons, a product version branch might be merged back into the
> HEAD (to use the CVS vernacular), however, for the most part,
> branches were simply continued until they were no longer viable
> entities in the market place, at which point, development just
> stopped on that branch.
>
> Now, I happen to know from working on open-source projects that
> this is fairly common practice in the CVS world (eg., see the CVS
> repository for the PHP project). But all of the documentation I've
> read on subversion indicates that this form of branching is simply
> not done. The manual indicates branches should be used to manage
> trunk line development by multiple developers. Even the best
> practices document states:
>
> Know when to create branches - This is a hotly debated question,
> and it really depends on the culture of your software project.
> Rather than prescribe a universal policy, we'll describe three
> common ones here.
> The Never-Branch system...
> The Always-Branch system...
> The Branch-When-Needed system...
>
> There is no mention here of using branching for product versions.
> It's all about efficient trunk development.
I wasn't aware of the best practices document. Took me a minute to
find it. You appear to be talking about this document:
http://svn.collab.net/viewvc/svn/tags/1.3.0/doc/user/svn-best-
practices.html
It doesn't appear to have been modified significantly since it was
added to the repository in April 2004, and the section you're talking
about has not been modified at all since then. The document still
talks about limitations of Subversion 1.0. Doesn't sound very up-to-
date to me.
I recommend you read the book instead. The Branching and Merging
chapter has a section on Common Use Cases which describes two
different types of branching: release branches and feature branches.
You're talking about the former, while the best practices document
only seems to address the latter. Here's the section in the book:
http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.4
Received on Thu Mar 9 17:55:52 2006