on Sun May 05 2013, Beman Dawes
Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost SVN commit in a Git repository. You can view the results at
http://github.com/boostorg http://bitbucket.org/boostorg
or you can pull from these repositories and view them in your local browser.
What is the story on branches and branch names?
I think I need a more precise question in order to give a good answer, but I'll do my best. You can see the mapping of SVN paths to branch names in https://github.com/ryppl/Boost2Git/blob/master/repositories.txt As mentioned in my previous posting, to understand the mapping, read https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt It's important to note that in SVN, branches persist basically unobtrusively in history. If you don't explore the tree above /trunk/ and /branches/release/, you never see them. And even if you delete them in some later revision, you can still get to them by rewinding history. For example, there's nothing here: http://ci.boost.org/svn-trac/browser/branches/unordered but you can look back into history and there it is: http://ci.boost.org/svn-trac/browser/branches/unordered?rev=42181 By contrast, you may find Git branches somewhat obtrusive. However, the usual culture with Git is to delete feature branch references as soon as they are merged to some other branch. After all, the merged-to branch keeps the commit history alive and there's no longer any need to keep the old label around. If you delete a branch without merging it, of course, any commit history exclusively referenced by that branch is lost. Therefore we are conservative, preserving all SVN branches and tags as Git refs. If branche or tags were deleted in some SVN revision, they'll be converted to Git tags with the prefix "backups/" (see https://github.com/boostorg/system/tags for examples). Otherwise, as a rule, SVN paths below branches/ are converted to Git branches and SVN paths below tags/ are converted to Git tags, but of course you can control all that via the specific mappings in repositories.txt There are quite a few paths that are being mapped to a branch prefixed with "/old-branches/". I believe that pattern is a relic from earlier modularization efforts, and is not applied consistently. However, it is one good way of making some branches less obtrusive. We could decide to automatically put any SVN branch that hasn't been touched since revision XXXX under /old-branches/, for example.
The Boost.System release branch is there, but https://github.com/boostorg/system shows 34 branches, and it looks like most of those are branches for other libraries that happened to include a Boost.System component.
Yeah, quite a few branches seem to be empty in Boost.System, for example https://github.com/boostorg/system/commit/b59e42803ca7b37e2715657ba60532f988... We've made some effort to prevent the creation of empty branches, although it's difficult; clearly what we have isn't working in all cases. I'll see what I can do about it.
I suppose Git has a way to blow the unwanted branches away from the system repo?
Blowing away branches in Git is trivial, if a little obscure: git push <remote-name> :<branch-name>
How close are we to being able to experiment with modular boost? Do we know what the updated https://svn.boost.org/trac/boost/wiki/TryModBoost instructions are?
As long as the goal is to do it with the current build system, we still need to create the submodule references in https://github.com/boostorg/boost that point to all the libraries and tools. I'm working on that now. I think the instructions "should" be pretty close to correct once we've done that, but am not certain. Daniel? -- Dave Abrahams