Re: svn management, git, etc
On Tue, Aug 08, 2006 at 03:59:13AM -0400, Andres Salomon wrote:
> On Sat, Aug 05, 2006 at 06:12:19PM +0000, David Nusinow wrote:
> > Hi everyone,
> [...]
> > he's got a lot of experience. Either way, I'm 100% unwilling to do any sort
> > of switch until after we're frozen for etch, and even then there are issues
> > like where to host it that need to be solved.
> >
>
> I've complained a lot about SVN in the past; however, a lot of my complaints
> have to do more with the way we're using it. The SVN repo is hosted on a dsl
> connection, which makes it quite slow to do a check-out; on top of that, we
> need to deal w/ 3 separate branches (trunk, 7.1, and vendor) in order to work
> with it. And finally, we're tracking upstream's source as well, which makes
> for a whole lot of unnecessary stuff that must go across the network (and
> sit on my hard drive). Working with SVN would be a lot less of a hassle if
> the repository was a fraction of the size that it is now.
Right, I'm currently thinking that the vendor branch can and will go. I'll
give a few more days with it to see if anyone else speaks up in favor of
it, but currently it's slated for death.
As for the 7.1 versus trunk, I don't have a good way around that. It's just
a limitation of svn to need full checkouts for branches.
> > 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.
> >
>
> Is there a point to keeping a vendor branch? Upstream provides tarballs,
> upstream provides a git repository that's far more useful than our per-release
> vendor commits, and we have orig.tar.gz files on debian mirrors all over the
> world.. What does a vendor branch buy us?
Relatively little. If you want to easily diff the auto* stuff, it gives you
that. Other than that, not much. The auto* stuff didn't come in handy so
much as I'd hoped, so yeah... vendor can probably just go defunct unless
we have some real reason to keep it.
> > 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.
> >
>
> The only good reason I'm aware of for keeping the upstream tree in our SVN
> repo is for the auto* stuff; and there is no guarantee that what's in
> the debian archive is actually what's in the SVN repo. Have you ever
> autoreconf'd out of habit w/ updated auto*, without thinking twice about it?
> I have. Committing those changes to a repository is an extra step, and
> doesn't seem overly worth it.
>
> Instead, let's enforce certain things. If we desire having a certain version
> of autoconf, automake, and libtool used for our packages, let's have checks
> in the actual code to ensure certain versions are used. AC_PREREQ() in
> configure.ac comes to mind, for example. Ensuring that a certain version
> of xutils-dev is used to rebuild could be done (looking closer, it appears
> someone's already implemented the framework for this:
> XORG_MACROS_VERSION(x.y)). And so on..
I'd also like to shrink the repo. We'll need something concrete. We need to
know if we can use or adapt svn-buildpackage so that the build process is
automated.
Also, would you mind producing a patch for some package to use as a testbed
for this? We'd need a way to easily enforce this across the whole package
set too. The patch mechanism we currently have isn't up to snuff for that
obviously, demanding a lot of manual labor. I don't know how to fix that
though.
> > 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 like the patching system that's currently in place.
Me too. I think the consensus is to keep it, although I think pushing the
logic in to the quilt package is wise.
- David Nusinow
Reply to: