Public Access to Perforce?
dfr at nlsystems.com
Mon Aug 30 02:05:29 PDT 2004
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.
More information about the freebsd-current