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

[proposal] switch our repository from Subversion to Git



The subject line is quite self-explanatory: this mail is re-raising the
proposal made by Eric a while ago [1].  There are 2 new bits though.

[1] http://lists.debian.org/debian-ocaml-maint/2008/01/msg00198.html

svn -> git poll
===============

The first new bit is a _poll_ to gather opinions of d-o-m contributors
on the topic, you can find the poll at [2]. I propose that every person
which has committed at least once to our repository in the past *and*
which is interested in contributing again in the future can vote. If you
have such a status please go to [2] and cast your vote.

Note that for the moment the point is only to gather consensus on the
switch; if we will be able to do so then we will of course take the time
to migrate the whole history of our current repository to the new one.
And of course this will be done in due time to avoid adding extra
complications to our current and forthcoming transitions.

If you just want to vote please do so in the poll page and do not
follow-up on list with AOLs.

[2] http://doodle.ch/participation.html?pollId=9h9ywrna56cukpmg

pro/cons of svn -> git
======================

The second new bit is an analysis of the pro/cons of the change. I start
with mine below, please contribute to the discussion.

Pro
---

- Offline work

  the main reason for me to switch is the ability to do offline work
  (commit, branch, test, ...), which is currently not possible with
  plain svn. (Yes, ok, it would be with svk, but frankly I've always
  considered it more an hack than the proper tool to work offline.)

- Branch usability

  I would like to use branches, and I've actually did that in the past
  in some packages of mine (for example for test driving dh_ocaml, or
  for managing *-proposed-update upload). But the merge of those
  branches with svn is painful, as you basically have to be able to
  recognize the branch point to be able to merge, and future merges are
  no way. It is painful at the point that I'm no longer interested in
  branching with svn in the future and that my old branches are
  basically useless nowadays.

  Note also that according to some recent discussion we had, we will
  possibly need to use branches more thoroughly in the future, for
  example for maintaining *caml stuff.

- Reduced space requirements

  Thus far we have maintained tarballs in svn; a choice which have been
  debated several times. I was in favor of it, but it is undeniable that
  a practical disadvantage of that choice is the space requirements of
  our repository:

    zack@alioth:~$ du -sh /svn/pkg-ocaml-maint/
    507M /svn/pkg-ocaml-maint/

  this is not only a problem for the alioth administrators, but also for
  people willing to obtain some of the above missing features using
  hybrid tools such as git-svn.

  Nowadays space requirements in svn can be reduced still keeping
  tarballs using pristine-tar [3], but we can't change our repository
  history and we have to live with the fact the we do have 500 Mb we
  will never get rid of. Moving to git can be the occasion to
  restructure and shrink the disk usage of our history.

  For the future, git-buildpackage [4] offers tools (e.g.
  git-import-orig [5]) to checkin tarballs as source branches and
  natively support pristine-tar.

- Support for external repositories

  Right now not every OCaml-related package is available from our
  repository, some packages are simply maintained by people which does
  not alioth at all, some other are maintained in other repositories on
  alioth (e.g. ara).

  Git sports several nice tools for the interaction with external
  repositories, such as git-svn which I've already mentioned, but also
  git-cvs, and some others git-<friend>.

[3] http://packages.debian.org/sid/pristine-tar
[4] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
[5] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.man.git.import.orig.html

Cons
----

- New workflow, new tools

  Well, obviously changing our VCS will mean that people will need to
  learn to use new workflows and new tools. There no way around this. We
  did that when we created pkg-ocaml-maint several years ago, we will
  need to do that again, and actually for more people than we were back
  then.

  On the bright side, I'm confident several of us already know git, and
  most of the git related tools I'm aware of have really good
  documentation nowadays. Much more than what was available when we
  adopted the svn toolchain.

- Add yours here

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time


Reply to: