(Or the unfortunate story of why I am not yet participating in the Debian games or perl teams.)

I'm a big fan of both the Debian games and perl teams. The games team keeps finding new and interesting games and flowing them into Debian. The perl team is responsible for a rather amazing quantity of perl modules. Since I maintain both some games and some perl modules, I've looked at participating in both teams from time to time. I think it's odd that the reason I haven't been able to do so in both cases comes down to something as basic as how they use their subversion repositories.

In the case of the perl team, they have a fairly standard use of subversion, as explained in their guide. The problem is repository layout. They chose to use the "package/{trunk,tags,branches}" layout rather than the "{trunk,tags,branches}/package" layout. This means that it's not easy to check out the source for every package in the repo all at once.

Having all the sources checked out is a prerequisite for many kinds of work that span all packages. In my work on the d-i packages, which are in a repository using the latter structure, I often grep all the packages for a problem, and fix the problem in every package. To manage this with the debian-perl repo, I'd either have to check out the whole thing, with who knows how many gigabytes of tags, or I'd have to construct and maintain an svn:externals list that checked out the trunk of every package.

(Open offer to the perl team: I'd be happy to reorganise your repo for you.)

The games team uses the "{trunk,tags,branches}/package" repo layout, which is nice. But they have a policy of not keeping all upstream files in subversion at all. They prefer to only keep files that are patched in subversion, to save space. That looks on the surface to be a nice space optimisation, especially for space-hungry game data, but from what I tell, what it saves in space, it loses in complexity and maintainer time. And my time is much more valuable than alioth's disk space.

It's also very debatable how much space this saves at all for games. I keep uqm and all its data files in one subversion repo. I have 4 years of history of all of upstream's changes to the files in there, and it takes 165 mb of data. Which sounds like a lot, but the files in trunk alone take 170 mb to check out (not counting .svn directories)! And the games team is also storing upstream tarballs in a directory on alioth. One tarball per release, often multiple releases per game, 2.0 gb of tarballs in all. Would it really use much more space in svn? Even if it used 10x the space somehow, is 20 gb even worth worrying about? I think not.

(Open offer to the games team: I'd happily do the grunt work of checking in upstream sources for all the games in your repo.)

(Update: I realized after posting this that while the space gains on alioth might be illusory, there is certianly a space gain for people checking the whole repo out. What's really needed is a way to keep all the upstream sources in svn, but check them out only when wanted, and check out all the debian directories for cross-game work. Hmm..)

I also checked out one other big package repo, collab-maint. The policy for collab-maint's repo uses the same structure as the perl team's repo. However, I doubt I'd ever want to check out all of collab-maint or do group maintenance across it, so that's not a big deal. The documentation also recommends not storing upstream sources in svn, although I've found a lot of packages in the repo that do. I could probably dump in ~100 mb of subversion history for 50-odd packages without anyone caring ... right?

It's interesting that all three of these big subversion repos have their own custom policies for how to use their repo. Having different policies for each repo results in more complexity and a higher learning curve. I wager that 99% of all the packages in these repos are pretty stock in their packaging and can be pretty easily understood and worked with by most Debian maintainers. We've have de-facto standards and policies that they all use. Until you get down to the repos, which, despite using subversion each seem to need to go their own way for some reason.