I’ve searched around a bit, but haven’t found a satisfactory answer, so I’d like to hear your opinions on this.
I have a couple of tools which I have to update and deploy to a few servers every now and then. The source is managed in a SVN repository.
To save myself the bother of copying the binaries to the production servers by ftp or similar means (I have no means of building the projects on the servers), I’m thinking of creating an area in the repository to commit them as well. I could then simply retrieve the most current version of the executables from the svn server whenever I need them.
Since I don’t necessarily want to update/commit the binaries every time I work on the source, I would not create the folder for the binaries as a subfolder of my project. Committing the binaries would then (and should) be a separate, conscious act.
--- trunk --- project1 --- project2 --- built --- project1 --- project2 As far as I can see, there should be no problems with this setup. What I’d really like is to then give both the source revision and the binaries a single tag, so as to be able to retrieve everything that belongs together at once.
--- tags/project1/release2/ includes files from --- trunk/project1/ revision 487 and --- built/project1/ revision 488 Is what I’m after possible, and how would I achieve it? Should I instead be looking at some other way of solving this problem?
There’s nothing weird about your setup (I’m doing similar things with both build tools and build artifacts when I need to preserve the exact bits.) The layout you want is definitely possible – to ‘include’ specific versions of other branches or tags in your tags/project1/release2, all you need to do is set svn:externals properties on tags/project1/release2 referencing the URL of the sources and revisions you want to pull in, and you’re set.