Re: [boost] Git Modularization Ready for Review

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 <bdawes-AT-acm.org> wrote:

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

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

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

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

I don't know either.

-- 
Dave Abrahams