Re: Git hosting

["Elijah Newren" <newren gmail com>]

On Tue, Mar 4, 2008 at 9:44 PM, Behdad Esfahbod <behdad behdad org> wrote:
>  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.

It may be worth considering waiting a little longer; we might get a
nicer solution.  I agree with Olav that all VCSes suck...in one way or
another.

I'll try to help out with the migration whenever we decide on what and when.

>  > > 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?

No, DVCSes are not the same and won't be within 6 months.  Keith's
post a long time ago about "Repository Formats Matter" had all kinds
of problems contentwise (as mercurial developers pointed out), but the
title of the post was absolutely dead on.  Each VCS uses a different
format, and the format will often hinder or enable different
capabilities.  The fact that SVN has taken YEARS to try to get useful
merge functionality whereas many VCSes were able to implement it in
weeks is a direct reflection of the fact that the SVN repository
format is simply orthogonal to the needs of merging.  Sure, merging
can be shoe-horned into the svn implementation -- which turns out to
be exactly what they are doing, but they've hit all kinds of
unexpected snags along the way that they keep on having to try to fix.
 (Hmmm...maybe I should finish those notes of mine and make this a
blog post)

I crave the wonderful usability of bzr.  In my mind, it's a notch
above the rest.  svn and hg aren't too far off, but bzr has some extra
polish.  However, it has parallels to svn here in that the format is
going to limit its utility to many people.  I was talking to Ian
Clatworthy (bzr dev) about all kinds of bzr and DVCS issues; cool
things in bzr, stuff to put in his writeups, etc.  He did his best to
answer questions and sell bzr, but when I pointed out the most obvious
and painful missing feature in bzr that I'd miss the most from using
git -- being a branch container -- there was simply no response.  The
ramifications of this single feature are huge, though -- it means much
more than what you'd expect from a single listed feature.  In fact,
when you look closely enough, you find that *several* of the features
being developed by bzr in many ways amount to partial workarounds for
this missing functionality.  Also, if you read through the bzr layout
model and read over their documentation, you find that their
assumption of branch==directory goes all the way to their very core,
so this will be something that would be extremely difficult for them
to change.  And I'd be worried about pushing bzr on the developers of
large and low-level modules, because missing this feature would be
painful to them.

And the odds of being able to fix git's UI within 6 months seems like
a long shot.  You'd have to rip and replace their manpages (or at
least hide them), since they are really worse than useless for new
developers.  In fact, those manpages are really only any good for
someone who knows enough to write their own porcelain for git (at
which point they become very useful and even awesome).  And that's
only the biggest problem, there's quite a number of UI warts to fix as
well...

hg is kind of a middle ground here as far as these features are
concerned, but a number of people have found themselves hitting a
barrier with the hg implementation as well.

>  > > 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.

What's the rationale for having everybody use the same thing?  I will
likely agree with it, but it is worth noting that some of the reasons
for such a requirement may not be as important anymore.  I'll note the
changes in progress already mentioned in this thread to allow
translators to not have to use a VCS at all, and also the existence of
a simple tool called 'mr' which can be used to interact with projects
under half a dozen different VCSes all using the same commands (sure,
you're limited to the lowest common denominator, but that essentially
amounts to the common operations of cvs/svn).

>  > 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.

I think you'd even find people starting to want it with bzr or hg,
really.  Sure, not everyone would want it, but the modules with many
developers will at some point realize these capabilities and start
clamoring for this kind of support...or else roll their own solution.
Even among modules with only a few maintainers you'll see some
adoptions of this functionality.  I've already seen these kinds of
things spring up all over the place, and not just for git.

>  > 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.

git-submodule?  It's a joke IMO.  Nearly no useful functionality yet
and already it has some nasty UI issues and a couple gotchas to boot.

(Great idea which would be superior to svn:externals, IMO, but the
implementation is extremely lacking at best.)

>  >   - 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.

I haven't read the whole page, but I think you are referring to:
"Publishing a git branch to your public webspace is not obvious (last
time I tried) and requires git to be installed on the remote server.
Not good if you have a shitty ISP."

No, I can publish git repos on a public website without git installed
on the server.  I completely agree with it being unobvious in git
(it's a series of 6 seemingly random incantations, some of which are
not git commands).  However, updating such an uploaded repository
without git installed on the server is essentially a big nasty script
you write yourself or a mirror-only operation.  But then again, not
sure that mirror-only would be such a big deal.

I'm not sure how this is relevant to GNOME, though...

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

Absolutely, tailor is harder to figure out than git, IMO.

Luckily, bzr, hg, and git all have tools for svn migrations.

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

I disagree with this being a requirement; even the svn developers are
considering dropping this feature (and appear to agree that it's worth
it to gain performance and other abilities of DVCS systems).

>  >   - same for documentation things

As I've stated elsewhere, svn, hg, and bzr have good documentation.
hg even has a book online to match the cvs and svn ones at red-bean,
which is really cool.  Git's online tutorial is actually decent, but
their built in help is abysmal and worse than telling users "just try
something -- good luck!" (even despite the nasty gotchas lurking with
git).

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

svn does this in one step, you can turn it into a single step in bzr
(a combined local commit + push; see 'bound branches'), and in hg and
git it will be just two steps (commit + push).

I don't think this rules out any system.

>  One can write shell scripts that make it very easy to do so...  We can

Bah!  "The tool is broken but I know how to work around it".

The tool is stupid and lacking if you have to do this, IMO.

>  For example, with SVN,
>  tagging (and branching too) is REALLY HARD.  I use the following script:

Yes, svn is also stupid and lacking.

>  > 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

Ah, here's part of the answer to my previous question.  Would be nice
to have a list of these somewhere; it'll be needed regardless of the
chosen migration path.

>  > - 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'm pretty sure all systems satisfy this.  I've even rebuilt my own
rpms of bzr, hg, and git since Fedora wasn't as aggressively following
their release schedules as I was (I didn't want to wait more than a
couple days in some cases), and it has been very simple.  I've also
rebuilt the svn rpm (to get bzr-svn working); that one was by far the
most painful, though mostly just a long waiting game.

>  > - I *really* *really* like something with good and easily usable Python
>  >   bindings (better that SVN one.. feels like C in Python)

I haven't looked at the bindings side myself, but from what I've read
bzr would be the winner here, then hg, and git doesn't have much of
anything at all.  (git is really nice from a shell scripting side...in
fact, it seems like it was designed for someone else to write a
wrapper around it...oh, wait, it was.  Too bad no one has made a good
one yet and published it)

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

Yes, they all have it, though they don't idiotically require a URL
like svn (another example of stupid UI that needs a script): svn
export, bzr export, hg archive, git archive.


Elijah