Re: [lmi] Migration to git

[Greg Chicares]

On 2016-05-20 16:32, Vadim Zeitlin wrote:
> On Fri, 20 May 2016 15:56:55 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> I'm not sure whether we'll be able to import into that repository 
> ourselves.
> 
>  We can push to it, of course, and, unlike with svn, there are no important
> advantages (like it being 10 to 100 times faster) in doing it server-side.

Oh. That's why the administrations wanted to handle migration to svn
themselves.

>  For me the important questions are:
> 
> 1. Do we want to have git-svn-id metadata in the new repository? I think it
>    could be useful as there are quite a few references to the existing
>    revisions in the history and they use just "NNNN" for them and not
>    "rNNNN" or "revNNNN" which would have allowed us to replace them with
>    the references to git commits automatically during import. And then
>    there are, of course, all the references to svn commits on the mailing
>    list too which would become dangling if we removed the metadata.

Good question, but I tend to think that we needn't care about this.

The historical svn references would remain valid because AIUI the svn
repository would continue to exist (just as our ancient CVS repository
was still there the last time I looked). I'd be more concerned about
the code than the mailing list. Let's search it:

$grep evision *.?pp
[...pruning instances that don't refer to any VCS...]

docmanager_ex.cpp:// was used in 'illustration_view.cpp' through revision 1.98 .

Wow...a CVS version.

gpt_commutation_functions.cpp:/// It would seem more natural to use a reference 
as in revision 5778,
input.cpp:/// (as of 20151102T2351Z, revision 6384) because the default age is
input.cpp:/// this function explicitly (20151104T0416Z, revision 6385). However,

Two have datestamps, so it should be easy enough to find them in
'git log'. The other one we could find readily enough in an
unmaintained history svn repository.

input_xml_io.cpp:    // already been asserted in a prior revision. It is not

That one isn't very specific anyway.

> 2. Assuming we do want to have this metadata, are we going to reuse the
>    existing GitHub repository or redo the import from svn? For me reusing
>    the existing one would obviously make things simpler and I, perhaps
>    self-servingly, don't see any advantages in redoing the import.

Oh...I forgot you've already done the work. Suppose, hypothetically,
that I were to redo it; would our sha1sums match? AIUI, they would
not, so we'd have to flip a coin and pick either yours or mine, so
in that case I should just save myself the trouble. And I suppose
you've already taken care of all the little details like creating
an 'authors' file, which I might forget the first few times I try.

I propose that I clone your repository and look it over carefully.
Then, after discussing any questions I might raise, we push it
to savannah ("push", or whatever the verb is). I think we should
do things in that order because I have the impression that gnu.org
blocks updates that would erase already-published code.