Perforce comparison

Has anyone seen this document Perforce has which compares it
to Subversion?

http://
www.perforce.com/perforce/reviews.html

I know a lot of you use Perforce, so I'd be curious what you
think.

-- 
Thanks

Mark Phippard
http://markphip.blogspo
t.com/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On Wed, 2007-09-26 at 17:26 -0700, Mark Phippard wrote:
> Has anyone seen this document Perforce has which
compares it to Subversion?
> 
> http://
www.perforce.com/perforce/reviews.html
> 
> I know a lot of you use Perforce, so I'd be curious
what you think.

"Subversion doesn't offer a method to resolve different
line-ending and
carriage-return requirements for files being transferred
between Windows
and Unix."  Fascinating.

I think their "distributed development" row (which
is actually just
about slow network links) kind of inverts the story.  My
muddled
understanding is that Perforce is much more dependent upon a
fast
network link because you typically NFS-mount your working
copy.  So
yeah, they have a proxy caching server because they *need*
one, and
Subversion doesn't because there's no real need.  With
Subversion, you
can work over a medium-latency network link without setting
up any kind
of proxy and not feel much pain.


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 9/26/07, Greg Hudson <ghudsonmit.edu> wrote:

> I think their "distributed development" row
(which is actually just
> about slow network links) kind of inverts the story. 
My muddled
> understanding is that Perforce is much more dependent
upon a fast
> network link because you typically NFS-mount your
working copy.

Actually it's more the fact that you have to contact the
server for
almost all actions, you don't actually NFS mount your
working copy in
p4 (perhaps you're thinking of clearcase?).

-garrett

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 9/26/07, Mark Phippard <markphipgmail.com> wrote:
> Has anyone seen this document Perforce has which
compares it to Subversion?
> http://
www.perforce.com/perforce/reviews.html

I've seen it, but I don't generally trust such evaluations,
from
parties with a vested interest in the outcome. Especially
when that
vested interest is money. ;)

> I know a lot of you use Perforce, so I'd be curious
what you think.

Right now my shop uses Perforce for the code depot, and
Subversion for
everything else. In my opinion, if your repository has a lot
of large
binaries, and you have several offsite contributors, or not
everybody
is on the same fast LAN, Subversion is always faster. In
most other
cases, Perforce is faster, with a few caveats.

Here's my reaction to the main points in the document...

Branching and Merging:
    They are right about Subversion 1.3 lacking good
internal merge
tracking, but they clearly ignore the python svnmerge
scripts, and 1.5
will definitely close this gap. I have to admit, their
Revision Graph
GUI is quite nice. The process of creating branches and
working copies
in Perforce seems a lot more convoluted to me, than
equivalent svn
operations. I do like their "label" features.

Platform dependencies:
    Boy are they wrong here! Using autoprops with native
line-endings
has always been much more reliable on Subversion.
    I had a situation at my last job, where we changed P4
servers from
a Windows 2K3 box to a Linux box, and back, and all the line
endings
in every text file in the depot had their line endings
doubled during
each transition. This was after running convoluted
line-ending
conversion scripts on the depot, as recommended by Perforce
support at
the time. We even wrote a script to eliminate these double
line-endings on a working copy, and had a big commit of
nothing but
line-ending changes. All the developers were on the same
platform --
this was purely a server data format issue. What a joke!
    I started with a couple of small Subversion repositories
on a
WinXP box at my current company, and moved to a Linux server
when we
got the hardware budget. We NEVER had ANY line-ending
issues. The
dump/load process between Subversion servers and versions is
MUCH
better than Perforce.

Distributed Development:
    They are way off here too! They obviously ignore the
existence of
SVK, and the fact that SVN working copies are inherently
offline.
P4Proxy is a joke. It doesn't even have support for secure
transfers
-- it depends on SSH and VPN tunnels for that. P4Proxy is a
glorified
cache, and an obvious kludge, to get around the fact that
their
clients require a constant server connection to do anything
useful.

Scalability and Performance:
    While this is debatable, I find Perforce's memory
requirements
onerous. They fail to describe the massive servers required
to host
3000+ user environments -- each user inherently adds to the
P4 server
memory requirements. Partly due to their licensing system,
it is
nearly impossible to set up load-balanced clusters of
Perforce
servers. This seems to be trivial when using clustered
filesystems
with Subversion, and svnsync developments may make this
trivial for
servers with discreet filesystems in the future. SVK and
Pushmi
currently create lots of ways to make Subversion scalability
and
performance unbeatable.

Defect Tracking:
    I don't  personally see much value to integrating defect
tracking
with source control. I like the Trac method, of being able
to
reference repository objects from the ticket description. I
think
going the other way -- allowing commits to automatically
resolve
tickets -- leads to bad developer habits. If closing tickets
based on
commits is ever allowed, it should be done exclusively
through
continuous integration testing methods. That's all
debatable. I think
commit hooks are a better place for defect tracking
integration in
general.

Integration with related tools:
    Boy do they gloss over the tools "available from
open source
community" here! They fail to mention that Perforce has
almost no
third party support for tool integration, despite their API.
They
create almost all their integration tools in-house, and
leave very
little incentive for third party development in this area.
Subversion
has them beat by far, here.

Support:
    Let's see, how do you compare a single monopolistic
source of
support, for proprietary software -- to a wide open market
of support
options, for open software that can be endlessly customized?
You say
that the free-market support options are "available at
additional
cost", and gloss over the fact that you HAVE to pay for
the
monopolistic support BEFORE you can really use the
proprietary
software. This is just silly.

    The rest of the document just reads like an
advertisement to me.
The "meat" is usually the operation time
comparison charts, but they
are obviously biased here. Commit, update, and status
commands for
text files are usually much faster on Perforce, if you have
a reliable
connection to the server, and said server has plenty of
memory. That
is because most of their client status information is stored
on the
server, and is usually cached in server memory. Binary
updates can be
faster on a fast network connection, but Subversion binary
diff
network transfers are usually faster on updates that don't
involve too
many sub-folders.
    Subversion really shoots itself in the foot here, by
storing
client status information in each and every folder. This is
something
CVS really got wrong. Recursive disk IO is usually going to
be much
slower than any central database IO. If the working copy
were kept in
a single local store, like SVK or Mercurial, speed
comparisons would
become trivial, and Subversion would almost always win.
Right now, any
P4 vs. SVN speed comparisons are really just comparing
specific client
recursive disk IO to client-server network IO. That makes it
pretty
easy to set up scenarios where one will always beat the
other. I'm
sure they tested on a client with a slow disk and fast LAN,
and with a
dedicated server connection. Unfortunately, that's a pretty
common
scenario in commercial development environments.
    All you need to do is set up a client connected to the
server by a
slow and unreliable modem, with a really fast (10K+ RPM)
local disk,
and use a filesystem with very efficient metadata and
small-file
storage and caching (i.e. ReiserFS3+). Fill up the repo with
lots of
large binaries that diff well. In this scenario, Subversion
will
usually win. ;)

 Jred

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 9/26/07, Jared Hardy <jaredhardygmail.com> wrote:
> On 9/26/07, Mark Phippard <markphipgmail.com> wrote:
> > Has anyone seen this document Perforce has which
compares it to Subversion?
> > http://
www.perforce.com/perforce/reviews.html
>
> I've seen it, but I don't generally trust such
evaluations, from
> parties with a vested interest in the outcome.
Especially when that
> vested interest is money. ;)
>
> > I know a lot of you use Perforce, so I'd be
curious what you think.
>
> Right now my shop uses Perforce for the code depot, and
Subversion for
> everything else. In my opinion, if your repository has
a lot of large
> binaries, and you have several offsite contributors, or
not everybody
> is on the same fast LAN, Subversion is always faster.
In most other
> cases, Perforce is faster, with a few caveats.
>
> Here's my reaction to the main points in the
document...

Thanks for taking the time to write such a detailed
response.  There
is a lot of good information and it would be hard for anyone
to argue
that it is not fair and unbiased.

There seems to be a lot of serious momentum towards unifying
the WC
metadata information in the 1.6 or 1.7 time frame.  It is
exciting to
think it could deliver those kind of speed improvements.

-- 
Thanks

Mark Phippard
http://markphip.blogspo
t.com/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On Wed, 26 Sep 2007, Garrett Rooney wrote:

> On 9/26/07, Greg Hudson <ghudsonmit.edu> wrote:
> 
> > I think their "distributed development"
row (which is actually just
> > about slow network links) kind of inverts the
story.  My muddled
> > understanding is that Perforce is much more
dependent upon a fast
> > network link because you typically NFS-mount your
working copy.
> 
> Actually it's more the fact that you have to contact
the server for
> almost all actions, you don't actually NFS mount your
working copy in
> p4 (perhaps you're thinking of clearcase?).

...because all p4 WC meta data is stored server-side; only
the equivalent
of Subversion's text-base is stored client-side.
-- 

Daniel Rall

On 9/27/07, Daniel L. Rall <dlrcollab.net> wrote:
> On Wed, 26 Sep 2007, Garrett Rooney wrote:
>
> > On 9/26/07, Greg Hudson <ghudsonmit.edu> wrote:
> >
> > > I think their "distributed
development" row (which is actually just
> > > about slow network links) kind of inverts the
story.  My muddled
> > > understanding is that Perforce is much more
dependent upon a fast
> > > network link because you typically NFS-mount
your working copy.
> >
> > Actually it's more the fact that you have to
contact the server for
> > almost all actions, you don't actually NFS mount
your working copy in
> > p4 (perhaps you're thinking of clearcase?).
>
> ...because all p4 WC meta data is stored server-side;
only the equivalent
> of Subversion's text-base is stored client-side.

Yes, exactly.  Also note that this is one of p4's big
scaling issues,
as the amount of data the server needs easy access to (i.e.
needs to
be cached in RAM to be usefully fast) is proportional to the
combined
size of all active working copies (they call them
"client views") at
any given time.  Once you have more than can comfortably fit
in RAM on
the server you're screwed.

-garrett

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 9/26/07, Mark Phippard <markphipgmail.com> wrote:
> There is a lot of good information and it would be hard
for anyone to argue
> that it is not fair and unbiased.

Oh I'm quite biased, but I like to think it's based on
experience and
understanding. ;) That, and nobody can pay me enough to lie
or shut
up.

> There seems to be a lot of serious momentum towards
unifying the WC
> metadata information in the 1.6 or 1.7 time frame.  It
is exciting to
> think it could deliver those kind of speed
improvements.

You could see those speed improvements now -- just set up
SVK to
mirror on a large repo, make a local branch and WC, and
compare update
or status execution times. It goes even faster when you keep
the .svk
cache on a separate disk from the WC. That's how I'm holding
out on
the client side, until some SVK "distributed"
features start hitting
mainline Subversion. Most of what SVK is doing there is just
a
creative use of existing Subversion repository code, on the
client
side.

    One feature I forgot to mention, that has come up in
previous WC
refactoring threads, was a "mark for edit"
command. This is similar to
the Perforce "checkout" command -- their
"update and get lock"
equivalent, since all Perforce WC files implicitly require
locks. This
would allow clients to bypass recursive disk IO status
comparisons,
when listing modified files. SVN cleanup commands could be
re-purposed, to update status cache more thoroughly, when
necessary.
Perforce commit performance benefits a great deal by having
a
"checkout for edit" requirement; but that
requirement can really hurt
when you have an editor that overwrites files despite
read-only bits,
sometimes without notifying you. For now, I'm trying to
write my own
"mark for edit" wrapper scripts, in part using the
svn "--targets
edit-list.txt" options, which should eventually extend
to all
multi-file svn commands. These scripts might also use any
changelists
features provided by future versions.

 Jred

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On Sun, 2007-09-30 at 20:35 -0700, Jared Hardy wrote:
>     One feature I forgot to mention, that has come up
in previous WC
> refactoring threads, was a "mark for edit"
command. This is similar to
> the Perforce "checkout" command -- their
"update and get lock"
> equivalent, since all Perforce WC files implicitly
require locks. This
> would allow clients to bypass recursive disk IO status
comparisons,
> when listing modified files.

Yeah... I think the general consensus is (or would be, if
people thought
about it) that "mark for edit" would produce
wonderful speed for
recursive WC operations, and wouldn't be a hassle when
you're using an
editor with a well-integrated svn mode, but would be a
horrible pain in
the butt when you aren't.

I think if there were a WC design which made "require
mark for edit and
get better performance" a checkout option in some
beautiful elegant
fashion without unduly complicating the code base or UI,
that would be
the best of both worlds.  But that feels a bit blue-sky.


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org