On Mon, 08 Dec 2008 12:44:00 +0100, Steffen Moeller wrote: > Hello, > > it is nice to have a thread to which everyone can contribute something. > > > Argh, git! :) > > Ok, that would probably mean some learning period for me. I'm currently > > using SVN for all my personal projects, and am not really comfortable > > learning git -- but hey, everyone's using that, kernel hackers are using > > that, we are going to use that, it *must* have something good :) > > I just went through using git for a local project (and registered for a git > repository on berlios.de for the moment we are going to publish about it). If > you have used bazaar before, the migration seems straightforward. But I am > using only its basic functionality, as it seems. I'm currently using bzr for bash-completion (on Alioth -- just because we wanted the Ubuntu guys to join in, but they didn't) -- but we're using it as a "classic" VCS, i.e. in a "centralized" fashion (we're not using it as a DVCS) > The other side is that my contribution to pkg-boinc (as little as it was) has > come to a complete standstill since its migration to git. Just something has > not worked the way I thought it would work and I was too busy since to digest > everything properly ... there are other ways I can contribute to the > community more efficiently. I fear that, since my contribution to Debian-Med is mostly focused on the general infrastructure, I won't be able to contribute any more. And, well, a centralized VCS is best to me, because, let's say, we can have {pre,post}commit hooks, and so on. Setting up a post-commit hook on bzr was a nightmare (and, it works just for me, because each commiter must set up his own hook...). I believe that, for what we're having now for our infrastructure (i.e. website/scripts/pos/policy update on commit), SVN is the best choice. You could argue that we could split packages from community/, but that's not an option IMHO. > svn I consider sufficient for now, as long as we don't experience any larger > complexity of our projects. /me too. > The "community" folder is more of a concern to me. What do you mean? > Concerning reorganisation, it may be helpful to have some package flocking > together a bit more. For instance, my mgltools packages I have combined into > one big subfolder. The perl packages could go into one, too (bioperl, > bioperl-run, ... and dependencies like gbrowse for instance). But this is > nothing we need to discuss at large, I'd say, the individual (active) > maintainers should just be given the freedom to prepare such subfolders when > they see their suite of software to be represented properly that way. I believe what you're proposing would break tools like svn-buildpackage -- it expects some "layouts" like: package/{trunk,tags,branches} {trunk,tags,branches}/package <I can't remember the third now, maybe on the manpage?> I believe that re-organizing the repo as {trunk,tags,branches}/package would let us scale a bit further -- who just wants the code can checkout trunk/*, anyone else can checkout *. Obviously all just IMHO, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Attachment:
signature.asc
Description: PGP signature