Hi, 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. Greetings, Joachim -- 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