Gunnar Wolf wrote:
> Don't assume on me, sometimes I'm too stupid or stubborn for my own
> good ;-)
Heh, ok. I just can't imagine doing it since if I were to check out some
of my svn repos starting at the root rather than at trunk, I'd need
hundreds of gigabytes of disk. :-)
> Maybe (part of) our problem lies with svn-buildpackage being meant to
> be used on simple trees, not on repositories with so many independent
> modules as ours? Maybe we should rather seek a more apt structure,
> which allows us to check out the whole tree at once without getting
> the whole structure. We could do this by having a slightly unkosher
> managing of tags and branches, something like (taking from our current
> usage):
I use such a layout for most of my packages; the d-i team uses it, etc.
There's nothing unkosher about it. With the exception of
svn-buildpackage and its companion tools svn-inject and svn-upgrade[1],
all other svn tools that I know of will support a combined trunk
structure transparently. The basic rule is that you should be able to
s/trunk/tags/ or s/trunk/branches/ in any svn uri and get to the tags
or branches; any reasonable svn tool will support any repository that
follows that rule no matter how it's laid out.
If you use svn-buildpackage, you have to deal with its nonstandard way
of finding the tags and branches, which defaults to looking in
../branches and ../tags from the svn uri, which will not work with a
combined trunk. So you'd have to work around this by setting up a
.svn/deb-layout for each package giving the actual uris to use. This
would of course, be slightly annoying especially since that file can't
go under revision control. Probably a simple perl script could set up
the files though.
--
see shy jo
[1] I have a svn-uupgrade that supports this transparently, but the
maintainer of svn-update did not seem interested in it.
Attachment:
signature.asc
Description: Digital signature