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 242E11022B for ; Thu, 22 Aug 2013 19:18:36 +0000 (UTC) Received: (qmail 50414 invoked by uid 500); 22 Aug 2013 18:16:35 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 50397 invoked by uid 500); 22 Aug 2013 18:16:34 -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 50386 invoked by uid 99); 22 Aug 2013 18:16:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Aug 2013 18:16:33 +0000 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE X-Spam-Check-By: apache.org Received-SPF: error (nike.apache.org: local policy) Received: from [74.208.4.200] (HELO mout.gmx.net) (74.208.4.200) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Aug 2013 18:16:27 +0000 Received: from [10.200.226.14] ([209.165.141.252]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0LwIyO-1W8PRX0L6s-01867b for ; Thu, 22 Aug 2013 20:15:45 +0200 Message-ID: <5216554F.1080209@gmx.us> Date: Thu, 22 Aug 2013 11:15:43 -0700 From: Edwin Castro <0ptikGhost@gmx.us> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: users@subversion.apache.org Subject: Re: Switching References: <910250F21FAA2A4E8F72DD21EA7807660906148C@VMJudi.corp.rotair.com> <1B05D8F50421E24799AE93B03CC284BE01CAE9CCEB@CRPMBX01.corp.cbeyond.net> <910250F21FAA2A4E8F72DD21EA78076609065B00@VMJudi.corp.rotair.com> <1B05D8F50421E24799AE93B03CC284BE01CAFDB285@CRPMBX01.corp.cbeyond.net> <910250F21FAA2A4E8F72DD21EA78076609066DB2@VMJudi.corp.rotair.com> <521648D3.7070308@gmx.us> <910250F21FAA2A4E8F72DD21EA7807660906CF26@VMJudi.corp.rotair.com> <910250F21FAA2A4E8F72DD21EA7807660906CF7E@VMJudi.corp.rotair.com> In-Reply-To: <910250F21FAA2A4E8F72DD21EA7807660906CF7E@VMJudi.corp.rotair.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:G8A410Awn5QHk654zY8hPIWNlRcR8bELCc4z33JiV6o+02mZM8D hFvfjtVcsYvtlqZnZzpsptIc9nTl5x2PT1sqs54HFqLdYolJfEm7qLUdtaQNskxUTG5HRgk 7FyX5fqXiqS+Mt89NjCr7cU6Vg2T0Jy60d6dXLCRiU0G2vkff8ucB5r+sXcjyLMmeAZ3lYM UZiKZWAkuP+jcLx96JDsA== X-Virus-Checked: Checked by ClamAV on apache.org I agree with Les here on the point about making sure you can automate the process correctly only with versioned resources. In our CI builds we have the versioned resources configured so that all tests are executed every time. Developers execute subsets of tests through their tools and are expected to manage their tools on their own. Sounds like there might be a trade off between copying/reconfiguring if they choose one working copy per branch and reconfiguring if they clean/switch between branches. That might be best left as an individual developer decision. On 8/22/13 10:58 AM, John Maher wrote: > You are correct that there will be issues with a fresh checkout. But I can live with that. The code will not be affected, just the way the code is tested. Once the developer decides on how they wish to test I do not want to A) lose those changes or B) step on the choices others have made by versioning it. > > Think config or settings file. > > -----Original Message----- > From: Les Mikesell [mailto:lesmikesell@gmail.com] > Sent: Thursday, August 22, 2013 1:53 PM > To: John Maher > Cc: Edwin Castro; users@subversion.apache.org > Subject: Re: Switching > > On Thu, Aug 22, 2013 at 12:43 PM, John Maher wrote: >> The clean up script is a good idea but won't work here. We have mostly all class libraries. One executable. This means to test we need to specify an application in the project. Some developers use the exe while some use a tool made just for testing the classes. This information is in the *.sou files which are unversioned for this reason. So we don't want to delete them (as I incorrectly stated somewhere) but ignore them. > You are sort-of asking for trouble if you have any dependency on unversioned files being in a workspace at all, much less for them to continue to exist when switching among versions with/without the > containing directories. I'd advise stepping back from the immediate > problem and thinking of processes that will always work with a fresh checkout so that in the future you can use build automation tools like jenkins, relying only on the contents of the repository even when the build happens on a new host. It will simply your life even for manual operations if you can count on that. >