Version control practices: branching, merging, releases

Michael Koch konqueror@gmx.de
Wed Mar 16 23:19:06 2005


On Wed, Mar 16, 2005 at 07:40:42PM -0500, Barry Hawkins wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Team,
> ~    Now that I have been working with and analysing some of the pkg-java
> projects for a couple of months, I have noticed something and wanted to
> bring it out for discussion.  I have been surprised by how many of the
> projects in our repository have a linear repository path with no
> branches for releases and/or experimental efforts by maintainers.  I
> wanted to see if we could talk about why some projects avoid branching
> and merging.
> ~    Having a comfort level with branching and merging in your version
> control system is something that can give increased agility and freedom
> to experiment.  I know we have all heard that, but I truly believe it.
> It certainly has been my experience in my professional life.  Two of my
> favorite authors, Andy Hunt and Dave Thomas (the Pragmatic Programmers),
> refer to version control as the "project time machine" because of how
> effective branching and tagging can give you point-in-time restoration
> of a project; I like that metaphor.
> ~    At any rate, I was wondering if some of the avoidance was simply due
> to not having done it before, or having had negative experiences in the
> past with excessive branching, etc.  I think we could derive a pretty
> effective policy for branching, tagging, and merging that could benefit
> our efforts.  The Pragmatic Programmer version control books are great
> small books thatat have recipes to show just how to do only what you
> need to in a concise manner.  The O'Reilly reference for Subversion is
> actually open sourced under Creative Commons, so if we migrated to
> Subversion, we could even use that as a standard reference that would be
> free to all.  I would be willing to draft an initial version control
> guide if the group so desired.  We could make it part of the project
> documentation on our Java Packaging site.
> ~    What are you guys' thoughts on these things?  I welcome the dialog,
> as I am only one voice and would like to see us develop some concensus
> around these items.  If this alreeady exists in the Debian
> documentation, please forgive my ignorance and point us to it.

While the above is true this practice is at least uncommon for Debian
packages. In Debian world a package normally depends on an older one.
Several branches of a Debian package are not really supported by
dpkg/apt-get.

Branching and merging is possible CVS, Subversion, arch, monotone and
others. We don't really need this feature but if we want we can with all
of them. There is no need to switch to another system just becuase its
not supported in CVS. CVS does it too. http://www.cvshome.org/ contains
a free manual that describes this.

I'm not against subversions. I really like it for some stuff where its
superior to CVS. We just need to balance the efforts with the gains we
will have.


Michael
-- 
Java Trap: http://www.gnu.org/philosophy/java-trap.html