Hi,
Doug Gregor will lead the effort, and will be the contact at IU when issues arise. Hopefully Troy Straszheim can help, given that he has already setup a Boost SVN repository.
I'd be glad to help. What concerns me most is the directory structure. Referring to the thread "Subversion experiences from the field": if boost wants to do something like that, things will indeed have to be moved around. There wasn't much discussion of this, I'm wondering what people think. There are big implications for developers (I can release versions of my library independent of the rest of boost, or in coordination with subsets of boost), release managers (who would manage a list of component libraries/versions, and would not be required to branch the entire archive for release at some particular instant in time), and users (for instance, as a user I could check out only a certain version of shared_ptr, if that is all I wanted...). Not clear to me if this is all upside, or chaos in the making; my gut feeling is that it is mostly upside but could be screwed up spectacularly if not well understood. If the consensus were to really rearrange things in the archive, one might want to get a 1.33 release out of CVS first, then immediately afterward importing thing into SVN and take one's time getting them organized. (Having done a few trial runs while 1.33 gets out the door.) Just FWIW, -t Beman Dawes wrote:
Dave Abrahams, Doug Gregor, Thomas Witt and I talked about moving to Subversion when we got together at the C++ committee meeting last week.
(I've been using Subversion on my machine for about a month, and quickly became convinced it is superior to CVS.)
Points discussed included the importance of a slow, step-by-step approach, because of the importance to Boost and to individual developers, and the need to build familiarity before diving in head first.
Some of the possible tasks to be accomplished before a final conversion:
* Research any remaining questions from Boosters regarding Subversion.
* Decide on the repository directory structure - follow Troy's lead or maybe something else? (One of the advantages of Subversion is that the repository directory structure isn't hard-wired, but that means we have to decide which approach is best.)
* Set up a trial repository, like the one Troy set up, but on the actual machine at IU.
* Set up write authorization. This might be a good time to prune the write-access list to those still active.
* Load test. (Maybe set a time, and have a bunch of Boosters hit the repository at the same time?)
* Make final go/no-go decision. This probably involves both discussion on the list and polling the moderators (as the closest thing we have to a steering committee.)
* Put change notifications in place.
* Verify that backup (tarball or whatever) procedures are in place and functioning.
* Update Boost documentation which refers to the source repository.
* Schedule and execute the actual changeover.
Comments?
--Beman
PS: The book "Version Control with Subversion" by Collins-Sussman, Fitzpatrick, and Pilato, is worthwhile, either in hard copy (O'Reilly) or download from http://svnbook.red-bean.com/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost