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

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-01 14:27:05

Stefan Seefeld wrote:
> 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.

Hmmm - actually it does - its the RC_1_34_1 branch.  We could
just designate that as the "Current Release" (or whatever you want
to call it.

Effort required - 0

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

So, given how subversion handles branches, the cost/effort
of creating a branch for each developer's changes is 0

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

This is the missing piece.  I believe it will be available in a relatively 
short
time.  The mechanism will be tests of library x will be run on branch
y by any tester interested in doing this.  Tests can be run whenever a 
tester
wants to - but it will really only be necessary when a developer requests 
it.

The current testing on the "Current Release" can remain unchanged - though
its usually interesting only to the release manager.

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

LOL - one hell of a lot more practical than the current system whereby
everythign changes at once.  I believe that this is the most widely
accepted manner of using a system such as SVN.  Failure to employ
this practice has made life much more dificult than it has to be.

> In any case, I agree to the point that there should be relatively few,
> but coarse grained, checkins on the 'stable' branch,

Good

> which can be  backed out as a whole if any regressions occur.

I would not expect regressions of such a drastic nature that the
above would be necessary.

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

For you perhaps.  By my memory is fading as I get older.  Its much
easier for me to remember boost 1.36 than 3.1415917872348376485
But basically you're correct - a tag is a convenient naming device
to bridge the gap between our feeble brains and the computer systems
we use.

> Packaging automatically (after a successful test run) can and should
> be automated with buildbot, too.

I don't know what build bot is - but it sounds like you're agreing that
packaging the release should be an automatic process which is run
affter the global test on the current release.  If that's what your 
suggesting
I'm sure everyone will agree

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

Correct - upon request from a library developer. The release manager
would review the requests from developers, select the order he want's
to merge them in, and for each one, merge in the developer branch,
request the global testing, and invoke the release build script if he's
statisfied.

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

What's impractical is what is being done now. Thomas's accomplishment
of getting all of boost and a new build system through the eye
of a needle - all at the same time - was a heroic accomplishment.  It
is the last time that it can ever be done.

>That would create a huge bottleneck.

Its the current system which is a huge bottleneck.

> The most important  thing to do is formalize the development process as 
> far as version
> management  is concerned,

That's what I'm trying to accomplish.

> to be able to easily and quickly rollback anything that risks to 
> destabilize the stable / release branch.

Totally, Totally wrong here.

The only way to make things work is to integrate pieces in one at a time in 
digestble chunks.

Note that all this has been discussed in quite a bit of detail.  Beman made 
a pretty clear
proposal along these lines and after quite a bit of discussion, it seemed to 
have reached
a consensus.

All the points made above have been made in previous posts. I'm sure you can 
find them
if you're interested.

Robert Ramey