Re: Git hosting

[Behdad Esfahbod <behdad behdad org>]

First, I'm happy Elijah wrote this in the mean while:

http://blogs.gnome.org/newren/2008/03/01/happenings-in-the-vcs-world/

On Mon, 2008-02-18 at 09:28 +0100, Olav Vitters wrote: 
> On Sun, Feb 17, 2008 at 03:46:29AM -0500, Behdad Esfahbod wrote:
> > We were discussing this on #gtk+ the other day.  Seems like transition
> > to a nextgen VCS, preferably git, would be needed in near future.  Many
> 
> Please confirm the near future means early 2009. This so that the
> conversion can be fully prepared and tested.

That would happen whenever it's ready to happen.  But yeah, early 2009
sounds good.


> > GTK+ hackers (everyone in Imendio for example) has been using git-svn
> > already, which makes perfect sense, because it allows a company/hacker
> > to have an internal GTK+ tree they work on.  The pain currently only
> > lies when they want to push the stuff upstream.  chpe also has been
> > using git-svn to do branches involving tens of commits and make them
> > available to me for review, for gnome-terminal and gucharmap.  These all
> > make me think, if we are using it, why the pain of the bridge?
> 
> Switching seems good. I don't want to rush things though. Once you have
> converted one module, there isn't a way to go back.

Well, for individual modules, it's much easier to check sanity, so after
the switch, there really shouldn't be any reason to want to go back.
Federico converted the entire Gtk+ history for example, and many hackers
will be looking at it and inspecting it:

  http://www.gnome.org/~federico/news-2008-03.html#full-gtk-history

> > I assume the merits of nextgen VCS tools are not disputed.  I personally
> > prefer git because that's widespread on fd.o and many of us around GTK+
> > stack already use it.
> 
> Heh. I like that approach (known + used by fd.o). I'd still like other
> requirements. Meaning: what is really needed? Or do you think all DVCS
> are currently basically the same -- or some that aren't will be in ~6
> months?

I really don't know.  I have only used git.  Elijah should know better.
While reading the comments on Elijah's post, I recognized a clear
pattern of prominent hackers (Havoc, Jeremy Katz, Company) essentially
saying the same thing: "for git, the learning curve may be steep, but
when you do get it, it becomes natural and you can't move away from it."
And at least some of the comments seems to be saying such a thing even
compared to Mercurial.  I don't know how accurate they are.


> > My proposal is to offer git hosting as an opt-in option, not switching
> > all modules to it.  That seems to have worked for fdo, though more and
> > more projects are moving.
> 
> I am not in favour of Git, nor switching only some of the modules. I'd
> like to move everything. This means the preparation is longer due to
> more testing. However, perhaps we can switch gradually (again: not
> rushed). Meaning: one module at a time.. but all modules will switch.

Sounds fine.

> I know Git has something like:
>   git://git.gnome.org/~username/myrepos
> 
> Is such a thing wanted? IMO I'd rather have real repositories (like any
> SVN user can create repositories ATM). For pet projects that aren't
> suitable as a general GNOME repository, use something other than GNOME
> to host it.

Oh definitely yes.  Those are the main reason of the whole D in "DVCS"
thing.  You may get away without providing it, it would just mean that
people will have to find another host for it.  The reason?  Lets see:

  Here is the central cairo repository, the "upstream", the "Linus tree"
of cairo:
  http://gitweb.freedesktop.org/?p=cairo;a=summary

  This is Carl's cairo tree, holding branches with series of patches he
has written that are undergoing review, or otherwise still not merged.
Note that some branches were last modified more than a year ago:
  http://gitweb.freedesktop.org/?p=users/cworth/cairo;a=summary

  This is Chris Wilson's, another core cairo hackers:
  http://gitweb.freedesktop.org/?p=users/ickle/cairo;a=summary
A series of commits by him typically holds more than twenty commits.
Imagine submitting those to bugzilla for review...

  All major cairo developers have such trees.

With a scheme like the above, I locally clone the upstream cairo repo,
then I add:

  git-remote add cworth url-to-carl's-tree
  git-remote add ickle  url-to-chris-wilson's-tree
  ...

Then when I want to review a series of patches from ickle, called
malloc-testing, I do:

  git-fetch ickle
  gitk ickle/malloc-testing

gitk gives me a visual tool where I can see all commits in cairo's
history plus the new commits in ickle's malloc-testing branch, syntax
highlighted and all...


> Questions:
> - What is the DVCS version of svn:external(s?)

Umm, I'm sure git has this feature.  Carl tells me about it all the
time.  Don't remember the name right now.

> - I know Git is preferred because most know it. However, what is the
>   main requirements of an DVCS?
>   - fast enough (I know Git is the fastest, but IMO fast enough should
>     do)

I add to that: Have entire project history offline.  Or at least have a
usable option to do so.

>   - ehr.. distributed? ;-)

Definitely, see above. ;-)

>   - I've edited http://live.gnome.org/DistributedSCM.. could you please
>     go over that? Please keep it 'post' integration. e.g. the SVN link
>     is not important. Only that you can reliably convert the repository

Your changes look accurate, at least to me.  Regarding git having to be
installed on the remote server, I don't understand, isn't that the case
for all systems?  You sure need cvs server installed to serve CVS.


>     Note: tailor is *not* suited for converting GNOME modules! The DVCS
>     should have tools for this (SVN->DVCS).

> - translator things:
>   - only checkout a file (highly preferred) / dir (like SVN)?

This is not possible with git as it works with commits as a whole, not
files.  Two orthogonal ways of looking at the repo.


>   - same for documentation things
>   - *very* easy to commit to e.g. gnome-2-22 branch, 'trunk', etc

One can write shell scripts that make it very easy to do so...  We can
even write shell scripts and a simple custom service, to checkout fa.po
for gnome-2-22 branch of gucharmap, let me translate it, and commit upon
completion.  That really holds with any VCS.  For example, with SVN,
tagging (and branching too) is REALLY HARD.  I use the following script:

#!/bin/bash
if test x$# != x3; then
	echo gnome-tag module tag release
	exit
fi
svn copy svn+ssh://svn.gnome.org/svn/$1/trunk svn+ssh://svn.gnome.org/svn/$1/tags/$2 -m "Tagged for release $3."

Yes, having to remember/type URLs is really hard, when compared to
"vcs-name tag tag-name".


> Note that:
> - needs lots of changes in Damned Lies
>   - must be done before the switch!
> - buildbot should be fine
> - we need to upgrade the SVN (version control) server.. waiting for new
>   LTS, etc (will be done after 2.22.. half 2008 somewhere)
> - switch might be delayed due to GNOME schedule (e.g. during freezes
>   seems bad)
> 
> - needs changes in various sysadmin scripts 
>   - forgot specifics
>   - 'gnomeweb' thingy that rebuilds the various websites (there are
>     *loads* of these)
>   - rather not maintain multiple VCS in those systems.. too painful
> 
> - Need to have packages for RHEL5, Ubuntu this years LTS, Fedora8,
>   possibly Debian (3.0 IIRC)
>   - should have backports when new versions come out.. or easily
>     buildable (meaning: I can do rpm, not deb)
> 
> - I *really* *really* like something with good and easily usable Python
>   bindings (better that SVN one.. feels like C in Python)

Well, this one git is definitely (far) behind competition.

> - All DVCS can do something like svn export
>   $vcs://$vcs.gnome.org/repos/path/$FILE right?

Humm.  Not so sure.  Sounds like git-checkout really.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759