Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 41860 invoked by uid 500); 27 Feb 2003 13:06:21 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 41840 invoked from network); 27 Feb 2003 13:06:21 -0000 Received: from fo1.kc.aoindustries.com (209.15.201.17) by daedalus.apache.org with SMTP; 27 Feb 2003 13:06:21 -0000 Received: from apache.org ([66.208.12.130]) (authenticated) by fo1.kc.aoindustries.com (8.11.6/8.11.6) with ESMTP id h1RD6LX26452 for ; Thu, 27 Feb 2003 07:06:21 -0600 Message-ID: <3E5E0D4E.8020509@apache.org> Date: Thu, 27 Feb 2003 08:06:22 -0500 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [proposal] Pruning up the CVS tree for real References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Pier Fumagalli wrote: > On 26/2/03 21:22, "Stefano Mazzocchi" wrote: > > Yes... A few. Pruning a tree by hand is a _very_ bad idea, IMVHO, because > it'll destroy all history of the project, and in our case, as we're using > branches, not only of the 2.1 tree, but of the 2.0 as well. Maybe so, but what about getting rid of JARs for real? Esp. ones that we may have found were incompatible with distributing them at apache? > But having managed CVS installs for the past 4 years, now, I kinda see the > point, the more you add stuff into history, the heavier the repository gets. What about storing a log dump somewhere? I mean, there comes a time where history is no longer useful. Then again, according to murphy's law as soon as you get rid of something you will then need it. > > Subversion _will_ solve this issue, that's for sure, so my suggestion would > be to move over onto that system, but there are IMHO, still issues with the > availability of non-command line clients. I would wait to start using it > until doesn't start working properly and it > gets more widely deployed (I'm watching that space because we want to use it > at VNU). I am not afraid of the command line, but there were issues with the release of the Windows client the last time I messed with it. When run on XP, it would fail miserably (core dump or something, can't quite remember). The information on the server was OK, but sometimes I had to make a commit more than once. I would like to see SubVersion improve a bit before making everyone switch. The client reliability issue is what has me gun shy about it. (No issues with the server that I can tell).