subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Eckhardt <ulrich.eckha...@dominolaser.com>
Subject Re: SVN Usage Questions
Date Fri, 09 Nov 2012 10:15:05 GMT
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.
**************************************************************************************


Mime
View raw message