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. [...] > > 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? > 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.. > 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
