Git hosting

[Behdad Esfahbod-3]

Hi,

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

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.

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.

Anyway, Olav asked me to write to these lists, so here it goes.

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

_______________________________________________
Gnome-infrastructure mailing list
Gnome-infrastructure@...
http://mail.gnome.org/mailman/listinfo/gnome-infrastructure

[Olav Vitters]

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.

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

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

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

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.


Questions:
- What is the DVCS version of svn:external(s?)
- 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)
  - ehr.. distributed? ;-)
  - 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

    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)?
  - same for documentation things
  - *very* easy to commit to e.g. gnome-2-22 branch, 'trunk', etc



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)

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


--
Regards,
Olav
_______________________________________________
Gnome-infrastructure mailing list
Gnome-infrastructure@...
http://mail.gnome.org/mailman/listinfo/gnome-infrastructure

[Claude Paroz-2]

Le lundi 18 février 2008 à 09:28 +0100, Olav Vitters a écrit :
(snip)
>
> Note that:
> - needs lots of changes in Damned Lies
>   - must be done before the switch!
(snip)

Don't think so. Even if not tested thouroughly, Damned-Lies has already
built-in support for git.
http://svn.gnome.org/viewvc/damned-lies/trunk/modules.py

Claude

_______________________________________________
Gnome-infrastructure mailing list
Gnome-infrastructure@...
http://mail.gnome.org/mailman/listinfo/gnome-infrastructure

[Olav Vitters]

On Mon, Feb 18, 2008 at 09:45:44AM +0100, Claude Paroz wrote:

> Le lundi 18 février 2008 à 09:28 +0100, Olav Vitters a écrit :
> (snip)
> >
> > Note that:
> > - needs lots of changes in Damned Lies
> >   - must be done before the switch!
> (snip)
>
> Don't think so. Even if not tested thouroughly, Damned-Lies has already
> built-in support for git.
> http://svn.gnome.org/viewvc/damned-lies/trunk/modules.py

Nice! It has obviously been a while since I checked out Damned Lies :-)

Is this already in use for some modules (please answer per DVCS system)?
This so I understand how stable it is.

Are all DVCS systems supported (git/hg/bzr.. don't care about others)?

--
Regards,
Olav
_______________________________________________
Gnome-infrastructure mailing list
Gnome-infrastructure@...
http://mail.gnome.org/mailman/listinfo/gnome-infrastructure

[Claude Paroz-2]

Le lundi 18 février 2008 à 09:55 +0100, Olav Vitters a écrit :

> On Mon, Feb 18, 2008 at 09:45:44AM +0100, Claude Paroz wrote:
> > Le lundi 18 février 2008 à 09:28 +0100, Olav Vitters a écrit :
> > (snip)
> > >
> > > Note that:
> > > - needs lots of changes in Damned Lies
> > >   - must be done before the switch!
> > (snip)
> >
> > Don't think so. Even if not tested thouroughly, Damned-Lies has already
> > built-in support for git.
> > http://svn.gnome.org/viewvc/damned-lies/trunk/modules.py
>
> Nice! It has obviously been a while since I checked out Damned Lies :-)
>
> Is this already in use for some modules (please answer per DVCS system)?
> This so I understand how stable it is.
>
> Are all DVCS systems supported (git/hg/bzr.. don't care about others)?

Currently, we only use svn and cvs in production. git and hg support
have been added by a patch from Dimitris Glezos who implemented it in
the D-L-derived application Transifex (used for Fedora translations).

Claude

_______________________________________________
Gnome-infrastructure mailing list
Gnome-infrastructure@...
http://mail.gnome.org/mailman/listinfo/gnome-infrastructure

[Olav Vitters]

On Mon, Feb 18, 2008 at 10:05:00AM +0100, Claude Paroz wrote:

>
> Le lundi 18 février 2008 à 09:55 +0100, Olav Vitters a écrit :
> > On Mon, Feb 18, 2008 at 09:45:44AM +0100, Claude Paroz wrote:
> > > Le lundi 18 février 2008 à 09:28 +0100, Olav Vitters a écrit :
> > > (snip)
> > > >
> > > > Note that:
> > > > - needs lots of changes in Damned Lies
> > > >   - must be done before the switch!
> > > (snip)
> > >
> > > Don't think so. Even if not tested thouroughly, Damned-Lies has already
> > > built-in support for git.
> > > http://svn.gnome.org/viewvc/damned-lies/trunk/modules.py
> >
> > Nice! It has obviously been a while since I checked out Damned Lies :-)
> >
> > Is this already in use for some modules (please answer per DVCS system)?
> > This so I understand how stable it is.
> >
> > Are all DVCS systems supported (git/hg/bzr.. don't care about others)?
>
> Currently, we only use svn and cvs in production. git and hg support
> have been added by a patch from Dimitris Glezos who implemented it in
> the D-L-derived application Transifex (used for Fedora translations).

This is probably more gnome-i18n material:
Would Transifex be something for GNOME? E.g. somehow allow transifex to
see *all* GNOME modules, then let translators commit?

I need to check how authentication is done though. A general
'free-to-commit' won't work. Plus how documentation is done.

(if you add gnome-i18n to cc, please kill gnome-infra + sysadmin and
remove any reference to DVCS switch.. too early for wide announcement)

--
Regards,
Olav
_______________________________________________
Gnome-infrastructure mailing list
Gnome-infrastructure@...
http://mail.gnome.org/mailman/listinfo/gnome-infrastructure

[Vincent Untz]

Le lundi 18 février 2008, à 10:23 +0100, Olav Vitters a écrit :

> On Mon, Feb 18, 2008 at 10:05:00AM +0100, Claude Paroz wrote:
> >
> > Le lundi 18 février 2008 à 09:55 +0100, Olav Vitters a écrit :
> > > On Mon, Feb 18, 2008 at 09:45:44AM +0100, Claude Paroz wrote:
> > > > Le lundi 18 février 2008 à 09:28 +0100, Olav Vitters a écrit :
> > > > (snip)
> > > > >
> > > > > Note that:
> > > > > - needs lots of changes in Damned Lies
> > > > >   - must be done before the switch!
> > > > (snip)
> > > >
> > > > Don't think so. Even if not tested thouroughly, Damned-Lies has already
> > > > built-in support for git.
> > > > http://svn.gnome.org/viewvc/damned-lies/trunk/modules.py
> > >
> > > Nice! It has obviously been a while since I checked out Damned Lies :-)
> > >
> > > Is this already in use for some modules (please answer per DVCS system)?
> > > This so I understand how stable it is.
> > >
> > > Are all DVCS systems supported (git/hg/bzr.. don't care about others)?
> >
> > Currently, we only use svn and cvs in production. git and hg support
> > have been added by a patch from Dimitris Glezos who implemented it in
> > the D-L-derived application Transifex (used for Fedora translations).
>
> This is probably more gnome-i18n material:
> Would Transifex be something for GNOME? E.g. somehow allow transifex to
> see *all* GNOME modules, then let translators commit?

That's something that we've wanted, yes. (but we shouldn't force
translators to use it). I've discussed this a bit with Dimitris in the
past.

Vincent

--
Les gens heureux ne sont pas pressés.
_______________________________________________
Gnome-infrastructure mailing list
Gnome-infrastructure@...
http://mail.gnome.org/mailman/listinfo/gnome-infrastructure

[Behdad Esfahbod-3]

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

_______________________________________________
Gnome-infrastructure mailing list
Gnome-infrastructure@...
http://mail.gnome.org/mailman/listinfo/gnome-infrastructure

[Olav Vitters]

On Wed, Mar 05, 2008 at 05:44:07AM +0100, Behdad Esfahbod wrote:

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

GTK+ is a well managed module. Try something like gnomeweb-wml. Modules
where /trunk was svn mv'ed, etc. Maybe the release-notes module I
created.

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

Years ago I read some magazine that had a different view on learning
curves. Steep was good, you learned a lot in a short while. Flat was
bad, took way to long to learn something.
My view on Git is that the learning curve is as good as flat -- I've
read through various documents and didn't feel like I understood
anything.
IMO calling Git difficult is a great compliment to the current state.

I understand that after minimum required 6 months you'll at one point
greatly improve -- after all, Git has a command for everything. However,
I don't believe people will have the patience for this (I do not -- I
have better things to do).

Yes, some prominent hackers love it. But ehr, give me something simple
I don't mean trying to ignore the 'extras' -- I tried that while reading
through the documentation. In the current state it feels like either
you're useful when you understood *everything* or nothing at all.

Elijah used VCS systems a lot more than me -- and it IMO it took him way
too long to figure out. I'm thinking of avoiding the 'total loss'
feeling within a few days at most (I recall having this when starting
wanting to do the first CVS commit.. the 'I don't want to fuck this
up' + 'wtf is this doing / I am supposed to do'). The part in the post
about 'if they have an unusually large level of patience and motivation'
is what worries me. I don't have the need to learn it.
e.g. Git != like learning a bike. I feel I'd forget everything if you
don't use it every day.

My view ATM is: Every VCS is crap. Choose the one with the least
drawbacks.

Git is something like:
+ swiss army knife.. great hackers will be loads more productive
+ really fast
- usability is crap (names of the commands, good *easily understandable* documentation)
- due above: lesser hackers/wannabees will not benefit at all and likely
  are left out
- (sane/Python) scriptability is crap
- windows support is still bad

But all DVCS systems have drawbacks. Hg where you (IIRC) tag using some
file, so you get merging problems there (forgot specific, just thought
'sucks'). Bzr.. not a swiss army knife.

My original plan was to leave everything for another year or so.. see
what the result is after that (progress made).

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

I don't understand this. Why not make a branch in cairo then? It is
hosted by the same thing, so you already have access to it.

Also wonder what happens when you have 1000+ users, all with different
repositories.

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

Down ATM. :-(

oh no.. gitweb just takes 2 minutes to load (!)

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

Can you give me the full commands to repeat above? Then I'll try to
figure this out.. hopefully. Btw: I do hope 'gitk' uses GTK+ right?

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

Note: subprojects (something like that) is crap. Not implemented
correctly (this I investigated). Bzr has some plans, but nothing that
works (AFAIK). Hg: no idea.

But perhaps we can avoid that svn:externals? Although that would require
someone looking into existing usage and finding a solution (I'll try --
but I don't pretend to understand build systems).

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

Isn't that with any DVCS?

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

With e.g. bzr you can use normal sftp, it is just a lot slower. Not sure
if Git allows the same (no loss of functionality). Hg is actually pretty
nice. Does all sorts of things to make it faster (e.g. might compress
things differently, etc).

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

Does it always get the whole history? Others allow e.g. only doing a
minimal checkout and using the remote server for missing info (saves
lots of diskspace).. that is bzr.. Hg I still need to investigate (I
really hate that file merge thingy).

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

Maybe integrate with damned-lies. That knows the .po files (not always
in the same place, sometimes multiple in a repos, etc). Just need
something that makes it simpler.

I don't think there are scripts that change git --> usable though.

> #!/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".

I know, branching/merging/tagging is crap. Mostly the merging/tagging
part.

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

I know :-(

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

Hrm. Don't understand why all those commands have to have a different
meaning in Git. Reset that isn't reset, etc.

--
Regards,
Olav
_______________________________________________
Gnome-infrastructure mailing list
Gnome-infrastructure@...
http://mail.gnome.org/mailman/listinfo/gnome-infrastructure

[Vincent Untz]

Le mercredi 05 mars 2008, à 11:37 +0100, Olav Vitters a écrit :

> On Wed, Mar 05, 2008 at 05:44:07AM +0100, Behdad Esfahbod wrote:
> > > - 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.
>
> Does it always get the whole history? Others allow e.g. only doing a
> minimal checkout and using the remote server for missing info (saves
> lots of diskspace).. that is bzr.. Hg I still need to investigate (I
> really hate that file merge thingy).
>
> > >   - 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:
>
> Maybe integrate with damned-lies. That knows the .po files (not always
> in the same place, sometimes multiple in a repos, etc). Just need
> something that makes it simpler.

FWIW, Transifex is the solution for committing .po files. Translators
just upload the po file somewhere and everything else is magically done.
I'll be pushing for this in the next few months ;-)

Also, just a general comment: as a hacker who doesn't care a lot about
VCS, I find git still too difficult to learn. It's improving and maybe
it will get to the right point. Each time I use git, I have to check I'm
using the right command and I'm not sure I'm doing things right. I mean,
this is normal when switching VCS, but it's way worse with git than when
I tried bzr or when I switched to svn. git is too powerful. We need a
dumb wrapper for people like me.

Vincent

--
Les gens heureux ne sont pas pressés.
_______________________________________________
Gnome-infrastructure mailing list
Gnome-infrastructure@...
http://mail.gnome.org/mailman/listinfo/gnome-infrastructure

[Elijah Newren]

On Tue, Mar 4, 2008 at 9:44 PM, Behdad Esfahbod <behdad@...> 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
_______________________________________________
Gnome-infrastructure mailing list
Gnome-infrastructure@...
http://mail.gnome.org/mailman/listinfo/gnome-infrastructure

[Behdad Esfahbod-3]

Thanks Elijah for jumping in.

On Wed, 2008-03-05 at 06:25 -0700, Elijah Newren wrote:
[...]

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

Right.  When I started git first I was shocked that I need two clones to
keep the stable and the devel branches *around*.  But very soon I found
that indeed I just want a single clone, and switching branches is so
fast that I actually don't mind switching over all the time.  And we
optimized our autotools stuff to minimize rebuilds needed.

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

Didn't know about 'mr', but always thought about something like that.
The only times I've found it's hard to emulate one VCS' behavior with
another one is times like a merge failing and needing intervention.
Otherwise, the routine things can really be wrapped very easily.

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

Well, there are as many different workflows as there are users.  A tool
having one command for each of them is not necessarily the most flexible
and better one.  If a workflow is logically divided into multiple steps:

  - Checkout the gnome-2-22 branch
  - Edit the .po file
  - Commit it
  - Fetch any possible remote changes, rebase
  - Push it out

and if the user can't be bothered to run three commands, I don't see why
a shell script is stupid.  I have a shell script in my cairo tree,
called 'g', that does:

  git fetch cairo
  git rebase cairo-origin

Sure, one may go lobby for calling that git-update.  For me, it does the
job, and I better understand what's going on.  The above is kinda
non-standard.  A more standard version would be:

  git fetch origin
  git rebase origin/master

that's pretty much equivalent to 'svn update'.


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

That's not true.  Tim Janik has published one for example, called
YummyYummySourceControl:

  http://blogs.gnome.org/timj/category/tools/


> Elijah
--
behdad
http://behdad.org/

"Those who would give up Essent