Comments on: Best practise when handling tags and branches (using subversion) http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/ What I encounter in my software part of life is in danger of being commented upon here Thu, 20 Nov 2008 21:31:00 +0000 http://wordpress.org/?v=2.6.3 By: Clay McCoy http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-22 Clay McCoy Wed, 19 Mar 2008 15:31:21 +0000 http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-22 I'm always surprised that the Subversion convention of trunk/tags/branches top level directories is still considered a best practice. Especially when there is nothing fundamentally different about tags and branches in this case. They are both just copies that can be committed to. I'm constantly surprised how few people realize this, and how the Subversion culture enforces this misunderstanding. The only way to have a true immutable tag is to reference the revision number. Doing this with svn:externals or piston is a nice way to group specific versions of projects for a release. So the main Subversion best practice that I recommend is to use revision numbers more. Use them for tags, since it is the only way to really lock down what you are depending on. Use them for internal release numbers for similar reasons rather than coming up with an alternate numbering strategy (which I have never seen work). Use them for your build. Or use an SCM solution that has real tags and branches (among other advantages) like Git. I used to work with a guy who didn't understand SCM (even though it was his job). He would constantly call for code freezes when he wanted to do a release. He never understood why I would get frustrated with him for expecting the developers to actually stop developing because he didn't understand how to manage the SCM appropriately. I’m always surprised that the Subversion convention of trunk/tags/branches top level directories is still considered a best practice. Especially when there is nothing fundamentally different about tags and branches in this case. They are both just copies that can be committed to. I’m constantly surprised how few people realize this, and how the Subversion culture enforces this misunderstanding.

The only way to have a true immutable tag is to reference the revision number. Doing this with svn:externals or piston is a nice way to group specific versions of projects for a release.

So the main Subversion best practice that I recommend is to use revision numbers more. Use them for tags, since it is the only way to really lock down what you are depending on. Use them for internal release numbers for similar reasons rather than coming up with an alternate numbering strategy (which I have never seen work). Use them for your build. Or use an SCM solution that has real tags and branches (among other advantages) like Git.

I used to work with a guy who didn’t understand SCM (even though it was his job). He would constantly call for code freezes when he wanted to do a release. He never understood why I would get frustrated with him for expecting the developers to actually stop developing because he didn’t understand how to manage the SCM appropriately.

]]> By: Bram Bruneel http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-9 Bram Bruneel Mon, 17 Mar 2008 11:47:35 +0000 http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-9 Hi, When I release, I branch from the trunk into a <em>major.minor</em> branch. This way I can adjust my pom.xml in the branch so it has the correct release scm urls and more importanly a correct version id, one without SNAPSHOT. Modifying the pom.xml in a tag is not really clean. When that is ok I tag (<em>major.minor.bugfix</em>) from my branch. All bugfixes are then done on my branch or merged into the branch. After one or more fix(es) are in the branch you can tag again. Regards, Bram Hi,

When I release, I branch from the trunk into a major.minor branch. This way I can adjust my pom.xml in the branch so it has the correct release scm urls and more importanly a correct version id, one without SNAPSHOT. Modifying the pom.xml in a tag is not really clean.

When that is ok I tag (major.minor.bugfix) from my branch. All bugfixes are then done on my branch or merged into the branch. After one or more fix(es) are in the branch you can tag again.

Regards,
Bram

]]> By: jeyben http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-8 jeyben Sun, 16 Mar 2008 07:02:12 +0000 http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-8 You are so right. As I write In the section 'branching': <blockquote cite"">... Do so from your release tag.</blockquote> but my example doesn't match my words. I have corrected it. You are so right. As I write In the section ‘branching’:
… Do so from your release tag.

but my example doesn’t match my words. I have corrected it.

]]> By: Tech Per http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-7 Tech Per Sat, 15 Mar 2008 20:25:09 +0000 http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-7 Good post, I agree with most of it. The example on branching is not that educational, as it copies from trunk into 1.0-bugfix. It would have been more educational to show copying from the tag 1.0.0 to 1.0-bugfix. Good post, I agree with most of it.

The example on branching is not that educational, as it copies from trunk into 1.0-bugfix. It would have been more educational to show copying from the tag 1.0.0 to 1.0-bugfix.

]]>