[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Looking for ideas for a tag/release svn usage model

From: David Weintraub <qazwart_at_gmail.com>
Date: Tue, 1 Sep 2009 14:07:08 -0400

I would be careful about creating a separate "release" branch because you
end up taking pressure off of the developers about getting their code to

I believe in the "Finger o' Blame". Whenever something goes wrong, the
Finger o' Blame points to the scapegoat... I mean culprit. Right now, if the
build breaks, the Finger o' Blame swings around and points to the developer
who did the checkin. By creating a release branch, you are now personally
responsible for the code on the release branch. If bad code gets put on
there, the Finger o' Blame now points to you.

I've gone the release branch route before. What happens is that it takes
pressure off the developers to make sure their code works. If a build
breaks, they simply say they're in the middle of something important, but
they'll get it fixed as soon as they can. If you talk to their manager, the
manager will side with the developer. Why are you so concerned? The release
code is still good.

Sooner or later, either by chance, or decree (last minute fix needs to be
sent to the customer!), that release build will break, and it will be your
fault for putting bad code on the release branch. The whole shop is now in a
tizzy because a release needs to be done, and because of your incompetence,
the release can't be built.

Do you have a continuous build system like Hudson or Continuum? Those will
do a build every time a commit is done. They will also show you who did the
change, what was changed, and why. Hudson will give you a link to the last
good build artifact for testing, so QA knows where to find the build to

Hudson also reports the Subversion revision number used for the build. Many
shops use that instead of a build tag which makes updating easier because
you can simply use the revision number instead of switching to a tag. By the
way, checking out tags can be a problem because it is extremely easy for a
developer to commit changes on a tag without anyone realizing it! I have a
pre-commit hook I use that allows users to create a tag, but be unable to
actually modify that tag.

In fact, I don't even like the "switch" command because developers get
confused which branch they're working on and end up putting changes into the
wrong branch. I usually prefer if the developer creates a working copy for
each branch just because it will cause less confusion. And, with 150
Gigabyte disks, disk space shouldn't be an issue.

David Weintraub
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-01 20:08:12 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.