Re: Let's talk about SVN management
Hi all,
On Tue, Nov 1, 2011 at 16:40, Arno Töll <debian@toell.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello Sandro,
>
> On 01.11.2011 15:52, Sandro Tosi wrote:
>> I'm following up the RFH (explicitly cc-ing Stefan ad Arno, just in
>> case) mail and what's written in [1].
>
> I'm subscribed to debian-apache, but thanks for remembering me.
just writing to the list then
>I'm
> sorry I didn't submit any patches yet, by the way. I already worked on
> some stuff but it is not ready to be published yet. More on that below.
me neither, so don't worry ;)
>> Anyhow, my suggestion is to try to bring the repo layout in a state
>> that's understandable by svn-buildpackage, and start using it to build
>> the package. We can keep maintaining only the debian/ dir in SVN, and
>> leverage the mergeWithUpstream svn-bp feature (see its manpage), but
>> at least we'll have a "standard" configuration, easier to work with.
>
> Fully acknowledged. I used to work with svn-buildpackage too, and it
> comes really handy. I'd be glad to have the repository in a shape which
> works together with svb-bp.
>
> We use layout 2 in glibc-bsd and I could configure svn-bp without much
> problems there, despite I am probably the only one using it there.
>
> However, merged repositories, i.e. those with the full upstream source
> are additionally easy to deal with. Especially with svn-bp you only need
> to checkout package/trunk (or trunk/package) respectively so the amount
> of wasted disk space is limited. So, why not switch to such a layout too?
Honestly, I think it's unnecessary: what we need to keep under
versioning control is the debian files, not the upstream source code,
that we "receive" as a tarball.
>> What do you think about it? If you're worried about the work to
>> re-shape the repo, I volunteer to do that, but I don't know exactly
>> how to create a parallel svn repo (to show the end result) without
>> access to the current one.
>
>
> 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.
> For your question: You can refactor the repository locally (e.g. by
> creating a new local repository) and import it later to Alioth by using
> svnadmin. See [1] to get the idea.
yes, I know, but this way I could not publish my repo somewhere public
where others can look at. oh well, I can push it to collab-maint svn
> 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 :)
Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Reply to: