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

Re: Git? (Was: Team maint update)


Am Freitag, den 03.07.2009, 10:11 -0500 schrieb John Goerzen:
> Git has submodules support (see git-submodule(1)).  Also,
> git-buildpackage and friends are structured around the idea of separate
> repos.  It's pretty easy to write shell scripts to act on all of them,
> and even treat them all as a logical whole, thanks to git-submodule.
> I'll need to go read the perl thing before commenting more on its
> relative merits.

Keep in mind that when DPG was started, git was not anywhere near where
we are now (if it even existed). So it might well be that SVN would not
be the best choice any more (although the feature of having one big
repository where you can still check out only the parts (e.g. packages)
you need is a big advantage). Collaborative maintenance of simple
packages has quite different needs than collaborative development of
software, and especially the nice features given by DVCS are less needed
here, IMHO.

> > (...)
> >> Information on the DPG’s SVN layout can be found here:
> >> http://pkg-perl.alioth.debian.org/subversion.html#2__repository_anatomy
> > 
> > I noticed they keep the upstream sources in the repository.  What's the
> > point of that?  Isn't keeping just the debian/ directories enough?
> It makes it much easier for everyone.  You can just darcs get, get
> clone, or whatever and get a working tree.  You can build a diff.gz from
> nothing but the data contained in the repo.  You can use the VCS to
> track diffs outside of debian/ as well, removing the need for things
> like quilt.

OTOH, only tracking debian/ makes stuff lightweight. Using the
debian/watch-file that every Haskell package has, a tool like
debcheckout, darcs-buildpackage or a custom script for the group can be
easily created that checkout debian/ and fetches the .orig.tar.gz from
Hackage. Not being able to modify stuff outside of debian/ is considered
a feature by some :-)

> > (...)
> >> I guess John, being the author of darcs-buildpackage, can
> >> best guess if it’s a good idea to use Darcs).
> > 
> > I agree with this too.
> I used to use darcs, and for this task in particular.  I was forced to
> abandon it due to all the conflicts it generated.  Eventually, its
> merge-in-exponential-time problem became so severe that it became unusable.

I made the same experience when packaging xmonad. I think that if we use
darcs (which would be worth a try), we should not try to mix it with any
upstream darcs repository – just import upstream from the released
tarballs. Or just keep debian/.

I’m inclined to favor Darcs and tracking only debian/, extending
debcheckout and darcs-buildpackage to handle the debian/-only tracking
and see if it works out ok.

Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Reply to: