From dev-return-39075-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Tue Mar 16 22:55:40 2010 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 20197 invoked from network); 16 Mar 2010 22:55:40 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 16 Mar 2010 22:55:40 -0000 Received: (qmail 77001 invoked by uid 500); 16 Mar 2010 22:55:39 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 76965 invoked by uid 500); 16 Mar 2010 22:55:39 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 76956 invoked by uid 99); 16 Mar 2010 22:55:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Mar 2010 22:55:39 +0000 X-ASF-Spam-Status: No, hits=-1.6 required=10.0 tests=AWL,FREEMAIL_FROM,SPF_NEUTRAL,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: 194.196.100.163 is neither permitted nor denied by domain of mark.hindess@googlemail.com) Received: from [194.196.100.163] (HELO mtagate3.uk.ibm.com) (194.196.100.163) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Mar 2010 22:55:32 +0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o2GMtAdO012710 for ; Tue, 16 Mar 2010 22:55:10 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o2GMtAK41405162 for ; Tue, 16 Mar 2010 22:55:10 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o2GMtAhV010072 for ; Tue, 16 Mar 2010 22:55:10 GMT Received: from anaheim.local (sig-9-145-236-171.de.ibm.com [9.145.236.171]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id o2GMt9P1010065 for ; Tue, 16 Mar 2010 22:55:10 GMT Message-Id: <201003162255.o2GMt9P1010065@d06av04.portsmouth.uk.ibm.com> X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-18) with nmh-1.3 In-reply-to: <3b3f27c61003141715s2a4fa3b4vb5ead378f2f82f17@mail.gmail.com> References: <16800226.1081268475132077.JavaMail.hudson@hudson.zones.apache.org> <14752481.1091268475640815.JavaMail.hudson@hudson.zones.apache.org> <20100313104027.67B61816020@nike.apache.org> <5899fca71003131235w5ae9e96anec0e962aa35e5f00@mail.gmail.com> <-4379907504050986006@unknownmsgid> <3b3f27c61003141715s2a4fa3b4vb5ead378f2f82f17@mail.gmail.com> Comments: In-reply-to Nathan Beyer message dated "Sun, 14 Mar 2010 19:15:22 -0500." From: Mark Hindess To: dev@harmony.apache.org Subject: Re: svn layout Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Mar 2010 22:55:08 +0000 In message <3b3f27c61003141715s2a4fa3b4vb5ead378f2f82f17@mail.gmail.com>, Nathan Beyer writes: > > On Sun, Mar 14, 2010 at 2:47 AM, Mark Hindess > wrote: > > > > In message <5899fca71003131235w5ae9e96anec0e962aa35e5f00@mail.gmail.com>, > > Tim Ellison writes: > >> > >> [snip] > >> > >> Only to the extent that the whole switching thing makes sense. > >> Never liked that. > > > > Nor me. I don't like the complexity of it. I particularly don't > > like that if you made a connected classlib/drlvm change in java5 > > trunk you had to do a merge to fix the java6 tree immediately > > because the java6 tree uses the java5 drlvm. This used to happen > > quite often with common_resources but I've pulled that back into > > trunk now so that one is "fixed". (We could fix this by creating a > > drlvm java6 branch but then I/we'd have yet another tree to merge.) > > > >> Anyway, I guess so, even though it seems a shame to take up so much > >> unused space. > > > > So why do we keep the "svn switch" structure? If we got rid of the > > svn switched layout then we'd have: > > > > trunk/... > > trunk/classlib/... > > trunk/drlvm/... > > trunk/jdktools/... > > > > and: > > > > branches/java6/... > > branches/java6/classlib/... > > branches/java6/drlvm/... > > branches/java6/jdktools/... > > Removing the 'svn switch' idiom is fine by me and this suggestion > seems fairly straightforward, so I'm in agreement. I've thought about this a bit more. We've a plan (though I'm not sure what progress is being made) to merge jdktools/branches/java6 back to the jdktools/trunk so we'd have less branches. This would mean that the java6 branch would only really be for classlib. And in future, any time we make another branch for one component, we have to branch everything. However the duplication of the other components doesn't really cost anything unless/until changes are made so I don't think this is really a disadvantage and the reduction in complexity more than makes up for this. Unless anyone says otherwise (or says they need more time to think about downstream processes?), I'd like to push ahead with this next week. I'll try to figure out the mechanics of changing existing workspaces without losing changes and I'm happy to fix up the hudson builds if we go forward with this. Regards, Mark. > > The only real differences is that we'd have a distinct copy of drlvm > > in the java6 branch that we don't currently have but actually that > > is arguably an advantage since it breaks the coupling (mentioned > > above). > > > > This does mean that you need to do a merge of the whole tree and not > > merges of federated build, classlib and jdktools but again I see > > this as an advantage not a drawback. > > > > It doesn't stop anyone checking out specific subtrees to work in as > > they do now but they'd need to change urls. > > > > It would be quite a painful change but personally I'd be in favour > > as it would be a one off change that gets rid of quite a lot of > > complexity[0]. > > > > Regards, > > Mark. > > > > [0] And I've just done the renaming of working_* directories which > > was a real nightmare due to all the switches but would have been > > much more simple without them.