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/