From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22423 invoked by alias); 11 Apr 2007 10:22:50 -0000 Received: (qmail 22407 invoked by uid 22791); 11 Apr 2007 10:22:49 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-04.spheriq.net (HELO lon-del-04.spheriq.net) (195.46.50.101) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Apr 2007 11:22:37 +0100 Received: from lon-out-03.spheriq.net ([195.46.50.131]) by lon-del-04.spheriq.net with ESMTP id l3BAMXCW025429 for ; Wed, 11 Apr 2007 10:22:33 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-03.spheriq.net with ESMTP id l3BAMUPL015145 for ; Wed, 11 Apr 2007 10:22:30 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id l3BAMTBw016712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Apr 2007 10:22:30 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3EFE4DA42 for ; Wed, 11 Apr 2007 10:22:25 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 0529B47437 for ; Wed, 11 Apr 2007 10:22:24 +0000 (GMT) Received: from [164.129.15.13] (bri1043.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.7.5a-GA) with ESMTP id CIR84082 (AUTH stubbsa); Wed, 11 Apr 2007 11:22:23 +0100 (BST) Message-ID: <461CB6DF.7050509@st.com> Date: Wed, 11 Apr 2007 10:22:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: binutils@sourceware.org Subject: Re: SVN for src (was Re: Binutils 2.18 prep) References: <46025531.90105@st.com> <20070322150018.GA4566@caradoc.them.org> <20070322152751.GA5538@caradoc.them.org> <4602A611.6060907@st.com> <20070326145736.GB23900@caradoc.them.org> <4607F1D1.8070200@st.com> <20070410172524.GA18853@caradoc.them.org> In-Reply-To: <20070410172524.GA18853@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2007-04/txt/msg00114.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Mar 26, 2007 at 05:16:17PM +0100, Andrew STUBBS wrote: >> All in all, I believe that, even before subversion introduces proper support >> for something module-like, it is possible to switch to subversion, provided >> that users are prepared to be disciplined in their use of checkout and update. >> There will be no need to modify the structure of the repository (so people who >> checkout the whole world still can), and when svn modules are implemented, >> there will be no painful transition (of our doing). > > Anyway, let's wait. Jim Blandy pointed out to me that most of what we > need will be in Subversion 1.5 ("sparse directories"). It may be > awkward, especially for gdb/testsuite/gdb.gdbtk, but we'll work > something out. I had not heard of sparse directories, but then I don't follow SVN development. I'm not sure where the proper documentation of these features might be, but I found this: http://svn.collab.net/viewvc/svn/trunk/notes/sparse-directories.txt?view=markup It would appear that the new feature is exactly what we were discussing, except with the update/switch issues resolved. We would still need a checkout script to implement the `modules', but it would not be necessary to use it for switch or update. Indeed it would also appear to be no more powerful than the accidental-feature abuse we were talking about - i.e. you can choose your directories, but you can't choose your files. I do not see a big issue with gdb.gdbtk, or indeed the various bits of include that are not distributed with some projects. Care would have to be taken that updates don't ignore new directories, but that's just a question of ensuring that each directory has the proper depth parameter set. I would suggest now that the real problem is how to convert CVS to SVN. I haven't even got a clue how that could be done. The GCC project managed it, but I imagine that it will take a CVS expert some time to get that mammoth process completed. Andrew