Re: svn management, git, etc
On Sun, Aug 06, 2006 at 07:04:28PM +1000, Drew Parsons wrote:
> David wrote:
> > Hi everyone,
> >
> > So we need to talk about how we manage the svn archive and plans for the
> > future. Given upstream's move, I think it's pretty apparent that if we are
> > going to change our repository, it's going to be to git. Since a number of
> > people are clamoring for that, I think it's a safe bet that it needs to
> > happen.
>
> For my part, I don't have a really strong preference for one system
> over the other. I asked about git in a previous email just to hear what
> others think. It makes a degree of sense to follow upstream in using
> git, but we shouldn't feel obliged to have to do so. But I'm
> comfortable with it if we do switch. By the way, I asked X.org why
> they preferred git, and they pointed to the arguments at
> http://lists.freedesktop.org/archives/xorg/2006-February/013113.html
The biggest issue with git for me at least is the lack of experience we
have with it. Upstream is still coming to grips with it, although they're
getting better at it. Andres has some experience with it, and Michel seems
to be our current reigning guru. I'm eager to learn more, but I'm worried
we'll struggle a lot with it at first when we need to focus on fixing RC
bugs for the release.
> > 1) Do we keep using the vendor branches? Are they worthwhile given that we
> > keep all important patches in quilt? My sense is no, they're not,
> > provided that we continue to use quilt this way.
>
> Personally I don't truly understand what the vendor branch is for,
> maybe I'm too new to the XSF to appreciate it? Is it a back-up measure
> in case a holocaust strikes and all upstream copies of the original
> source are completely lost? The only argument I've heard refers to the
> autobuild system, I'll comment on that at point 2.
Right, that's my sense.
> Like you, I tend to feel keeping explicitly separate patches makes for
> a cleaner solution when dealing with upstream source the size of
> X.org. Otherwise you've got to rabbit through the entire debian
> diff.gz file to try to find what we changed from the upstream source.
> Keeping separate patches makes it simpler to push particular fixes
> upstream, I think.
I agree. I think quilt has worked out extraordinarily well for us.
> That said, it does seem reasonable to me to keep a single copy of the
> upstream tarball (i.e. orig.tar.gz) in our repository. And my comments
> here are perhaps not quite so useful in the case where we wrap our own
> orig.tar.gz tarball from the latest upstream git sources.
Yes, I think it's reasonable too, although perhaps not optimal. As Andres
noted, it does suck up a lot of bandwidth, as well as processor time when
working with such a large repo. I really like being able to make my patches
directly in the repo, but importing them with quilt is fairly simple as
well, so I'd be willing to sacrifice this conveneince for the added speed
elsewhere.
> > 2) Do we keep putting the upstream tree in our svn repo? My sense is that
> > we should continue to do so. The reason being that we regularly are
> > patching the auto* build system from upstream. Keeping those generated
> > files in-tree ensures that we have the same build system from machine to
> > machine. This is a hideously fragile system as it is, and keeping things
> > in-tree seems to provide some resiliancy. If someone has a good
> > mechanism to get around this, I'm all ears, because it is a pain to keep
> > it all in-tree.
>
> I presume you mean here the upstream source in the working branch
> copy? Don't patches apply well enough to the autobuild files as much
> as the source files? I think I'd be comfortable keeping upstream
> source in branches, but I suppose it's "cleaner" to extract upstream
> source directly from the tarballs to ensure no patching is missed. Is
> there any reason why any build-system changes can't be handled by
> patches like any other change?
Right, I think the autobuilder thing isn't really a big issue. There are
definite conveniences keeping the upstream tree in the repo. On the other
hand, svn-buildpackage is supposed to handle building packages from repos
that don't keep the upstream tree inside, but I'm not sure if this tool
will currently work with our repo.
> > 3) Do we need to keep using quilt? Branden's original plan was to keep the
> > upstream source in-tree and not use dpatch or quilt or anything like it.
> > This is an option, but if we go this route we need to keep using the
> > vendor branch. I'm inclined towards quilt myself, as its proven and it
> > works. On the other hand, we're carrying around quite a bit of code to
> > make sure quilt works for us. My plan is to switch our system over to
> > what's built-in to the quilt package to make the less of our problem,
> > but some people still prefer to keep it all in the repository.
>
> I feel like I'm starting to repeat myself now :) I like patching
> because it declares explicitly what Debian has changed from upstream.
> It lets us keep those changes in discrete units so we know what each
> individual one is for. I'm inclined to think that makes it easier for
> pushing the patches upstream.
>
> In fact that was why I had chosen to use dbs for xprint - dbs keeps the
> upstream source explicitly in its original pristine tarball which is
> only unpacked at build time. Patches to that upstream source are
> created separately and explicitly.
I agree, although dbs is gross.
> > Please reply and let me know what you want and why you want it that way.
> > Again, I don't care so much about the details provided that we are working
> > in the best way possible. If what we're doing now isn't working for people,
> > then we need to find a solution.
>
> Likewise, I don't really mind what we do, so long as the consensus is
> documented so that we know what we're doing!
Right, I need to use the wiki more. :-\
- David Nusinow
Reply to: