Date: Wed, 18 Aug 2004 17:00:55 +0100 From: Doug Rabson <dfr@nlsystems.com> To: Robert Watson <rwatson@freebsd.org> Cc: current@freebsd.org Subject: Re: Public Access to Perforce? Message-ID: <200408181700.55424.dfr@nlsystems.com> In-Reply-To: <Pine.NEB.3.96L.1040818115052.55952G-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040818115052.55952G-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 18 August 2004 16:51, Robert Watson wrote: > On Wed, 18 Aug 2004, Doug Rabson wrote: > > On Wednesday 18 August 2004 16:31, Robert Watson wrote: > > > A first test for any open > > > source replacement for CVS in the FreeBSD project is that it be > > > able to import our current history and workload efficiently. I > > > believe last time this was attempted with Subversion, the > > > importer ran at least a month before the person trying it gave up > > > :-). > > > > For what its worth, the latest cvs2svn converter is at least two > > orders of magnitude faster than when this test was run. I have a > > private CVS test repository which used to take several days to > > convert on a fairly slow machine. With the latest convertion script > > it only takes a few hours. > > Last I looked, my primary concerns with Subversion were: > > - Cost to import full FreeBSD history. > > - That it promised the multi-way branching and merging in a future > release, but did not yet have it. > > Do you know how things look with respect to the second issue? Branching is cheap and fast. Repeated merging is not explicitly handled by subversion but in using it for my own work, I've found that the transaction oriented nature of subversion makes repeated merging between branches quite easy (in comparison to being pretty near impossible in cvs). All I do is keep track of the transaction number of my last merge and use that as the start of the transaction range to merge next time around. The svk system (which layers on top of subversion) does support repeated merges as well as distributed repositories. The mechanism used to support merges (storing extra state in properties) could probably be used in subversion itself. It certainly won't be in subversion 1.1 but it doesn't seem unreasonable that it might be included in 1.2.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408181700.55424.dfr>