Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 89042 invoked from network); 23 Sep 2005 10:38:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 23 Sep 2005 10:38:34 -0000 Received: (qmail 51242 invoked by uid 500); 23 Sep 2005 10:38:28 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 50867 invoked by uid 500); 23 Sep 2005 10:38:23 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 50849 invoked by uid 99); 23 Sep 2005 10:38:22 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Sep 2005 03:38:22 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [130.237.222.115] (HELO smtp.nada.kth.se) (130.237.222.115) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Sep 2005 03:38:28 -0700 X-Authentication-Info: The sender was authenticated as danielf using PLAIN at smtp.nada.kth.se Received: from [130.237.218.93] (cvap80.nada.kth.se [130.237.218.93]) (authenticated bits=0) by smtp.nada.kth.se (8.12.11/8.12.11) with ESMTP id j8NAbwjS002891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Sep 2005 12:37:58 +0200 (MEST) Message-ID: <4333DB05.2050000@nada.kth.se> Date: Fri, 23 Sep 2005 12:37:57 +0200 From: Daniel Fagerstrom User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] Are svn externals a good idea? References: <5E091A68F794974CAF431CA31F5AF2CC3C4E2D@server.bizzdesign.nl> In-Reply-To: <5E091A68F794974CAF431CA31F5AF2CC3C4E2D@server.bizzdesign.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N We should only use externals to projects with own release cycles. The idea of breaking out the blocks from trunk was to start considering them as separate projects with separate release cycles. The when we do a "compound" release of Cocoon core together with all blocks, all the externals in the taged compound release should point to tagged releases of the blocks. This certainly isn't our current practice. But I think we need to start considering the blocks like separate projects sooner rather than later. Its time that we stop thinking about Cocoon as one huge beast where everything is connected to everything else. First it isn't, and second it doesn't scale at all. Thinking more about it: with the wild card includes for configurations and sitemaps, is there still anything that prevent us from having binary releases? /Daniel Bart Molenkamp wrote: >Sorry, hit the send button too early... > >You can specify a revision within the svn:external property. Something >like (got this sample from the svn book): > >third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker > >So I think, when you've labelled cocoon 2.1.8, you should change the >svn:externals property in that tag one more time an let it point to the >CForms block with the same revision number as the revision that >committed the tagging of version 2.1.8, right? > >Bart. > > > >>>-----Oorspronkelijk bericht----- >>>Van: Carsten Ziegeler [mailto:cziegeler@apache.org] >>>Verzonden: vrijdag 23 september 2005 11:49 >>>Aan: Cocoon-Dev >>>Onderwerp: [RT] Are svn externals a good idea? >>> >>>I'm just wondering if svn externals are a good idea wrt to >>> >>> >versioning. > > >>>I just had to checkout an older version of 2.1.8-dev and checked out >>>that particular revision. Now unfortunately, the jcr block (and now >>> >>> >>the >> >> >>>forms block) is linked into the tree using a svn external. And >>> >>> >>although >> >> >>>I checked out an old version of the cocoon tree, I get the latest >>>version from the jcr block. So it's not that easy to get the exact >>>version of the whole tree. Or is there an easy way? >>> >>>And what does this mean wrt to tagging a release (which is a copy of >>> >>> >>the >> >> >>>source tree)? >>> >>>Carsten >>>-- >>>Carsten Ziegeler - Open Source Group, S&N AG >>>http://www.s-und-n.de >>>http://www.osoco.org/weblogs/rael/ >>> >>> > > > >