Re: [boost] [SVN]Best Practices for developers using SVN

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-08-01 13:47:33

Robert Ramey wrote:

> a) designate an branch/trunk as the "Current Release".

That's what I'm referring to as 'stable'. The question is
what that gets created from, since it doesn't exist, yet.

> b) ALL development occurs on branches.

I'm not sure what that means, given how subversion handles
branches. The difference between 'trunk' and 'branches/something'
is only in the naming.

> c) Testing is applied to branches as requested.

I believe how test runs are triggered most efficiently depends on
the usage patterns. Ideally (i.e. with infinite resources), test runs
would be triggered on each change. If that isn't possible, alternative
approaches can be chosen, such as 'no earlier than x minutes after
a checkin', to allow developers to make multiple connected checkins
in a row (though with subversion there shouldn't be any need for that,
in contrast to cvs). Or, "triggered by checkins but no more frequent
than once per day". Etc.
(See http://buildbot.net/repos/release/docs/buildbot.html#Schedulers)

> d) At the discretion of the release manager, Development branches
> are merged into the "Current Release" and the whole system is tested.

Does this imply that each individual feature (as defined by something
that is meant to be merged into 'stable' as a whole) will be developed
in isolation, on its own branch ? I'm not sure how practical that would be.

In any case, I agree to the point that there should be relatively few,
but coarse grained, checkins on the 'stable' branch, which can be backed
out as a whole if any regressions occur.

> e) Each time the "Current Release" test passes more tests than the
> previous one, A tag is added by the release manager and a new
> download package is automatically created.  I would anticipate this
> happing about once/month.

As above, I'm not sure what the tag is good for, with a repository that
has atomic / global revisions. Just remembering the revision number that
contains a new feature the first time should be sufficient.
Packaging automatically (after a successful test run) can and should be
automated with buildbot, too.

So, in this light, the release manager's job would be to decide which
patches / features to merge from development branches to stable, based
on the current release's life cycle.

> If you had nothing else to do, you could make the "Current Release"
> /main/trunk etc ONLY updateable by the release manager.  Who would
> do this by merging in branches which have passed their tests. Then
> we'd be in business

Actually I don't think it is practical to have a single person do
all this. That would create a huge bottleneck. The most important thing
to do is formalize the development process as far as version management
is concerned, to be able to easily and quickly rollback anything that
risks to destabilize the stable / release branch.

Thanks,
                Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...