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

From: Phil Richards (news_at_[hidden])
Date: 2007-08-01 14:51:17

On 2007-08-01, Stefan Seefeld <seefeld_at_[hidden]> wrote:
>  Robert Ramey wrote:
> > 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.

It means, I suspect, that the branch called "trunk" (or "stable", or
whatever) is the one from which releases are made, and only things
approved by the release manager can be merged on to it.

Therefore, to do development, it must be done on another branch.

Yes, it is just a matter of naming, but the branch named "trunk" *is*
special simply because of what it is being used for...

Of course, my understanding might be flawed :-)

> > 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.

It works fine on other projects - including the ones I work on in my day
job.  It is a very simple way of adding large chunks of functionality to
a release branch without breaking it, or, at least, not breaking it in a
way that can't easily be reverted.

The main thing to do is make sure that people working on the branches
either keep the branches short lived *or* they stay up to date with the
"trunk" (release branch) by periodic merging from it.

> > 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.

Because tags are more readable and understandable than revision numbers
when you are looking for Boost 1.35.0?  If you have a choice of telling
people to check out r15647 or boost-1.35.0, I know which one I'd go for.
And, if it is ever decide to move from SVN in the future, it makes
that process easier.

> > 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.

And this is a good point.  The job of the release manager should not be
to do the merge - the code being "delivered" on the branch should
basically be completely up-to-date with the trunk, so, to all intents
and purposes, whatever is on the branch will become the contents of the
trunk.  (Again, this is what is mandated in my day job.  The full tests
are run on the branch, and if they pass, over to the trunk it goes.)

This means that all the release manager needs to do is coordinate
the order of deliveries to the trunk, and perform the final "replace
trunk code with branch code" operation.  There would be no merging, as
such.

phil
-- 
change name before "@" to "phil" for email