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