Subject: Re: [boost] Live read-only GIT mirrors of Boost trunk SVN
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-05-11 01:45:15
on Thu May 09 2013, Niall Douglas <ndouglas-AT-blackberry.com> wrote:
>> on Mon May 06 2013, Niall Douglas <ndouglas-AT-blackberry.com> wrote:
>> > My experience with SubGit has been very, very good. I would *strongly*
>> > recommend it over git2svn.
>> Why, have you got a lot of experience with both tools? You'd recommend
>> SubGit for what job, exactly? Does it modularize? (answer: no).
> Git2svn is painful. I think anyone who has used it even trivially has found
> it so.
> SubGit can map structure arbitrarily, so SVN branches need not become GIT
> branches, they can become tags or any other kind of git ref. You can apply
> filters and map one (or more) SVN repo to multiple output GIT repos using
> those filters, so yes it does do limited modularization.
> Is that modularization support particularly powerful? Definitely not. With
> an automated script to generate a ton load of mappings it could approach the
> capability of KDE's tool, albeit with no range specific filtering available.
> But its specific purpose is a different use case: live two-way mapping. And
> for that you necessarily have to restrict the flexibility of output, because
> they have to map in reverse.
>> We didn't choose svn2git at random: we started using it because KDE (a
>> much bigger project than Boost) used it to solve the exact same problems
>> Boost has to solve: modularization + Git migration.
> Svn2git is a completely different tool to git2svn. Svn2git is a much
> superior tool, albeit rather harder to configure (correctly).
>> You'd have to have some pretty compelling arguments, a complete plan for
>> migration and modularization, and be prepared to lead the effort
>> yourself for me to throw out years of planning and coding to use a
>> different tool. Do you really think you're making a reasonable
> I'm sorry you have read my confusion that way Dave. I would have hoped that
> after all the years we have known one another you wouldn't have interpreted
> my comments in that way.
Sorry, I didn't realize we were discussing different tools. I don't
know anything about git2svn.
> Just to be clear and for the record, I have no compelling arguments, no plan
> for migration, and I am in no way criticizing your work, your leadership,
> nor suggesting the throwing away of any planning or coding. I apologise
> unreservedly if anything in my words appeared that way. I am absolutely sure
> that you have given this the very deepest of thought and I - as always
> actually - trust your judgment. I am simply confused.
OK. I don't know how to un-confuse you, though, sorry.
>> > I think it would be quite easy to set up a live perfect Git mirror
>> > of all Boost SVN,
>> "Perfect," really? I think you are grossly underestimating some of the
>> strange ways that the SVN filesystem has been used over Boost's history.
>> From http://subgit.com/book/index.html#branches-mapping it's clear that
>> the SubGit tool isn't equipped to deal with them properly. For example,
>> there's no revision range limiting in the branch mapping, a feature of
>> svn2git that we actually *need* to use.
> Perfect for me means that HEAD and releases work perfectly. I personally
> feel little priority about perfect preservation of history.
Unfortunately for my workload, the community begs to differ.
>> > do a transition period where SVN is writeable but GIT read only, and
>> > then one day the switch is flipped and it goes the other way
>> > round. That way anyone dependent on SVN keeps on working, but without
>> > write access.
>> Again, I think a two-way mirror could be a really nice addition to the
>> existing transition plan, if someone is willing to put in the elbow
>> grease to set it up. Are you volunteering?
> We can talk about this at C++ Now next week, but if we were to coordinate
> our efforts and I have definite approval and support from Boost SC, I have
> no objection to volunteering for this.
I don't see what difference approval from the steering committee makes.
If you think it would be helpful, you can go ahead.
> There is also the matter that SubGit would probably need some money
> paid for it as a matter of good faith. I would emphasize that a
> successful two way mirror does impose substantial restrictions on the
> variety of modularization possible so long as the mirror is
> active. That probably is unacceptable to you given your apparent
Yeah, we want to get this thing over with. Thanks for the suggestions,
-- Dave Abrahams
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk