[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion vs. Perforce

From: David Waite <mass_at_akuma.org>
Date: 2003-09-10 03:07:31 CEST

Garrett Rooney wrote:

> Guido van Rossum wrote:
>> So now my question: what does Subversion has that compares to
>> Perforce's GUI? I've used Perforce in the past, but only the command
>> line interface so I don't know what its GUI does, but I imagine it's a
>> nice piece of work, especially if you're on Windows (the only platform
>> we care about for non-engineers). I liked the Perforce command line
>> interface fine, but I'd prefer to continue to work with Subversion if
>> only to support open source, and to save the $750/seat that Perforce
>> will cost, and perhaps because I like Subversion's model for
>> per-repository revisions and its approach to branching better. But
>> for that money I can't put up much of a fight -- I want to save energy
>> for real work and for defending Python's role in the project if it
>> becomes under threat.
> You know, of all the features of Perforce, I would not have expected
> "GUI client" to be the one that would be beating us out. Now their
> intelligent merging support, that would be a more convincing argument...

This is mostly opinion and personal experience, but...

This was actually the argument which switched us from CVS to Perforce at
my last company - that non-developers could not figure out the wincvs
GUI (I kept trying to explain to them that this was because wincvs was a
horrible, horrible gui, and using the command-line would actually be a
lot more intuitive for them ;-))

The SCC integration in most applications is just horrible, to the point
where we were not allowed to use them (too many incidents of data loss
on updates and commits). We had many problems where the lack of local
file tracking information ('CVS' or '.svn' directories) caused major
headaches, especially when people were pair-programming - they would
switch users without realizing it, hitting the same view with a
different perforce 'client' which thought there were different local
file versions. The next commit or update would cause perforce to get
confused and remove local and committed changes. Finally, the whole
system was so incredibly slow, when I was heavily using the repository I
sometimes felt over an hour of my day was just running perforce
commands. If I never see another 'running man' cursor I will die a
reasonably happy man :-)

There is also wire security to perforce whatsoever (password
authentication is clear text for most clients on both ends, traffic is
unencrypted). The problems I had with perforce were actually what
convinced me to start using and working on subversion; I wanted to make
sure I could sell an alternative to perforce in the future, and to
hopefully not have to use it again. It wound up poorly meeting the needs
of the non-engineers, and the engineers for the most part would have
been much happier and more productive even with CVS.

That said, the two largest selling points for Perforce would probably be
the increased authorization support and the file locking support.
Ultimately the decision on which tool to use came from the SCM, and they
liked being able to control the branching/tagging policy. File locking
is very important for files which do not have clear merging tools, or
when the inconvenience of being blocked by a lock outweighs the
inconvenience of possibly having to perform a merge. Both of these are
areas subversion will improve in the future.

Another possible selling point is the perforce windows GUI being able to
display and navigate the server repositories, and display some useful
user repository "View" information, such as out-of-date files and who
has the current lock on a certain file. This however was way too slow
(even in our small group) to be truely useful except to resolve locking
conflicts. As far as server-side navigation, I preferred viewcvs over p4web.

I understand the merge tracking is more sophisticated with perforce, but
AFAIK it comes with no merge tools. I had difficulty figuring out how to
actually perform the merge resolution with perforce - I prefer the
subversion model for its simplicity.

Not to mention the python support is more integrated with subversion... ;-)

If I was in this situation, I might try to get subversion evaluated,
probably under the argument that X, Y, and Z are the only features not
currently in subversion that are in perforce, especially if I could show
there is concensus that the features are valuable and will be added (at
some point). Saying that third parties are writing tools that should
allow conversion between the two systems might also make it perceived as
a lower risk. If it is close, I'd see if they were willing to try a
limited evaluation of the TortoiseSVN with the non-development users
(assuming they are also windows platform users). If worse comes to
worse, there is always the possibility of switching tools in the future
if it becomes clear that a future version of subversion meets your needs
-David Waite

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 10 03:08:33 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.