On Oct 31, 2006, at 6:01 AM, Cornwell, Ian H wrote:
> We are in the process of migrating to subversion.
> We are having a discussion on how we should tag our built artefacts /
> deployment bundles.
> We are sure we want to include our deployed artefacts in the
> repository.
>
> We see 2 viable options, but we have not yet agreed which is best.
>
> Let's assume that we already have a source tag, and that we have built
> that and produced a set of files for deployment.
>
> Option A) Commit the deployment files to trunk (or a branch), and make
> another release tag from trunk (or a branch).
>
> Option B) Commit the deployment files straight to a new tag in tags/
> without them ever having been in trunk.
>
> Different engineers here see different advantages and disadvantages in
> the two options. It could be an advantage not to have the deployment
> files in trunk, because we are only ever interested in tags of
> deployment files.
>
> What do you think is the best practice for tagging deployment files?
I use Subversion for FPGA development, and I put build results (the
bit files and the EEPROM images) in a tag. This is done because even
with the same source could and build script, it's possible that the
FPGA tools may change routing or whatever (this commonly occurs when
the FPGA tools change) and having checksums and images for each
release that match what's in the field is important.
Basically, my trunk format is:
project/trunk/src
/fitter
/testbench
/tags
/branches
and my build scripts create a directory called \bin at the same level
as \src, \fitter and \testbench. Whenever I release something, I get
rid of all of the cruft from the bin directory (various reports, etc)
and do an svn add on the directory. I don't commit the change,
though; I create a tag using svn copy:
$ svn copy project http://repo/project/tags/v1.0
which puts the relevant build results as well as the code and scripts
used to make it in the v1.0 tag:
project/trunk/src
/fitter
/testbench
/tags/v1.0/src
/fitter
/testbench
/bin
/branches
then a simple svn revert undoes the change in the working copy:
$ cd project; svn revert
so the working copy no longer thinks the bin directory is part of the
working copy. You need to do this because if you commit any other
changes back to the trunk, the bin directory would be included, which
you don't want.
Hope this helps,
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 1 19:53:17 2006