Re: [boost] Git Modularization Ready for Review

on Mon May 06 2013, Beman Dawes wrote:

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

...

...

...

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

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