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. **************************************************************************************
