Hi! I'm trying to think of a usable repository layout. The features it should provide IMHO: (1) release-ready branch, which is updated by the release manager/team and includes latest additions for the next release as well as bug fixes from the last release. this one is to prepare for a major release (2) release-fixing branch, which is updated by the release manager/team and only gets bug fixes. this one is to provide support/fixes for the last release (3) a main development branch for each library in boost. this would be updated by the library maintainer. this directory should hold changesets which the release manager/team merges into (1) (4) testing branches for each library which can hold various bugfixes and which are used for testing the changes before they are merged into the release-ready (1) and release-fixing branches (2). (5) possibly branches for each library which are "private" to the library and used by the maintainer as she likes To keep (3), (4), and (5) together, I think the following directory structre would do: /libraries /iostreams /trunk (3) /branches /testing_bug143 (4) /trying_refactor (5) /serialization /trunk (3) /branches /... /tags /... (also 5) /... /release /release-1-35-ready (1) /release-1-34-fixing (2) /tags /release-1-34 /release-1-34-1 /... Library work flow: Bring /library/foo/trunk in sync with last release. Fix bugs in this trunk. Report to release manager/team: "please include /libraries/foo/trunk -c 39042 into release, its a bug fix for ticket #374". Maybe branch off from trunk of foo or from latest release in order to develop new feature. Use this branch for heavy testing, too. When ready, report: "please include /libraries/foo/branches/new_feature -r 40000:42000 into release-ready, its a new feature requested in #845". Release work flow: When receiving a "bug fix report" merge it into working copy of the release-fixing branch and do local testing. maybe include some more requests. After that "commit" and create a tarball for external testing. Committing the only locally tested state will preserve this exact state in the subversion. I think this is needed to provide a tarball and an identical copy in repository. If tests are successful try the same bug fix in release-ready branch and do the same testing. Ok. I currently don't know how testing is done exactly, but other messages on the list indicated testing each bug fix as it is merged into the release branch. This seemed to require building a tarball and giving it away for testing. I think this is a process which takes days. So how long would it take to include a couple of fixes into the release-fixing branch? How much testing is done up to today? Frank