[Pkg-bluetooth-discuss] svn repository restructuring

[Øystein Gisnås]

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/tarballs)
> > 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/pkg1
> svnroot/packages/trunk/pkg2
> svnroot/packages/trunk/pkg3
> svnroot/packages/trunk/tarballs (NOT in SVN)
> svnroot/packages/tags/pkg1
> svnroot/packages/tags/pkg2
> svnroot/packages/tags/pkg3
> svnroot/packages/branches/pkg1
> svnroot/packages/branches/pkg2
> svnroot/packages/branches/pkg3
> svnroot/people/eddyp
> svnroot/people/tiCo
> ...
>
> 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
> http://users.alioth.debian.org/~filippo/tarballs/bluez-utils-0.26.tgz)
> 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
> 'http://users.alioth.debian.org/~filippo/tarballs/bluez-utils-0.26.tgz'
> debian
>
> 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
> package:
>
> mkdir ../tarballs # will not be needed anymore starting with 0.6.22
> svn-buildpackage
>
>
> 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
http://svn.debian.org/wsvn/pkg-gnome/packages/?rev=0&sc=0

Øystein