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