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

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-04 12:38:49

Stefan Seefeld wrote:
> Robert Ramey wrote:
>> Stefan Seefeld wrote:
>>
>>> This logical and technical separation between A and B is the kind of
>>> modularity I have in mind. Whether that actually leads to separate
>>> release cycles for A and B is an entirely different (and to the most
>>> degree non-technical) matter.
>>>
>>> And I believe something similar is what Robert was alluding to when
>>> talking about "running development tests on our local system against
>>> the latest release". Correct ?
>>
>> Correct.
>
> Well, you didn't tell us how you do that. Building a library against
> an external boost tree (installed or not) isn't quite supported yet.
> Have you modified boost.build locally to fit this purpose ?

Its amazingly simple.

Here is how I currently do it.  I havn't switched over to SVN yet so
its couched in terms of CVS.

I synced my local CVS with RC_1_34_1 branch.  I did this starting
at the root so my whole system as on this branch.

I use CVS to switch three directories libs/serialization, boost/archive
and boost/serialization. to the HEAD which has been the current
boost practice.  Strickly speaking, this isn't necessary until I try
to check something it.  But doing it now prevents me from later
checking in changes to the release branch which I once accidently
did.

I run tests from inside libs/serialization/test using the short
script described in the previous email.  This builds required
libraries, builds the serialization library, runs all the tests
and updates the table of all the latest results.

Edit source code and repeat as necessary.

When my results table is noticibly improved I check in
to the HEAD in accordance with current boost practices.

When I get a set of local test results (against the current
boost release) that I like, I'll post the versions of the
cited three directories as zip file on my web site.  That
way anyone who want's the version with "no known bugs"
can get that and I'll only have to deal with newer issues.

This will cut the time down between time of discovery
of a bug or implementation of a small enhancement to
around 30 days rather than 1 1/2 years as it is now.

Sooooooooooooo  This is the context of my original
question about "Best Practices for SVN".  I've been using
SVN on my local machine for a few weeks and find
it to be quite good.  Though CVS was good enough
for my purposes, I do find SVN easier to use, better
documented, etc and all around better.  So I'm happy
about the change.  It's not enough to have a new tool.
One has to decide on the best way to employ it for
his situation - I spend a little time doing that and it has
helped me alot.

Robert Ramey

>
> Thanks,
> Stefan