The Big Switch to Git

The Big Switch to Git

[Ludovic Courtès]

Hello,

Neil and I have agreed to switch from CVS to Git (a few others were
enthusiastic too).  Now we need to agree on the details.  :-)

Personally, I'm thinking about only importing `guile-core' for now (like
what Han-Wen did at http://repo.or.cz/w/guile.git some time ago).  If we
eventually feel the need to import the other modules, we can do it and
have the Savannah folks let us store them in sub-directories.

We can't easily setup a `git-cvspserver' on Savannah I'm afraid, nor a
bidirectional gateway, and I think the complexity of doing it would
exceed the benefit, especially now that Git has become widespread.
Thus, I think we should just leave the CVS repository as is.  Of course,
we don't want to delete it, since it contains other modules, for
instance.  What do you think?

I've already done a `git-cvsimport' of `guile-core' locally.  I now have
a complete and UTF-8-clean list of committers (a mapping from
CVS/Savannah user IDs to real names and emails).  The Git repository
takes 34 MiB vs. 52 MiB for the CVS repository.

Once we've agreed on the details, one of the Savannah admins of the
project (i.e., Neil) will have to tick the "Git repository" option in
the "Select Features" menu item of the web interface, after which I can
just push the repository online.  We'll also have to update all
references to the CVS repository.

Comments?

Thanks,
Ludovic.

Re: The Big Switch to Git

[Greg Troxel]

  From: ludo@gnu.org (Ludovic Courtès)

That sounds ok.  I think not having bidirectional gateways is the right
call.

I would be tempted to transfer the other modules; the plan you stated
leaves some things in cvs and some not, and you want to disable writes
to cvs after the cutover.  It would be cleaner to have all in git and
cvs just a historical reference.

Re: The Big Switch to Git

[Ludovic Courtès]

Hi,

Greg Troxel <gdt@ir.bbn.com> writes:

> I would be tempted to transfer the other modules; the plan you stated
> leaves some things in cvs and some not, and you want to disable writes
> to cvs after the cutover.  It would be cleaner to have all in git and
> cvs just a historical reference.

Just to clarify: there are 18 modules, most of which are interesting,
but also somewhat bitrotten.  Here's the list:

  guile-comp        guile-modules   guile-statprof  guile-www
  guile-core        guile-oops      guile-tcltk     qscheme
  guile-doc         guile-rgx-ctax  guile-template  workbook
  guile-gtkthreads  guile-scripts   guile-tk
  guile-lightning   guile-scsh      guile-vm

I did some work on Guile-VM (in another repository, but it could be
merged), so this one is slightly less outdated.  `guile-statprof' is now
known as `(statprof)' in Guile-Lib.  `guile-oops' has been part of Guile
for several years.  `workbook' contains valuable but somewhat outdated
(?) documentation.  And the others, well...

That's why the "lazy import" method I was suggesting seemed worthwhile
(and also much less resource-consuming ;-)).

That said, we could agree on a subset of these modules that we'd import
from the beginning and let a few others rest in peace?

Thanks,
Ludovic.

Re: The Big Switch to Git

[Thien-Thi Nguyen]

() ludo@gnu.org (Ludovic Courtès)
() Sat, 15 Mar 2008 22:30:51 +0100

   Just to clarify: there are 18 modules, most of which are interesting,
   but also somewhat bitrotten.  Here's the list:

     guile-comp        guile-modules   guile-statprof  guile-www
     guile-core        guile-oops      guile-tcltk     qscheme
     guile-doc         guile-rgx-ctax  guile-template  workbook
     guile-gtkthreads  guile-scripts   guile-tk
     guile-lightning   guile-scsh      guile-vm

   Could agree on a subset of these modules that we'd import
   from the beginning and let a few others rest in peace?

It would be nice to have workbook and guile-scripts as peers of
guile-core, since that forms the minimal set to reproduce "cvs
checkout hack" of yore.  (Basically, the cvs-module "hack"
included only those three cvs-modules.)

Unrelated, i would request that guile-www be imported as well.
This way, presuming there is interest, we can eventually merge in
work on Guile-WWW that has been happening ttn-locally[0] for many
years now.

Everything else i don't really care about, personally.

thi

____________________________________________________________
[0] http://www.gnuvola.org/software/guile-www/
    http://www.gnuvola.org/wip/  (guile-www)

Re: The Big Switch to Git

[Neil Jerram]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> It would be nice to have workbook and guile-scripts as peers of
> guile-core, since that forms the minimal set to reproduce "cvs
> checkout hack" of yore.  (Basically, the cvs-module "hack"
> included only those three cvs-modules.)

I'm not aware that this "hack" collection has been doing anything for
us recently.  At least, it's true that guile-core does not currently
depend on workbook, as it did once.

I'm sure there is stuff in workbook and guile-scripts that is still
useful, but I prefer to import it lazily (and as and when it becomes a
priority).  That will also allow us to consider where each imported
item should go within the Git repository.

> Unrelated, i would request that guile-www be imported as well.
> This way, presuming there is interest, we can eventually merge in
> work on Guile-WWW that has been happening ttn-locally[0] for many
> years now.

Wouldn't it make sense for guile-www to be a separate Savannah
project?

In case this sounds like I'm singling out guile-www, I've actually
always had a problem understanding the structure and existence of the
Guile CVS modules other than guile-core - and I think the fact that
many of them are obsolete and/or bitrotted is a clue that this is a
problem in practice.

Regards,
      Neil

Re: The Big Switch to Git

[Thien-Thi Nguyen]

() Neil Jerram <neil@ossau.uklinux.net>
() Mon, 24 Mar 2008 23:16:23 +0000

   > It would be nice to have workbook and guile-scripts as peers of
   > guile-core, since that forms the minimal set to reproduce "cvs
   > checkout hack" of yore.  (Basically, the cvs-module "hack"
   > included only those three cvs-modules.)

   I'm not aware that this "hack" collection has been doing anything for
   us recently.  At least, it's true that guile-core does not currently
   depend on workbook, as it did once.

It's only value would be for history browsing.  Granted, that history is
shallow; interest quickly moved away from the non-guile-core cvs modules.

   I'm sure there is stuff in workbook and guile-scripts that is still
   useful, but I prefer to import it lazily (and as and when it becomes a
   priority).  That will also allow us to consider where each imported
   item should go within the Git repository.

I urge you to reconsider.  It's no big deal to import them and leave them be
(for historians).  You can even make them read-only.

   Wouldn't it make sense for guile-www to be a separate Savannah
   project?

Yes.  If Guile maintainers don't mind, i can pursue that angle.  More
precisely, i would create a Guile-WWW project on Savannah (w/ myself its
sole administrator), make a Git repo available, shutdown the gnuvola
guile-www Git repo, and post an announcement to the guile-user list.

   In case this sounds like I'm singling out guile-www, I've actually
   always had a problem understanding the structure and existence of the
   Guile CVS modules other than guile-core - and I think the fact that
   many of them are obsolete and/or bitrotted is a clue that this is a
   problem in practice.

Yes, there's a lot of hoarding of lost bits, there.  However, i think
singling out Guile-WWW is fine; it has undergone continued development,
whereas the others have not.

thi

Re: The Big Switch to Git

[Han-Wen Nienhuys]

Thien-Thi Nguyen escreveu:

> I urge you to reconsider.  It's no big deal to import them and leave them be
> (for historians).  You can even make them read-only.

this is a non-issue.  You can do the import to a seperate git repo later, 
and then do a merge into core. This will add all the history of the side-project
to core as well. 

IMO Until there is a need, importing random bitrot is a waste of time, and will
confuse newcoming hackers.

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: The Big Switch to Git

[Thien-Thi Nguyen]

() Han-Wen Nienhuys <hanwen@xs4all.nl>
() Thu, 27 Mar 2008 11:28:56 -0300

   this is a non-issue.  You can do the import to a seperate git repo
   later, and then do a merge into core. This will add all the history
   of the side-project to core as well.

   IMO Until there is a need, importing random bitrot is a waste of
   time, and will confuse newcoming hackers.

Sorry, i thought we were talking about parallel Git repos (to reflect the
parallel cvs modules "guile-core", "guile-scripts" and "workbook").  Am
i missing something?

thi

Re: The Big Switch to Git

[Han-Wen Nienhuys]

Thien-Thi Nguyen escreveu:
> () Han-Wen Nienhuys <hanwen@xs4all.nl>
> () Thu, 27 Mar 2008 11:28:56 -0300
> 
>    this is a non-issue.  You can do the import to a seperate git repo
>    later, and then do a merge into core. This will add all the history
>    of the side-project to core as well.
> 
>    IMO Until there is a need, importing random bitrot is a waste of
>    time, and will confuse newcoming hackers.
> 
> Sorry, i thought we were talking about parallel Git repos (to reflect the
> parallel cvs modules "guile-core", "guile-scripts" and "workbook").  Am
> i missing something?


Oh; you could import those your self, and push them to other branches in the
same repository.  For lilypond we have the website and the  binary builder in 
a branch web and gub respectively. 

I doubt it is worth the effort, though.


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: The Big Switch to Git

[Thien-Thi Nguyen]

() Han-Wen Nienhuys <hanwen@xs4all.nl>
() Fri, 28 Mar 2008 01:33:59 -0300

   Oh; you could import those your self, and push them to other
   branches in the same repository.  For lilypond we have the
   website and the binary builder in a branch web and gub
   respectively.

Sounds like a reasonable workaround.  I have yet to play w/ git
(sub)modules; perhaps that's another approach to keep peer dirs
synched (history-wise).  Does "gub" stand for "guile build"?

thi

Re: The Big Switch to Git

[Han-Wen Nienhuys]

Thien-Thi Nguyen escreveu:
> () Han-Wen Nienhuys <hanwen@xs4all.nl>
> () Fri, 28 Mar 2008 01:33:59 -0300
> 
>    Oh; you could import those your self, and push them to other
>    branches in the same repository.  For lilypond we have the
>    website and the binary builder in a branch web and gub
>    respectively.
> 
> Sounds like a reasonable workaround.  I have yet to play w/ git
> (sub)modules; perhaps that's another approach to keep peer dirs
> synched (history-wise).  Does "gub" stand for "guile build"?

No; it's written in Python. It is called grand unified builder, because 
in it we unified our (cross)build to windows, windows/cygwin, linux, freebsd
and various MacOS Xs.


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: The Big Switch to Git

[Ludovic Courtès]

Hi,

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> Oh; you could import those your self, and push them to other branches in the
> same repository.  For lilypond we have the website and the  binary builder in 
> a branch web and gub respectively. 

Branches within a Git repository are supposed to be related, i.e., to
have a fair amount of common data, otherwise using a separate repository
is probably a better idea.

Thanks,
Ludovic.

Re: The Big Switch to Git

[Han-Wen Nienhuys]

Ludovic Courtès escreveu:
> Hi,
> 
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
>> Oh; you could import those your self, and push them to other branches in the
>> same repository.  For lilypond we have the website and the  binary builder in 
>> a branch web and gub respectively. 
> 
> Branches within a Git repository are supposed to be related, i.e., to
> have a fair amount of common data, otherwise using a separate repository
> is probably a better idea.

The branches are related by being part of a common project, and
therefore sharing the same set of committers.  Also, it's not a
all-or-nothing thing.  Using another branch is a low profile way of
getting started, because it requires no setup at all. If the need
(different committers, high activity level) is there, you can always
push the branches into a different repo

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: The Big Switch to Git

[Thien-Thi Nguyen]

() ludo@gnu.org (Ludovic Courtès)
() Fri, 14 Mar 2008 17:23:38 +0100

   switch from CVS to Git

Cool!

   Personally, I'm thinking about only importing `guile-core' for
   now (like what Han-Wen did at http://repo.or.cz/w/guile.git
   some time ago).  If we eventually feel the need to import the
   other modules, we can do it and have the Savannah folks let us
   store them in sub-directories.

On the other hand, the sooner you import the other modules, the
sooner problems w/ the import can be found and corrected.  This is
especially important a few months down the line when details of
the process will have become fuzzy.

thi

Re: The Big Switch to Git

[Han-Wen Nienhuys]

Ludovic Courtès escreveu:
> Personally, I'm thinking about only importing `guile-core' for now (like
> what Han-Wen did at http://repo.or.cz/w/guile.git some time ago).  If we
> eventually feel the need to import the other modules, we can do it and
> have the Savannah folks let us store them in sub-directories.
> 
> We can't easily setup a `git-cvspserver' on Savannah I'm afraid, nor a
> bidirectional gateway, and I think the complexity of doing it would
> exceed the benefit, especially now that Git has become widespread.
> Thus, I think we should just leave the CVS repository as is.  

Good idea. Don't forget to add a 

  THIS_REPOSITORY_IS_DEAD

marker in a conspicuous place, say next to README.  
The same for any other module you convert.

> Of course,
> we don't want to delete it, since it contains other modules, for
> instance.  What do you think?
> 
> I've already done a `git-cvsimport' of `guile-core' locally.  I now have
> a complete and UTF-8-clean list of committers (a mapping from
> CVS/Savannah user IDs to real names and emails).  The Git repository
> takes 34 MiB vs. 52 MiB for the CVS repository.

That sounds a tad on the large side. The mirror I have uses 27mb (I just ran a git-gc).

> Once we've agreed on the details, one of the Savannah admins of the
> project (i.e., Neil) will have to tick the "Git repository" option in
> the "Select Features" menu item of the web interface, after which I can
> just push the repository online.  We'll also have to update all
> references to the CVS repository.
> 
> Comments?

Someone remarked about the workbook module.  I would vote for taking all of the relevant
history from that module and pulling that into a workbook/ directory.  It's better if the 
repo is self-contained.

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: The Big Switch to Git

[Ludovic Courtès]

Hi,

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> Ludovic Courtès escreveu:

>> I've already done a `git-cvsimport' of `guile-core' locally.  I now have
>> a complete and UTF-8-clean list of committers (a mapping from
>> CVS/Savannah user IDs to real names and emails).  The Git repository
>> takes 34 MiB vs. 52 MiB for the CVS repository.
>
> That sounds a tad on the large side. The mirror I have uses 27mb (I just ran a git-gc).

Wait, I was measuring the whole directory, i.e., working copy +
repository; `.git' alone weighs in at 23 MiB after `git-gc'.

That's indeed much better.  :-)

Thanks,
Ludovic.

Re: The Big Switch to Git

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Personally, I'm thinking about only importing `guile-core' for now (like
> what Han-Wen did at http://repo.or.cz/w/guile.git some time ago).  If we
> eventually feel the need to import the other modules, we can do it and
> have the Savannah folks let us store them in sub-directories.

After reviewing what others have said on this, I'm inclined to agree
with this lazy-import approach.

> We can't easily setup a `git-cvspserver' on Savannah I'm afraid, nor a
> bidirectional gateway, and I think the complexity of doing it would
> exceed the benefit, especially now that Git has become widespread.
> Thus, I think we should just leave the CVS repository as is.  Of course,
> we don't want to delete it, since it contains other modules, for
> instance.  What do you think?

Agreed.  Except that I think that we should "cvs remove" everything
that has been transferred to Git (once it is clear that the transfer
was successful).  (Because there should not be two possible sources
for the guile-core files, that can only confuse people.)

> Once we've agreed on the details, one of the Savannah admins of the
> project (i.e., Neil) will have to tick the "Git repository" option in
> the "Select Features" menu item of the web interface, after which I can
> just push the repository online.

I think I can go ahead with this at any time, can't I?  In other
words: ticking this option won't automatically do anything bad to the
existing CVS infrastructure, will it?

>  We'll also have to update all
> references to the CVS repository.

Agreed.

Regards,
      Neil

Re: The Big Switch to Git

[Ludovic Courtès]

Hello,

Neil Jerram <neil@ossau.uklinux.net> writes:

> After reviewing what others have said on this, I'm inclined to agree
> with this lazy-import approach.

OK.

> Agreed.  Except that I think that we should "cvs remove" everything
> that has been transferred to Git (once it is clear that the transfer
> was successful).  (Because there should not be two possible sources
> for the guile-core files, that can only confuse people.)

Hmm, I'd prefer adding a `THIS-REPOSITORY-IS-DEAD' marker, as Han-Wen
suggested.  We should also ask the Savannah hackers what other options
are available to somehow "hide" the repository without actually deleting
it.

> I think I can go ahead with this at any time, can't I?  In other
> words: ticking this option won't automatically do anything bad to the
> existing CVS infrastructure, will it?

Yes, you can do it anytime, and as long as you don't "untick" the "CVS
Repository" feature, nothing bad will happen.  ;-)

Thanks,
Ludo'.

Re: The Big Switch to Git

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hmm, I'd prefer adding a `THIS-REPOSITORY-IS-DEAD' marker, as Han-Wen
> suggested.  We should also ask the Savannah hackers what other options
> are available to somehow "hide" the repository without actually deleting
> it.

OK; I'm not wedded to "cvs remove", just want to avoid future
confusion - so let's see what the detailed options are.

>> I think I can go ahead with this at any time, can't I?  In other
>> words: ticking this option won't automatically do anything bad to the
>> existing CVS infrastructure, will it?
>
> Yes, you can do it anytime, and as long as you don't "untick" the "CVS
> Repository" feature, nothing bad will happen.  ;-)

I've done that now, so please feel free to proceed with whatever is
the next step.  Should we announce a temporary moratorium on CVS
commits?  Do people need time to record any work that they have in
progress by doing "cvs diff"s, while the CVS server is still working?

Regards,
        Neil

Re: The Big Switch to Git

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> I've done that now, so please feel free to proceed with whatever is
> the next step.  Should we announce a temporary moratorium on CVS
> commits?  Do people need time to record any work that they have in
> progress by doing "cvs diff"s, while the CVS server is still working?

Jim Meyering on `savannah-hackers' confirmed [0] that the CVS repo can
be made read-only, so I'll ask him to make it read-only and push the new
Git repo sometime tomorrow evening (Thursday, 27th), i.e., around
9pm-10pm GMT+1. (At any rate, we don't have a flow of tens of commits
per hour, so we should be able to cope with this downtime.  ;-))

Thanks,
Ludo'.

[0] http://www.mail-archive.com/savannah-hackers-public@gnu.org/msg01433.html

Re: The Big Switch to Git

[Ludovic Courtès]

Hi!

ludo@gnu.org (Ludovic Courtès) writes:

> Jim Meyering on `savannah-hackers' confirmed [0] that the CVS repo can
> be made read-only, so I'll ask him to make it read-only and push the new
> Git repo sometime tomorrow evening (Thursday, 27th), i.e., around
> 9pm-10pm GMT+1. (At any rate, we don't have a flow of tens of commits
> per hour, so we should be able to cope with this downtime.  ;-))

It's now online!

  http://git.sv.gnu.org/gitweb/?p=guile.git

The CVS repository contains a single file that indicates the change:

  http://cvs.savannah.gnu.org/viewvc/guile/guile/guile-core/

Thanks,
Ludovic.

Re: The Big Switch to Git

[Ludovic Courtès]

Hi,

ludo@gnu.org (Ludovic Courtès) writes:

> It's now online!
>
>   http://git.sv.gnu.org/gitweb/?p=guile.git
>
> The CVS repository contains a single file that indicates the change:
>
>   http://cvs.savannah.gnu.org/viewvc/guile/guile/guile-core/

I've updated the website to reflect the change.  See in particular the
new `repository.html'.  Suggestions are welcome!

Thanks,
Ludo'.