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