[Pkg-bluetooth-discuss] svn repository restructuring
oystein at gisnas.net
Wed Aug 22 06:30:20 UTC 2007
2007/8/21, Eddy Petrişor <eddy.petrisor at gmail.com>:
> On 21/08/07, Mario Iseli <mario at debian.org> wrote:
> > Hello Bluetooth Team :)
> > We (Filippo Giunchedi, Eddy Petrisor, $myself) just had a little
> > discussion on IRC about the structure of our svn repository. At the
> > moment we save _all_ upstream stuff in svn, including tarballs and the
> > whole stuff again with every upload (tags). Please see for example the
> > following:
> > mario at aismis:~/src/svn.debian.org/pkg-bluetooth/bluez-libs$ ls
> > branches/*
> > 3.11 3.12 3.13 3.14 current
> > => 5 times the source
> > mario at aismis:~/src/svn.debian.org/pkg-bluetooth/bluez-libs$ ls tarballs/
> > bluez-libs-3.11.tar.gz bluez-libs_3.12.orig.tar.gz
> > bluez-libs_3.14.orig.tar.gz
> > => 3 times the tarball
> > mario at aismis:~/src/svn.debian.org/pkg-bluetooth/bluez-libs$ ls tags/
> > 2.22-0exp1 2.24-0exp1 2.24-1 2.25-2 3.0-1 3.1-1 3.10-1 3.11-1
> > 3.12-1 3.13-1 3.14-1 3.5-1 3.7-1 3.9-1
> > => ~15 times the whole source + debian/ directory.
> > We have now 11 projects in our svnroot, and this number will probably
> > grow, as you can imagine we use quite a lot of discspace now.
> > mario at aismis:~/src/svn.debian.org/pkg-bluetooth$ du -sh
> > 482M .
> > Ok, so... we need a new structure I think, the problem is that most
> > people have a different meaning about those structures. My (other
> > opinions welcome) way would be:
> > svnroot/TODO
> > svnroot/pkg1
> > svnroot/pkg2
> > svnroot/pkg2/tags
> > svnroot/pkg2/trunk
> > svnroot/pkg2/tarballs svnroot/packages/tarballs (NOT in SVN)
> > svnroot/pkg2/build-area (symlink to svnroot/build-area)
> > svnroot/tarballs (empty dir in svn)
> > svnroot/build-area (empty dir in svn)
> In svn-buildpackae terms this is layout 1.
> I would rather use layout 2:
> svnroot/packages/trunk/tarballs (NOT in SVN)
> About the tarballs dir I want to mention something, this could be
> whatever the user wants, a plain dir or a symlink to ../tarballs
> (while ../tarball is a real directory).
> Also version 0.6.22 of svn-buildpackage will be able to create that
> directory when used in conjunction with the origUrl feature.
> > upstream tarballs in the repository, I have always to download them
> > myself. Eddy Petrisor told me that there is an svn property to set an
> > URL where svn-buildpackage can fetch the orig.tar.gz itself.
> Yes, this is the origUrl feature which allows better working
> conditions for teams. In order to prevent the need to download by hand
> each orig tarball, one has to set the property svn-bp:origUrl to be an
> URL of a valid orig tarball available somewhere where it can be
> fetched via wget.
> For instance, if you have bluez-utils version 0.26-1 in svn trunk (as
> we do now) and you just did the update to a newer version), and you
> uploaded the orig tarball to a place (let's say is
> you would need to set svn-bp:origUrl (and commit the change) this way
> (ran in the checkout of the trunk directory of bluez-utils):
> svn propset svn-bp:origUrl
> The next user (using a clean machine) will be able to just checkout
> the bluez-utils trunk directory and then just run these to build the
> mkdir ../tarballs # will not be needed anymore starting with 0.6.22
> svn-buildpackage will take care to download for you the orig tarball
> and will save it in the ../tarballs directory under the proper name
> (although, as you might have observed, it was not bearing the proper
> name in the remote location).
> > I'm waiting for your suggestions...
> Also, in some future version of svn-buildpackage a new feature that
> allows to set a remoteOrigDir(s) option and svn-buildpackage will try
> to download the orig tarballs from that place (assuming is a
> directory) and one will not need to update the svn-bp:origUrl property
> at every update of the package.
> P.S.: svn-buildpackage patches are welcome
I like the pkg-gnome layout. The task of downloading packages can be
supported by a simple script, which can also verify the md5sum.
The pkg-gnome layout essentialy focuses on the Debian distributions,
with tags of every official release. See
More information about the Pkg-bluetooth-discuss