From users-return-16643-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Fri Nov 9 10:15:37 2012 Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9B7B2D7E8 for ; Fri, 9 Nov 2012 10:15:37 +0000 (UTC) Received: (qmail 26694 invoked by uid 500); 9 Nov 2012 10:15:36 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 26664 invoked by uid 500); 9 Nov 2012 10:15:36 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 26620 invoked by uid 99); 9 Nov 2012 10:15:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Nov 2012 10:15:34 +0000 X-ASF-Spam-Status: No, hits=-1.6 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [207.126.144.115] (HELO eu1sys200aog103.obsmtp.com) (207.126.144.115) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Nov 2012 10:15:28 +0000 Received: from UKHC-SMTP.dps.local ([64.212.99.80]) by eu1sys200aob103.postini.com ([207.126.147.11]) with SMTP ID DSNKUJzXqcNKkpnHC0yyWuNgNhoRTmTJ4Fsm@postini.com; Fri, 09 Nov 2012 10:15:07 UTC Received: from DESA-Exchange.emea.dps.local (desa-exchange.emea.dps.local [192.168.55.10]) by UKHC-SMTP.dps.local (Postfix) with ESMTP id 4DDE0126944 for ; Fri, 9 Nov 2012 10:15:05 +0000 (GMT) Received: from [10.49.3.210] ([10.49.3.210]) by DESA-Exchange.emea.dps.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Nov 2012 11:15:04 +0100 Message-ID: <509CD7A9.7040901@dominolaser.com> Date: Fri, 09 Nov 2012 11:15:05 +0100 From: Ulrich Eckhardt Reply-To: users@subversion.apache.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: users@subversion.apache.org Subject: Re: SVN Usage Questions References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2012 10:15:04.0996 (UTC) FILETIME=[165EBE40:01CDBE63] X-Virus-Checked: Checked by ClamAV on apache.org 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. **************************************************************************************