on Tue Feb 05 2013, Dave Abrahams <dave-AT-boostpro.com> wrote:
> on Tue Feb 05 2013, Eric Niebler <eniebler-AT-boost.org> wrote:
>> Now that 1.53 is done, this is a good time to move to modularized boost.
>> What's the current status of the migration?
> The clear message we got from the community was that they want
> "modularized history," approximate though it may be. We have been
> working on a system to produce that history based on the tool used by
> KDE for the same purpose
> The process is currently being run by a Jenkins installation at
> As you can see from
, there's a crash
> in the tool somewhere. Daniel has been working on debugging it.
OK, update: I fixed those problems in the tool. You can see the
modularized history [here](https://bitbucket.org/boostorg/
We're using bitbucket for this, at least temporarily, because it's able
to show multiple branches/merges at once (see, e.g.,
), which we think
may be useful for people who want to vet the conversion.
At the moment, the entire release branch and trunk (except
which we'll fix ASAP) are represented in those repositories.
We have the
needed to direct the other branches and tags where they belong, and I
expect Daniel will incorporate that information into the svn2git
we're using in the next few days.
All changes that are not otherwise-accounted-for are going into [this
the idea being that we'll know we have a complete modularized history
when that repository is empty. At the moment, most of our branches are
represented there, which is not unexpected since Daniel has not yet
incorporated the aforementioned mapping into the rulesets.
Once that is done, we should have a vetting period during which Boosters
can inspect the history of their projects and make sure they are happy
with the results, submitting pull requests on the rulesets if they wish
to make changes. If people want it, we can post instructions for running
the modularization on their local machines. I don't want to do that
unless there's demand, though.
I have a project that might help us automatically create some of the
merges in Git that either aren't represented in SVN due to sub-optimal
behavior on the part of committers (see
) for an
example), or aren't making it across in the translation due to the
limited capabilities of the svn2git tool. However, I have doubts about
the cost/benefit ratio of attempting such a reconstructions. Manually
adding a [parent
to represent the most recent merges between trunk and release in each
repository might work just as well.