[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Best practice for tagging built artefacts

From: John Waycott <javajohn_at_cox.net>
Date: 2006-10-31 14:45:08 CET

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
Received on Tue Oct 31 14:46:17 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.