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

Subject: Re: [boost] [git] [conversion] Schedule and remaining showstoppers?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-10-15 14:41:29

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.

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.

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.

I hope this is useful, even if not fully thought through.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/