Re: [boost] Git Modularization Ready for Review

Subject: Re: [boost] Git Modularization Ready for Review
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-05-06 01:31:05

on Sun May 05 2013, Beman Dawes <bdawes-AT-acm.org> 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
>>
>>     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/b59e42803ca7b37e2715657ba60532f988ab4199
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