Comments on: Guide And Best Practices For Subversion Branching http://devnulled.com/content/2006/10/guide-and-best-practices-for-subversion-branching/ devnulled provides news, tips, resources, and articles about various topics that software developers and engineers enjoy. Sat, 30 Aug 2008 01:47:49 +0000 http://wordpress.org/?v=2.5.1 By: Spike http://devnulled.com/content/2006/10/guide-and-best-practices-for-subversion-branching/#comment-30775 Spike Tue, 31 Oct 2006 05:41:21 +0000 http://devnulled.com/content/2006/10/guide-and-best-practices-for-subversion-branching/#comment-30775 Yeah, that's in line with my experience, in some cases it causes more problems than it solves, but for distributed development, especially where the project has different teams that work semi-autonomously, it can be very useful which is why I mentioned it. Yeah, that’s in line with my experience, in some cases it causes more problems than it solves, but for distributed development, especially where the project has different teams that work semi-autonomously, it can be very useful which is why I mentioned it.

]]> By: Brandon Harper http://devnulled.com/content/2006/10/guide-and-best-practices-for-subversion-branching/#comment-30740 Brandon Harper Mon, 30 Oct 2006 21:54:14 +0000 http://devnulled.com/content/2006/10/guide-and-best-practices-for-subversion-branching/#comment-30740 Thanks for the link Spike, I hadn't seen that before (especially being a VSS convert). As for a bit of irony, we actually started off doing the "<a href="http://computing.ee.ethz.ch/sepp/cvs-1.10-to/cvsbook/main_toc.html#TOC88" rel="nofollow" rel="nofollow">Flying Fish</a>" method of branching listed on that site and found it very troublesome because of all of the commits occurring in many different places, as well as not being able to see the full, incremental history in trunk. I suppose with as with all things technology related, the right answer starts off with "it depends"; I thought I'd just pass on something I thought was good as well as some personal experiences and observations. Thanks for the link Spike, I hadn’t seen that before (especially being a VSS convert).

As for a bit of irony, we actually started off doing the “Flying Fish” method of branching listed on that site and found it very troublesome because of all of the commits occurring in many different places, as well as not being able to see the full, incremental history in trunk.

I suppose with as with all things technology related, the right answer starts off with “it depends”; I thought I’d just pass on something I thought was good as well as some personal experiences and observations.

]]> By: Spike http://devnulled.com/content/2006/10/guide-and-best-practices-for-subversion-branching/#comment-30731 Spike Mon, 30 Oct 2006 20:56:30 +0000 http://devnulled.com/content/2006/10/guide-and-best-practices-for-subversion-branching/#comment-30731 There are many ways to approach branching and use it heavily to the benefit of your projects. I have used the flying fish approach on several projects and found that it removes some problems common to most revision control systems. Most notably, the ability of each developer to tag, track and commit on their own branch without worrying about how it will affect others. Merging becomes a more involved and complex process, but the benefits can outweigh that; particularly if you are working with a distributed development team who aren't always within easy access if something is wrong with the code they committed the night before. There's a good section in the "Open source Development with CVS" book dedicated to the discussion of branching. It includes a good description of flying fish and a couple of other approaches. Although the book is written for CVS, the branching chapters apply equally to Subversion. Here's a link to save you the time of googling for it: http://computing.ee.ethz.ch/sepp/cvs-1.10-to/cvsbook/main_84.html#SEC84 There are many ways to approach branching and use it heavily to the benefit of your projects. I have used the flying fish approach on several projects and found that it removes some problems common to most revision control systems. Most notably, the ability of each developer to tag, track and commit on their own branch without worrying about how it will affect others. Merging becomes a more involved and complex process, but the benefits can outweigh that; particularly if you are working with a distributed development team who aren’t always within easy access if something is wrong with the code they committed the night before.

There’s a good section in the “Open source Development with CVS” book dedicated to the discussion of branching. It includes a good description of flying fish and a couple of other approaches. Although the book is written for CVS, the branching chapters apply equally to Subversion.

Here’s a link to save you the time of googling for it: http://computing.ee.ethz.ch/se.....html#SEC84

]]>