[Nix-dev] Re: new possible movement to git (?)

[Michael Raskin]

<j377eb$m52$1 at dough.gmane.org>)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

> From my thinking, the process would be cleanest if it took the 
>following steps:
>
>1. All the projects which contain references to the svn repos get 
>updated to point to where the new git repos will be
>2. The svn repo is rendered read-only or all committers have their write 
>access revoked
>3. Git repos are generated from the svn repos (each of the 
>https://svn.nixos.org/repos/nix/*) using one of the many available tools 
>for the purpose
>4. The newly-generated git repos are put in the locations specified in 
>step 1.
>
>Anyone can perform steps 1 and 3, while steps 2 and 4 require some sort 
>of administrative access to complete, but are fairly straightforward in 
>and of themselves. If we can get agreement about where the git repos 
>should go, I'll be happy to perform steps 1 and 3 (and 4, if we decide 
>to host the git repos somewhere public or on my servers for some reason) 
>myself, but without agreement on step 1 any effort on this will just be 
>wasted since everything will still default to the svn.nixos.org repos.
>
>I'm a bit tempted to just say "If I get no objections by two weeks from 
>now, I'll update the svn to point to a github repo until someone can set 
>the repos up on the nixos servers", but I don't know whether the policy 
>for a change this big is "if nothing is said, do it" or "if nothing is 
>said, don't do it".
>
>~Shea

We have "if nothing is said, don't do it" for far less intrusive changes
than changes that include loss of access to some parts of data. 

With SVN I can easily look up which commits were initially done in 
stdenv branch and which were done in trunk. Ditto with Mercurial. But 
with git you seem to need some extra knowledge to do that after the 
proposed move.

There are many arguments for hg/fossil/git, so just moving to git is 
not obviously the best solution. There are things that are better in 
SVN than in git, and we are not a kernel-sized project where we would
be in the situation git is tuned for. So it is not a good idea to do any
radical step without explicit support from TU Delft people.