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
signature.asc
Description: PGP signature
