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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-08-01 17:02:07

Robert Ramey wrote:
> 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.

I've also been using the name "stable" for the "release ready" branch. 
And, yes, the starting point for "stable" is the current "RC_1_34_1" tag.

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

Right, although as a practical matter most developers will want to test 
against "stable".

I've been trying the following procedure for the six or eight weeks:

I've got a working copy "stable" which was checked out from the 
RC_1_34_1 tag. I'm doing some Boost.System development on a branch 
"c++0x". So I've switched the components involved (.../boost/system, 
.../boost/cerrno.hpp, .../libs/system) to the c++0x branch.

I go about testing and development as usual on my Windows machine, 
committing c++0x changes every time I want Chris Kohlhoff and Peter 
Dimov, who are helping, to be able to access work-in-process.

I've also got a mini Mac and a Linux box set up with "stable" working 
copies checked out from RC_1_34_1. I'm running a web server on those 
machines (to simulate remote machines out on the Internet.) It has a 
"test-on-demand" web page, which fires off a CGI script written in 
Python that will switch a particular library to a specified branch, run 
bjam, upload four result files to the server, and switch the library 
back to the stable branch.

So whenever I want to see if the code is working on the non-Windows, I 
sign onto the web sites, request tests be run, and have the results in a 
couple of minutes.

Although the process needs a lot of polishing, it already works well 
enough to demonstrate the value of the approach. The tools involved are 
mainly just Subversion and bjam. The same approach would work with other 
testing frameworks.

The bottom line is that I know that code works *before* it gets merged 
into the stable branch. That's the critical point; the exact way the 
testing is done is important operationally, but those details don't 
matter as far as the big picture goes.

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

Right.

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

Yes, agreed.

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

The point of testing before actually changing the stable branch is that 
regressions should become very rare.

--Beman