David Abrahams wrote:
on Thu Aug 23 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
on Thu Aug 23 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Wouldn't generally accepted SVN setup be:
svd/boost /trunk (same as current trunk) /tags RC_1_35_1... (snapshot when tarball is created) /branches RC_1_35 (next release in being updated) joe_shmoes_library_development .... Yes, that would be usual, and it's roughly what I was going to suggest (the tag RC_1_35_1 should be something like 1_35_1a1, because we may end up releasing multiple release candidates for a given Boost version). Is there a good reason not to follow it? This is why I asked for a rationale ;-) The two reasons Beman gave (one of which I guessed):
* To make the permissions easier to manage. (my words) * Focal point for casual browsers to find release related trees. (Beman's words)
svn/boost/
trunk/
tags/ ... release/ 1_34_1 1_35_0 ... branches/ release/ 1_35_0 ... libraries/ python/ serialization/
That would work, and avoid having two directories named trunk. OTOH it now has two directories named 1_35_0. Is there any point having two copies of the final for a release? 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/ --Beman