Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-03 18:24:47


Vladimir Prus wrote:
> Stefan Seefeld wrote:
>
>> Robert Ramey wrote:
>>
>>> We're running development tests on our local system against
>>> the latest release. There is currently no real value in creating
>>> a branch because that branch is never going to get tested
>>> anywhere besides one's local machine anyway.
>>
>> How does this actually work ? I have been proposing changes to
>> Boost.Build (v2) to allow an individual library to be built / tested
>> against an installed (or at least, external) boost tree providing
>> the prerequisites.
>
> Err, what changes do you want and why:
>
> svn sw <some-branch>
> <regular testing procedure>

That's what I'm doing now.

I'm not sure what <regular testing procedure> contains - but the
closest thing I've found is Rene's runtest.sh script in
regression/tools/ and basically Its fine as far as it goes. I
want a different report - see other post. I'm not crazy
about having to edit the environmental variables for each
installation. But these are minor quibbles. I"m using a variation
of this now. It just needs to be tweaked and documented
so that users can validate thier own installations.

> is not adequate?

So all this is fine- the only thing I can't do is use it to
test my library with someone elses compiler on their machine.

Of course that will soon change. If I develop on the branch
all I will have to do is to ask a tester - to switch to the branch
and run test for the serialization library. I am expecting for a
solution to this to spontaneously appear at any time.

So we will be there regardless of what happens to the
current trunk

I had thought I read that we were going to start with
RC_1_34 and I was just hoping for some sort guidence and / or consensus
as to branching an naming. Questions like:

a) should branches be made off of RC_1_34 root or from
the library directories themselves. I think its the former but
my SVN experience is a little sketchy here.

b) Is there a way to do a read only checkout of a the
release branch and the switch the checkout of the directories
I'm working with to read/write. This to avoid accidently
checking in a change I didn't mean to. Or accdently
checking back into the wrong branch.

c) Would it convenient to adopt some sort of naming
convention like"serialization_next" ... for branches of each library?

d) Would the "development branches" stay around after
being merged into the Next Release branch. I would think
it convenient that they would (afer applying a tag) but there
may be a reason why his wouldn't be a good idea.

e) Suppose I wanted to check in some small changes into
something which is outside the serialization library. Currently
I would like to check in the source to my Library Status
program along with scripts and instructions for running it
to the web page. I previiously asked if anyone had any
object to this and got no answer, so it should be OK. Of
course now I don't know where I would check such a thing
in. If Doug wants to resurrect the trunk - I could well
check it in there - But then I would be subjected to the ridicule
of my peers - with some justification. But there is no branch
for boost/../// regressoin and I'm sort of relucant to do this
since as things stand now, it wouldn't get tested or integrated.

Regardless of what happens there is still some value on
agreement/suggestion as to what practices/policies should
be used with the new SVN system.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk