On Tue, Sep 1, 2009 at 11:07 AM, David Weintraub <qazwart_at_gmail.com> wrote:
> 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
> work.
>
> 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.
>
The model I prefer is for the submit system to reject failing "release"
submissions and bounce them back to the developer who submitted them. Blame
isn't always very effective. In fact, I've found that the developers who
respond best to blame are also the ones who least frequently make bad
checkins to begin with. Guess it makes sense.
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
> test.
>
Nope. I'll look into these. Keep in mind this is an ASIC design
environment, where build tools tend to be very primitive. What we have now
is a primitive perl script to run a set of design simulations and count the
number of failures. All development is done on Linux machines, with builds
and simulations being farmed out to networked computers (using Sun grid
tools for job management). I'm not sure if any of these continuous
integration tools can handle such an environment natively, though of course
anything is possible with enough customization.
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.
>
Yes, this is one of my concerns about using Subversion tags they way I've
used tags in the past.
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 don't like "switch" because it's really easy to "switch" one directory
into an entirely different location, or otherwise mess up your work area.
And I agree that properly-switched directories can be very confusing.
> 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.
>
Alas, disk space always seems to be an issue in the ASIC world. Developers
work on network filesystems, so you can't just stick a 500GB disk in their
desktop machine and be done with it. Simulations aren't interactive, which
means they dump massive log files in your work area. Every design company
I've worked for has battled disk space issues, with one of the big problems
being multiple trees in user directories. In a prior company that will
remain nameless, the default user disk quota was only large enough to build
and run simulations in a single branch. You could double that space with
manager approval, but it was still tight...
-Brett
--
Brett Coon - brett.coon@gmail.com - http://brettcoon.smugmug.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389889
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-01 21:13:05 CEST