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.Received on Mon Aug 30 2004 - 07:05:29 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:09 UTC