home of the madduck/ blog/
Team-maintained packaging with DVCS

The other day, Romain shared his concerns about using Git for team-maintained packaging. His comment system is currently broken, so I wrote an e-mail reply, which I would like to share.

I agree with Romain that the design decision to not support subtree checkouts like SVN is not without problems. As opposed to a single SVN repo with components in subdirectories that you can individually check out, you might end up with a hundred Git repos, and the same change to all then requires one to iterate all 100.

I'd like to make the distinction between trivial changes (e.g. s/© 2008/&-2009/g) and those that might not be (e.g. Standards-Version, or something even more elaborate).

In case of the former, there's no question, it can be painful to operate across a hundred repos. Tools like mr make that a bit easier, but it's still far from optimal.

The latter, however — updating Standards-Version and adding the appropriate changelog entry — is not really comparable. Neither would be e.g. changing a file location in 100 different repos. In those cases, every single package needs manual intervention, and if only for quality reasons and testing. In this sense, I actually think that a single SVN checkout with all the subtrees and the possibility to easily commit the result of a recursive action is counter-productive.

On the other hand, I don't say that I am pleased with the workflow Git (or any other DVCS for that matter) imposes. It's sometimes quite painful, as Romain says. We are missing higher-level tools that allow for easier and more intuitive bulk operations. I think that they should be implemented outside of the VCS-tool though, true to the Unix principles. SVN integrates it all into a monolithic piece of software, and that often isn't ideal either (think size and slowness, or backup weight, or chance of corruption, or granular access control, or the impossibility to properly track files across subtrees).

mr is a step in the right direction, and we need more tools along those lines. First, however, I think that people need to figure out how exactly to use DVCS for packaging, such that there is any chance of consolidating workflows across a larger number of packages; if everyone does it their own, slightly unique way, then that goal is inifinitely far. This is the reason I started vcs-pkg.org, and even though we're still far from anywhere, I am quite pleased with what we've done so far.

If you're at Debcamp or DebConf, maybe you could join the discussion.

Romain also mentioned that distributed VCS don't allow for the same sort of centralisation as SVN does. I disagree: you can use Git in exactly that way, as a centralised repo from which packages are built. The nice advantage over SVN (one which svk tried to close) is the ability for everyone to easily branch/fork, or work offline.

Once you start down that path, it somehow inherently becomes everyone's own responsibility to ensure that one's changes end up in the central repository (where commit hooks might verify the build-ability, ensure that the test suite still passes, or run simple format/consistency checks).

This sort of workflow is very different from the one with a self-appointed benevolent dictator at the top, who (like Linus, or Junio for Git) sometimes forget to include patches due to overflooding. The question is really: Given that you need some sort of centralised release coordination, do you want a human or a repo to be the central entity (and single point of failure)?

I really prefer the repo, since that places the sole responsibility on the leafs, on the contributors, who need to see their code through all the way.

It's a whole lot more rewarding to commit/push, get a rejection, pull, merge, commit/push, and be done, rather than to send a patch to upstream, wait, reping, notice that it's not in in the new release, ask, ping, change, reping, get angry, ping, hope, wait, ping, wonder why the heck you are still doing this, write angry email but don't send it, reping, ask, and finally notice that it's been accepted after all.

NP: Deep Purple: Made in Japan