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

Subject: Re: [boost] Live read-only GIT mirrors of Boost trunk SVN
From: Niall Douglas (ndouglas_at_[hidden])
Date: 2013-05-09 12:41:49

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

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.

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

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

Niall

---
Opinions expressed here are my own and do not necessarily represent those of
BlackBerry Inc.