Re: Let's talk about SVN management
Hi & sorry for this late reply
On Mon, Nov 7, 2011 at 07:12, Stefan Fritsch <sf@sfritsch.de> wrote:
> Hi,
>
> On Tue, 1 Nov 2011, Sandro Tosi wrote:
>>>
>>> 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.
>
> I would prefer switching to git, too. Therefore we should not put work into
> restructuring the svn repo, IMHO. But I don't have any experience in
> maintaining a large complicated package in git, though. Do you?
I have some experience with maintaining packages in git (excluding
reportbug, which contains both upstream development and debian
packaging), f.e. with amule, mrtg and other smaller packages.
> Is it
> necessary to import the complete upstream source with git?
Following the usual workflow, yes, it should be imported the whole
tarball inside the repository (in a separate branch than the debian
stuff), usually also adding the pristine-tar diff (used to regenerate
the pristine tarball downloaded from upstream code).
> Though it may
> actually be a good idea, because we frequently have to backport commits from
> upstream's 2.2.x branch.
I can see your reasoning here, but there are a couple of problems:
- it would make quite a lot of sense if the upstream repository was
also git, but AFAIK apache httpd project is still on svn. you can use
svn-git but is it really worth?
- if you want to backport a patch, I think the best way from a
packaging POV is to add a patch do debian/patches, and not simply take
the patch from upstream repository and "merge" with the code. Having a
separate patch will easy its removal when we'll package the version
the patch was taken from, and clearly mark the differences we've made
from the upstream version (and also why we did that).
Just to be clear: I'm not against git, I like it a lot, but having
seen it from both side (as a developer and as a packager) I do like it
much more as a developer than as packager, and the simple svn for
debian/ only and a separate tarball is usually easier. But that just
IMHO.
>>> 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 :)
>
> The dpatch scripts are the reason that the package is not switchted to 3.0,
if that's just it, I think we can hack something in debian/rules
Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Reply to: