You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John Calcote <jc...@novell.com> on 2006/03/09 06:09:27 UTC
branching as a product version strategy
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:
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.
Can anyone indicate how to transition a CVS project that uses product
version branches to SVN properly?
Thanks in advance.
-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.
Re: branching as a product version strategy
Posted by eg <eg...@gmail.com>.
John Calcote wrote:
> 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
>
You might also want to check out William Nagel's book on Subversion. It
has some real world case studies that may cover some of these issues too.
For details on the book and a pointer to downloads of it, see:
http://svn.haxx.se/users/archive-2006-01/1204.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: branching as a product version strategy
Posted by John Calcote <jc...@novell.com>.
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 <su...@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
Re: branching as a product version strategy
Posted by Ryan Schmidt <su...@ryandesign.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org