Fabian Fagerholm wrote: > Thanks to jcollins@asgardsrealm.net and joeyh@debian.org for their > insight into this issue. I will try to summarize everything in this > reply to myself. Nice job writing this up, here are some corrections. > The repository will have the following structure: > > trunk/ > projectA/ > projectB/ > ... > branches/ > projectA/ > projectB/ > ... > tags/ > projectA/ > projectB/ > ... > vendor/ > projectA/ > projectB/ > ... > > The advantage of this might be that the svn:externals property might > work better. (TODO: verify, why) The reason I prefer this layout is I can check out the whole trunk/ directory here, and get a nice directory with all my debian packages (projectA, projectB, projectC..) in it. No need for svn:externals at all. > Option B.A.: Per-project trunk/, branches/ and tags/ > > The repository will have the following structure: > > projectA/ > trunk/ > branches/ > tags/ > projectB/ > trunk/ > branches/ > tags/ > ... Compare with a layout like this one. If I want a directory with all my projects, I must either check out the whole repository (likely not an option due to disk spack), or set up a directory with a svn:externals propery like this: projectA svn://wherever/projectA projectB svn://wherever/projectB projectC svn://wherever/projectC And maintain this. The maintenance burden, coupled with the limitations of svn:externals (which some subversion developers don't like and would prefer to just remove), make me prefer to avoid svn:externals when possible. Of course, there are advantages to the toplevel project layouts too. For one thing, the tags and branches directories are closer to the trunk directory, which can make it be less typing to tag projects, work with branches, and so on. Just do a svn info, and paste the repo url, changing the last word of it from trunk to tags. I've lately been working on tools to automate this kind of thing, for example I have a svnpath tool that I use to get directories for tags and branches. It works with either repo layout, like this: svn cp `svnpath` `svnpath tags`/new-tag Will make a new tag of the project I'm cd'd to. This is in my subversion repository in the bin directory along with other tools to do automated committing and tagging based on the debian/changelog. > * B.B. svn_load_dirs -t tags/projectX/upstream/<version> > url://host/repos/ branches/projectX/upstream > /path/to/new/version I've only ever had to do this once, and I tried a svn_load_dirs command like that and watched it try to check out the root of my repository. 10+ gb of files (hundreds of versions of most packages) over dialup. The thing is very badly documented, but I eventually worked out that I could run it like this: svn_load_dirs url://host/repos/branches/projectX upstream /dir This leaves me doing the tag myself of course. Even when run this way it apparently checked out all of url://host/repos/branches/projectX/, which could be quite painful if you have a lot of branches. I hope this tool gets improved. > Then export (svn export) the current tag and build the package. You also > need to export the upstream source and turn it into an .orig.tar.gz. Please don't do that. Keep an archive of your .orig.tar.gz's and copy the tarball into place before doing the build so we can have pristine source. I personally use a local mini-dinstall repository that I upload all my packages too, that way I have all the released packages handy, along with their sources. Another approach is the check the orig tarballs into svn, if you're optimistic about the ever-falling price of disk space. :-) -- see shy jo
Attachment:
pgpiuN5FRNGYY.pgp
Description: PGP signature