Re: Debian Perl Group meeting at DebCamp - 2008-08-06
On Sat, Sep 13, 2008 at 11:53:44AM -0500, Gunnar Wolf wrote:
> Russ Allbery dijo [Sat, Sep 13, 2008 at 09:26:05AM -0700]:
> > I'm not sure what in there is a good case for Subversion, but I'm maybe
> > missing something?
> >
> > With Git, you'd clone the repository of whatever package you were working
> > on, do some work, push your changes back, and then can just delete the
> > local repository. It's fairly similar to what you described for
> > Subversion. Assuming, that is, that each package gets its own repository,
> > but I think that's the most natural way to structure things with Git.
>
> Well, thing is we would have to set up as many public-facing Alioth
> git repositories as packages we have, all with the same setup
> (i.e. permission-wise, to all group members and DDs). Of course, it
> could be templated/done... But it sounds suboptimal!
"setting up" a git repo isn't like setting up a cvs or svn repo.
Pretty much all you need to do is put a bare clone (a copy of the
local repo from whoever creates it) in a place where others can
access it. So putting one under pkg-perl (which Damyan appears
to have already initialised for padre) should automatically take
care of the permission issues.
Adding each new repo should be as little or less work than adding
a new svn module.
Which isn't to say _moving_ all the existing code won't be a big
job, but no bigger than it would be to, say move it _into_ svn
from something else.
If we were right back at the beginning of setting this up I would
suggest git is considerably better optimised for this sort of
collection of packages than svn. Adopting packages that started
out external to the group would be as simple as moving the repo
to a location under pkg-perl if they were already in git -- no
importing (or losing) the old history would be required. Ditto
if any packages ever move out from the group to a smaller group
or individual maintainer again for some reason.
It also means you can move packages into the new repo one package
at a time as they next get updated. Which is notable, because
it's the difference between this being a massive job for one person
to undertake, and a quite tractable one that can be spread over as
many people as are active here, and as long as it takes to finally
get to them all ...
I don't really feel like I have a 'vote' here, it's been a while
since I've needed/maintained (m)any perl packages myself, but if
I ever do again, I'd much prefer to have them in git than svn,
and would be much more inclined to offer group access to them if
it didn't mean having to regress to use svn again if I do that.
Cheers,
Ron
Reply to: