Re: [boost] Git Modularization Ready for Review

Subject: Re: [boost] Git Modularization Ready for Review
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-05-06 11:32:10

On Mon, May 6, 2013 at 1:31 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>
> 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

One more precise question: Are we still planning to map trunk->develop
and branches/release->master?

> 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.

Thanks - that's helpful. I've added the last paragraph to
https://svn.boost.org/trac/boost/wiki/StartModWorkflow

> 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.

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.

>> 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.

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.

>> 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?

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.

--Beman