David Abrahams wrote:
on Thu Aug 23 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Wouldn't it be potentially less confusing for the release manager to move 1_35_0 from svn/boost/branches/release to svn/boost/release at the time of release? And since there would only be one release work-in-progress directory at a time under branches/release, the release level could be eliminated.
So after 1.35.0 ships, the tree would look like:
svn/boost/
trunk/
tags/ ... release/ ... 1_34_1 1_35_0 branches/ 1_36_0 libraries/ python/ serialization/
Sounds good to me.
This sound good to me as well. I do have a couple of observations To me - the "release" in tags/release is redundant so it could just as well be tags/ 1_34_1 1_35_0 .... The branches is fine as well. BUT it requires some explanation for users. I've been only recently learning how to use SVN to good advantage. I've been practicing on my own machine with my non-boost projects. a) Using the SVN interface with windows is veeerrrryyy slick. But like all slick stuff its not quite as easy as it first appears so when you want to do something you haven't done before you can get it wrong the first time. In my case, I made a branch of the whole RC_1_34_0 as it looked like making a branch of just one library would result in an SVN "branch" structure which didn't map exactly to the directory structure. Since SVN uses "cheap copy" this didn't have any big impact but now I see that it would have been simpler to do it differently. So a short explanation of how developers should do this would be helpful. I think that this has been covered in the emails but a short "SVN usage recommendations" would be helpful. Also I think following the common SVN pattern is a good idea if possible. b) I'm thinking that the tagged versions should be locked to prevent someone from accidently checking in any changes to them. Again I made such a blunder in the past. I think this is easy to do with SVN Robert Ramey