That said, if we're restructuring the repository anyway, why don't move
to git? I was setting up git-svn for the Apache repository earlier which
allows me to commit patches even though I have no write access to
repository yet. That's only one of the advantages in using git (although
I am no git zealot).
Well, I like both svn and git, but I think the svn + mergeWithUpstream
is often the right balance; what are the advantages of git? ok, you
can commit locally even without connections, but on the other hand you
have to commit the whole upstream code, when it's often un-necessary:
you have to download anyhow the tarball from apache.org, then import
it, then you have to keep it around for building the package, or use
pristine-tar, which introduce another layer before the package can be
build... :) That's the main draw back for me, but I'd like to hear
what Stefan thinks about it.
While we're talking about transitions: While getting some feeling for
the Apache package, I noticed it is still a 1.0 package which makes use
of dpatch. Would you mind switching to 3.0/quilt instead and dropping
the dpatch depdendency?
I noticed, there are two patches which aren't actually patches but
scripts. I used some debian/rules trickery to replace them in a
3.0/quilt setup. I didn't publish my patch yet, but unless you think
switching to 3.0/quilt would be a terrible idea I'd do soon.
I'm perfectly fine with 3.0 (quilt), if others are, (I'm moving all of
my packages to it when I come to touch them) but I think it's kinda
orthogonal to the VCS/layout of choice :)