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/