Am 08.11.2012 23:39, schrieb Ahmed, Omair (GE Oil & Gas):
> I am looking for some guidance on where to store build artifacts in SVN.
Generally, the advise is not to store build artifacts. Compiled binaries
can't be merged or diffed meaningfully, which makes them "dead ends" as
far as their handling is concerned.
That said, there are cases where this really makes sense, and that is in
particular when making a release who's binary results are shipped to
customers. In that case, it isn't really important that this is an
endpoint in development and not further modified. The important point is
rather that you can retrieve the exact binaries that were shipped to
customers if/when they report problems etc. If you then need to change
anything, you simply create a second release that has a similar base but
is not directly derived from the earlier one. These releases are very
similar to what is customary called a tag in SVN.
> Our proposed process calls for the build engineer to copy the code from
> the SVN repo to the build server. When a build has been executed, where
> should we copy the artifacts (the executables) back to? Is the /release
> directory appropriate or is the another "standard" way to store the
> artifacts?
Firstly, I would use a working copy instead of manually copying things.
This should also be the approach for making a "nightly build" (for
continuous integration), except that you don't store the nightly build
results. In order to make a release, I would first assemble the required
sources by copying or linking (via svn:external) them into a working
copy. Alternatively, check out a working copy of the sources, if they
only consist of a single project folder. Then, build the sources. If the
build succeeds (and perhaps after some testing), I would add the build
artifacts and commit this to a new release folder. Make sure that you
don't commit this to the regular development folder but instead copy the
whole working copy including the added binaries to the new location.
This can and should be scripted, so that the script knows exactly which
source versions you use and to avoid avoid error-prone human interaction.
Note: Copying things is cheap in SVN, concerning both time and space,
since representations are shared and only differences take up space.
Creating a copy of several hundred MB of sources is therefore not a big
deal. You should refrain from checking out a whole repository as a
working copy though!
> Secondly, if we check-in to the /release folder, what mechanism is there
> to readily identify the artifacts. Do we create a /release/rel_1 type
> structure or is there some labeling convention available in SVN? Unless
> I am I missing something very obvious, I don't see a way to apply labels
> in SVN.
Applying labels? SVN just versions file trees. All other things like the
trunk/branches/tags structure are purely by convention. Further, you can
also set custom properties ("svn propset ..") on items in the
repository, which you can also use internally. All you have to do is
decide on a convention how the meaning you attach to some things is
represented in SVN.
Good luck!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Hans Robert Dapprich, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich.
**************************************************************************************
Received on 2012-11-09 11:15:43 CET