Re: [boost] Live read-only GIT mirrors of Boost trunk SVN

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
>> suggestion?
>
> 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
> plans.

Yeah, we want to get this thing over with.  Thanks for the suggestions,
though.

-- 
Dave Abrahams