From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: new repo layout? Date: Mon, 04 Jun 2007 11:25:28 -0600 Message-ID: <1180977928.6221.144.camel@bling> References: <20070530214638.GA21589@fc.hp.com> <1180598644.29571.57.camel@localhost.localdomain> <1180627325.16734.26.camel@basalt> <1180628637.29571.84.camel@localhost.localdomain> <1180967986.6221.133.camel@bling> <1180973667.4041.18.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1180973667.4041.18.camel@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: Aron Griffis , xen-devel@lists.xensource.com, Hollis Blanchard List-Id: xen-devel@lists.xenproject.org Hi Ian, On Mon, 2007-06-04 at 17:14 +0100, Ian Campbell wrote: > > Hmm. > > xen-unstable will look at a URL derived from it's own parent to find the > Linux tree this means that for the ppc and ia64 trees it will currently > be looking on xenbits for /ext/linux-2.6.18-xen.hg for both archs, this > tree doesn't even exist and I don't think you'll want to share a Linux > tree. Agreed, synchronizing updates and pulls would be too much of a headache. > If we define $(XEN_LINUX_ARCH) as "" in the $(XEN_TARGET_ARCH)==x86* > case and -$(XEN_TARGET_ARCH) in != x86 case. Mixing that into > XEN_LINUX_HGREPO would yield /ext/linux-2.6.18-xen-ia64.hg etc. Does > that seem OK to you? But that would only need to be the case if the parent of the xen tree contained xenbits.xensource.com/ext in the path (or some other locally defined path if the parent is a local clone). If we're building xen-unstable.hg on ia64, it needs to pull linux-2.6.18-xen.hg just as it would on x86. This quickly starts to sound like rather complicated rules. > Another option would be to move the ia64 and ppc trees into separate > subdirectories of /ext/. I'm open to other alternatives. So far, this sounds like the best option. This way it would work just like the staging tree builds and would hopefully be less likely to get broken. We might also gain some flexibility in being able to create new repos in the subdirectory. Thanks, Alex -- Alex Williamson HP Open Source & Linux Org.