Re: svn management, git, etc
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.
Reply to: