Boost logo

Boost :

Subject: Re: [boost] Git Modularization Review no vote heads-up
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-05-20 02:20:46


on Sat May 18 2013, Vladimir Prus <ghost-AT-cs.msu.su> wrote:

> On 13.05.2013 09:00, Dave Abrahams wrote:
>
>>> That said, the separation of libraries into separate modules with full
>>> history is looking very much improved!
>>
>> Well, I know it isn't glamorous and it doesn't satisfy the need to say "look
>> it builds," but *that* is what we're asking people to evaluate now.
>
> So what are the plans for "look it builds"? At the very least, I would prefer that
> requirement to use cmake to put together symlinks be removed. What's
> the plan for that?

Steven Watanabe is working on that. It looks like Jürgen Hunold and
Eric Cornelius may have picked up where he left off? Jürgen has asked
Eric to post about this on the boost-build list, so I presume you've
seen some of it.

> Jürgen has posted a patch that teaches Boost.Build to do that, and I can give it
> a try, but before that I think cloning of the master repository should work

It does work.

> (others already reported some issue with chrono)

I don't know what's being referred to here.

> and at least Boost.Build should have its final layout.

I think maybe I disagree. If you want to rearrange Boost.Build in SVN
before the transition, then be my guest. Modularization will capture
those changes and you'll have a corresponding layout in Git. However, I
don't think it's reasonable to build a fake *history* in Git that
doesn't reflect the way things went in SVN. That would make those
running the Git transition responsible for any adjustments required for
your preferred layout. Make sense?

> Also, what would be the process for tweaking any infrastructure code?
> Commit to SVN and wait until git mirror is updated?

That would be my preference. The mirror updates fairly quickly. If
rules or modularization code doesn't change, it's very fast (about 3.5
minutes). Otherwise, it takes about an hour, but we're not pushing
ruleset or modularization code changes very often.

> Or create a special branch/repo in git and do changes there, rebasing
> against new versions?

The process essentially clobbers and reconstructs the git repos
continuously, so if you want to work in Git using the modularized repos,
expect to have to rebase against new branch heads, and don't expect to
be able to push to the github repos.

-- 
Dave Abrahams

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk