Re: [boost] [git] [conversion] Schedule and remaining showstoppers?

Subject: Re: [boost] [git] [conversion] Schedule and remaining showstoppers?
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-10-15 19:38:58

On 10/15/2013 08:41 PM, Niall Douglas wrote:
> On 15 Oct 2013 at 13:59, Beman Dawes wrote:
>
>>> I agree about switching just after a release, but it's not ready for
>>> primetime yet IMHO.
>>
>> Is that a general concern, or are there specific issues you are worried
>> about?
>
> It's the hideous complexity of doing a perfect conversion, not
> specific issues.
>
> One way I have not previously mentioned here is rebuilding the
> existing SVN repo to rectify unfortunate historical commits which
> make perfect git conversion very hard. I know Dave is opposed to this
> solution, and it certainly launches yet another new tool for
> converting SVN to cleaner-SVN. But it might be less work overall.
>
>>> I would really *strongly* advocate a period where the SVN repo is
>>> used for write only, but the git repos are used for everything except
>>> writes. Boost2Git has been designed exactly to do that. We should
>>> take advantage of it.
>>
>> How would this work? As a Boost developer how could I use the git repos for
>> my libraries if I can't write to them? How can I use the svn repo if I
>> can't read from it?
>>
>> I have a fuzzy idea of what you are suggesting, and am interested, but
>> would need to hear specifics of how it could be made to work in practice.
>
> Sure. I'll think aloud here, it may or may not be useful.
>
> Option 1:
>
> I'm thinking that because git is distributed, a Boost developer can
> merrily commit to their local git without issue. However when one
> goes to push to origin, a *locally installed* hook script converts
> the push into a diff patch, and sends that to svn instead.
>
> I'd make it locally installed rather than remotely installed because
> such a push converting hook script is inevitably brittle, and only
> those who really know what they're doing should engage.
>
> Disadvantages: Only the brave will bother which reduces number of
> testers.

Boost2Git changes history in resulting git repositories which invalidate 
any "local" git repositories you are working in.  So as long as the 
conversion scripts are active, it will be a-lot of noise and complexity 
if you attempt to get work done in Git.  Sorry I don't think this is a 
very viable approach.

> Option 2:
>
> Add the metadata to allow subgit (a tool which implements
> simultaneous svn and git commits) to work with the Boost2Git output.
> Pushes to git are therefore mirrored by subgit into svn. We'd add a
> post-push hook to subgit to undo any changes by subgit to the git
> repo, letting the daily Boost2Git cron job do the mirror instead
> (unless Boost2Git is upgraded to implement delta updates).
>
> Disadvantages: Would need more work to implement subgit metadata
> output. Need to buy a subgit licence (they may give one for free in
> exchange for publicity). Users may be confused if git pushes don't
> immediately turn up in git origin. git push times are likely to
> become tens of seconds.

Can subgit deal with history changes caused by Boost2Git?

> Option 3:
>
> Instead of doing an all-or-nothing SVN to Git conversion, we
> gradually transition individual libraries out of SVN and into Git
> submodules using svn:externals i.e. you wipe library X from SVN,
> replacing it with an svn:externals which loads a Github provided SVN
> translation from Git
> (https://help.github.com/articles/support-for-subversion-clients) for
> that particular library submodule. This lets maintainers test their
> particular library to make sure it really works as a git submodule,
> and "detach" its write access from SVN. Slowly, over time, we
> therefore transition from all-SVN write access, through some-SVN
> some-Git write access, to all-Git write access, with the SVN repo
> eventually becoming a "shell" of links to git modules and whose svn
> revision no longer increments.
>
> Disadvantages: someone has to manage and coordinate this process, and
> if finding review managers is hard now, finding git conversion
> managers is probably harder. Explaining it coherently to Boost devs
> might be hard, especially convincing of need as compared to staying
> with SVN.

This may be somehow workable approach as it leaves more control to each 
library maintainer.  But I worry about the additional coordination, 
complexity and management it involves.  Why do we need it?

I would rather suggest to get all critical processes such as builds, 
installs and tests verified as working to a reasonable comfort level
in git modular "read only" layout while the Boost2Git is active.  Then 
turn Boost2Git off hopefully with reasonable time to next release.  Then 
work out remaining issues in Git.  I think this is more or less what 
Beman suggests.

Advantage:
This can be done soon, and conversion will be done.  There is no plan 
for how and when all problems with the conversion are discovered and 
fixed, so waiting for a perfect conversion make no sense.

Disadvantage:
After general Boost2Git conversion is turned off it is possibly harder 
to fix history breakage for some library that got it wrong in the last 
Boost2Git conversion run.

Risk mitigation:
If seriously broken library history is discovered after general 
Boost2Git conversion is turned off, that library submodule repository 
reference can be changed with a simple commit in the boost "master" 
repository.  So it is still possible to fix history for individual 
libraries as needed with Boost2Git or other tool after the conversion is 
"completed", but this should only be done if it really is needed. In 
addition SVN history is available, it does not go away.

--
Bjørn