|
Boost : |
Subject: Re: [boost] [git] [conversion] Schedule and remaining showstoppers?
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-10-16 13:23:25
On Tue, Oct 15, 2013 at 7:38 PM, Bjørn Roald <bjorn_at_[hidden]> wrote:
On 10/15/2013 08:41 PM, Niall Douglas wrote:
> 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.
>
Yes - and spacing out the various actions in my original post to give time
for testing makes perfect sense.
>
> 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.
>
Yes, and that pretty much describes my thinking too.
--Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk