Re: Best practice for tagging built artefacts

[Andy Peters <de...@latke.net>]

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