Boost logo

Boost :

Subject: Re: [boost] Git Modularization Ready for Review
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-05-07 00:36:32

on Mon May 06 2013, Beman Dawes <> wrote:

> On Mon, May 6, 2013 at 1:31 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>> on Sun May 05 2013, Beman Dawes <> wrote:
>>>> 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
>>>> 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
>> As mentioned in my previous posting, to understand the mapping, read
> One more precise question: Are we still planning to map trunk->develop
> and branches/release->master?

Presently, as you can see, the mapping is trunk->master and
branches/release->release. It could be easily changed, and I think that
might be a very good idea because otherwise we have to do a bulk branch
rename, which could cause havoc with developers. Daniel felt that the
branch names should reflect the names we've used historically, but I
think I disagree with him on that. I think there's too little benefit.
Daniel, shall we argue? :-)

>> 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:
>> but you can look back into history and there it is:
>> 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.
> Thanks - that's helpful. I've added the last paragraph to
>> 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
>> 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.
> That might be worth doing if it isn't too much work. Maybe XXXX could
> be the revision that corresponds to say one year ago, or maybe 18
> months ago to be a bit more conservative.

I think it's probably doable. Another thing we might consider is mapping
them to tags/old-branches/...

These things are fairly easy to adjust.

>>> The Boost.System release branch is there, but
>>> 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
>> 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.
> Seems like it would be helpful.
>>> 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>
> Good, and even easier with Jonathan's later suggestion.
> For a simple library like system, I'm only really interested in
> develop and master branches.

Hopefully we'll be able to automatically prune the irrelevant ones, but
if not, it's easy to write a script to prune everything but a set of
specified branches. We can give that out to maintainers and they can
make their own choices.

>>> How close are we to being able to experiment with modular boost? Do we
>>> know what the updated
>>> 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
>> 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?
> There was a tentative change to the current build system that would
> allow b2/bjam to handle the "cmake -P forward_headers.cmake" step. I
> don't know if that change was ever finalized. If not we will have to
> pester the Boost.Build folks to get it working.

I don't know either.

Dave Abrahams

Boost list run by bdawes at, gregod at, cpdaniel at, john at