You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Cornwell, Ian H" <Ia...@mottmac.com> on 2006/10/31 13:01:50 UTC
Best practice for tagging built artefacts
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?
Ian
-------------------------
Mott MacDonald Ltd.
1 Atlantic Quay
Broomielaw
Glasgow G2 8JB
Direct tel: +44 (0)141 222 4576
-------------------------
This message is from Mott MacDonald Limited, registered in England
number 1243967. Registered office: St Anne House, 20-26 Wellesley Road,
Croydon, Surrey, CR9 2UL, England.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best practice for tagging built artefacts
Posted by 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
Re: Best practice for tagging built artefacts
Posted by John Waycott <ja...@cox.net>.
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?
>
> Ian
>
Look at your CM processes and organize Subversion repositories around that.
We store deployment artifacts in an area that is separate from the
source. We do that for several reasons. First, a different group of
users than developers need access to the final output. Second, different
people need to be notified when someone commits a deployment artifact.
Most importantly, our deployment artifacts go through a different
process of testing, review and certification.
A repository should contain the source for a particular process. I don't
think it is a good idea to mix the outputs of a process with the source
for those outputs. Create a different area in the repository for that.
For example you, could have /branches, /tags, /trunk, /releases. Put all
your deployment artifacts under /releases to keep them separate from the
source.
-- John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best practice for tagging built artefacts
Posted by Reinhard Brandstädter <re...@jku.at>.
I would suggest another solution:
create another directory on the same level as /trunk and /tags
called /artefacts or /archives and everytime you tag a build
(eg. /tags/myfancysoftware-1.2.3/ src....) you place the artefacts in the
artefacts directory /artefacts/myfancysoftware-1.2.3/*.zip or
even /artefacts/myfancysoftware-1.2.3.zip (if you can place all your
artefacts in one zip file)
The advantages of this approach are:
1) you get a directory with downloadable versions of your product
2) it's easily automateable (either your build scripts create the tag and
place the artefacts with in the correct name in the correct directory, or you
create the tag and a post commit hook starts the build and commits the
artefacts)
Apart from that i favor the solution not to put build artefacts in a
repository (because most often they are big binary files, sometimes even CD
images). I rather ensure that everything needed to rebuild from a tag is
included in that tag.
Reinhard
On Tuesday 31 October 2006 14:01, 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?
>
> Ian
>
> -------------------------
> Mott MacDonald Ltd.
> 1 Atlantic Quay
> Broomielaw
> Glasgow G2 8JB
>
> Direct tel: +44 (0)141 222 4576
> -------------------------
> This message is from Mott MacDonald Limited, registered in England
> number 1243967. Registered office: St Anne House, 20-26 Wellesley Road,
> Croydon, Surrey, CR9 2UL, England.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org