Re: Git hosting

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

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

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.

- 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
  - ehr.. distributed? ;-)
  - I've edited 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://$$FILE right?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]