From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 09:05:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B014616A4CE; Mon, 30 Aug 2004 09:05:29 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D25C43D45; Mon, 30 Aug 2004 09:05:28 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i7U95PU5094708; Mon, 30 Aug 2004 10:05:25 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-current@freebsd.org, current@freebsd.org Date: Mon, 30 Aug 2004 10:05:58 +0100 User-Agent: KMail/1.6.2 References: <200408160104.03708.chris@behanna.org> <41325D89.5040806@freebsd.org> <20040829232346.GA95117@dragon.nuxi.com> In-Reply-To: <20040829232346.GA95117@dragon.nuxi.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408301005.58602.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on itchy.rabson.org X-Virus-Status: Clean cc: Tim Kientzle Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 09:05:29 -0000 On Monday 30 August 2004 00:23, David O'Brien wrote: > On Sun, Aug 29, 2004 at 03:49:45PM -0700, Tim Kientzle wrote: > > >Ask Perforce to port to 64-bit AMD64. That would allow them to > > > have a lot more memory for their in-memory operations. > > > > Another possibility would be to switch from Perforce > > to something like SVN. > > > > I'm not sure how it compares to Perforce, > > It is amazing the number of people that keep suggesting things like > this and yet don't compare the two things they suggest to know how > they really compare. For what the project uses Perforce for, SVN > would offer nothing. True. That doesn't mean that subversion isn't better than CVS though. > > > but > > SVN has much better branch and merge support > > than CVS does. > > Oh? SVN's own developers say "Currently, Subversion's merge support > is essentially the same as CVS's." Well it might be the same in a purely technical sense but after actually trying to use both for non-trivial repeated merges, I can say that subversion is a huge improvement over cvs given a small amount of care. The atomic transaction numbers of subversion make it possible to keep track of where your last merge ended. To do the same thing with cvs requires repeated whole-repository tagging which sucks. > > > It's also specifically designed > > for use over slow networks, which would be a real > > plus. > > SVN does nothing better than Perforce, yet removes the advantages of > CVS. SVN doesn't remember past merges, so its branching is still > embryonic compared to Perforce. Compared to CVS, SVN requires a > connection to the main repo, and uses a heavier-weight network > transport (requires Apache and HTTP-based WebDAV/DeltaV protocol). You don't have to use apache or webdav. The svnserve protocol works well and if your project is structured so that developers can have accounts on your repository machine its just about identical to using cvs with CVS_RSH=ssh from a sysadmin point of view. True, no-one has implemented anything like cvsup so that you can have a local read-only copy of the repository. I very much doubt that this would be hard to write - the atomic transactions make it trivial to work out how to bring a read-only slave repository up to date wrt. the master - essentially you get CTM-style deltas for free.