[p4] perforce vs. subversion

Wed May 3 08:56:30 PDT 2006

Locking:
> A corollary to the above ... As SVN has no concept of "open for edit",
it's very
> hard for SVN to lock a file so that only one person can modify it at a
time. 
> This is absolutely necessary if you're working on a binary document
(Word, image,
> etc) as you can't merge binaries.  When I stopped investigating SVN,
there were a
> few proposals on how to setup locking, so there might be a solution in
place for
> this SVN issue.  P4 has regular locking and exclusive locking.

Subversion does do file locking since version 1.2. You use a Subversion
attribute to say that a file must be locked before being submitted for
changes. You can then use a Subversion hook to make sure that the
attribute is set on binary type files before new changes are submitted.

BTW, the reason you have to "p4 edit" a file in Perforce is to put it
into a changelist. Subversion has no "changelists", so there is no need
to mark a file for editing.

To me, the biggest problem of Subversion is the absolute lack of merge
tracking. You have to manually track what versions of a file have
already been merged when you do a merge. Not much fun.

Subversion really doesn't differentiate a branch from a tag (what
Subversion call labels) which is what Bruce was referring to in his
post. That's why you cannot say a tag is version X of all these files,
but version Y of this one file. It's as if you label files via the "p4
integrate" command. It really limits your flexibility in this respect.
Even worse, there is no built in mechanism to protect a tag from being
changed. And, even when a tag is changed, detecting this is extremely
difficult. We used a Subversion hook to allow "tags" to be created, but
not edited.

Subversion does "track" where a file comes from when you do a "svn cp"
(which is how you do branches), but you have to do a long list of the
"svn log" file to find this information. And, once you find this
information, you then have to do another "svn log" on the other branch
to find earlier information. Not very convenient.

Also in Subversion, you cannot delete versions of a file. That means if
you're storing binary code in your source archive, you cannot delete
obsolete versions. Plus, if a user accidentally added a particular
version of a file, it will be there forever. We have had issues with
users accidentally checking in passwords or adding files that contained
information that shouldn't be in the source archive.

Advantages that Subversion has over Perforce:

* File attributes. Perforce simply doesn't have them. It is nice to be
able to store information about a file and its revision that is not in
the file itself.
* No need for the "edit". (Whether this is a feature is debatable since
this means Subversion doesn't really have changelists. However, most
developers like this one fact, so I'll count it as a feature).
* You can configure everything via https and http.
* Price (can't beat free).
* No Client setups (Again, debatable since client views add a lot of
flexibility, but most developers find setting up a Perforce client view
confusing, so I'll count this as a feature).

Perforce advantages:

* Support. You can always count on Perforce to know what is going on.
* Speed. Perforce is much faster than Subversion.
* Changelists (Developers hate the "p4 edit", but they find multiple
changelists very helpful)
* True labeling
* Built in permissioning (Subversion relies on hook scripts or
http/https security).
* Merge tracking.
* Available GUI. Subversion doesn't have a GUI. You can use TortoiseSVN
or an Eclipse plug-in, but neither is run by the Subversion development
team.

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Jay Glanville
Sent: Wednesday, May 03, 2006 8:26 AM
To: brucemc119 at yahoo.com; perforce-user at perforce.com
Subject: Re: [p4] perforce vs. subversion

I did a comparison between Perforce and Subversion about 18 to 24 months
ago.  So, keep in mind that all my comments are based on based on the
products at that time.

Pending Change Lists:
In subversion, there is no 'pending change list' as there is in P4.  In
SVN, a change list is created for you at submission time.  For anyone
who has used P4, the ability to have multiple pending change lists is
great -- in many cases, it's necessary.  

For example, in my product, there are many configuration files that
dictate how the product behaves.  These configuration files need to be
modified in my development environment.  So, I've opened the files for
editing and placed them into a pending change list that I will never
submit.  This allows me to separate my configuration changes from my
code changes.  With SVN, every time I execute the submit command, I
would then have to manually exclude all the changes that weren't part of
the submit.  This is very error prone.

Defect Tracking Integration:
At the time of my investigation, there was no integration between SVN
and any defect tracking system.  With P4, there's P4DTI (the perforce
defect tracking integration package).  With P4DTI, I can integrate any
defect/bug/issue tracker with P4.  When I submit a change list, I
associate it with an issue, and P4DTI updates the issue with the change
list information, possibly even closing the bug/issue for me.  We use
P4DTI to integrate P4 with Bugzilla - very clean.  Other integrations
already exist
(http://perforce.com/perforce/products/defecttracking_table.html), or
you could use P4DTI to make your own.

Your code repository tracks what you did.  Your Defect tracker tracks
what's wrong with your product.  Integrating the two allows you to track
what fixed your problems.  It also allows you to more effectively state
why you're submitting the changes you're submitting.

Labeling:
If I remember correctly, SVN doesn't support labels, all they have is
'submission number mnemonics'.  By that, I mean that a label simply maps
to a submission number.  We've found that that isn't always enough.  For
example, we may want a label that doesn't pick a point in time or point
in the submission series, but is a cherry-picking of file versions.  By
basing your labels on submission numbers, you don't have the ability to
flexibly define your label.  (a submission number in SVN is analogous to
a change list number in p4.)

Branch Tracking:
I don't believe that SVN tracking where a file was branched from.  I
could be wrong on that.

Cost:
SVN is free.  In a value per dollar ratio, as you can't divide by zero,
this is an excellent reason to investigate SVN.  In our installation,
not everybody gets a P4 user id as these cost money.

P4 Edit vs SVN Modify:
In P4, the server likes to know if you're going to modify a file.  Thus,
you "open for edit" the file before modification (or "open for delete"
or "open for add").  In SVN, you simply modify the file.  In P4, you
submit all the files that are "open for XXXXX" (that are in a pending
change list).  In SVN, you submit all the files that are modified.

Both systems have their pros and cons.  In P4, if you "dirtied" a file
(ie: you modified it without telling the server), then it won't be
submitted until you tell the server about it's change.  (There are tools
in the P4 toolset that help you find dirty files.)  In SVN, as it needs
to "search for modifications", a submission can be a time-consuming task
if you have a large development tree.

Locking:
A corollary to the above ... As SVN has no concept of "open for edit",
it's very hard for SVN to lock a file so that only one person can modify
it at a time.  This is absolutely necessary if you're working on a
binary document (Word, image, etc) as you can't merge binaries.  When I
stopped investigating SVN, there were a few proposals on how to setup
locking, so there might be a solution in place for this SVN issue.  P4
has regular locking and exclusive locking.

Those are some of the things off the top of my head.  Again, everything
is based on the evaluation I did approximately 24 months ago.  I think
it was SVN version 1.0.  As 1.3 is now available, probably a lot has
changed.

JDG

> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of 
> brucemc119 at yahoo.com
> Sent: Wednesday, May 03, 2006 12:15 AM
> To: perforce-user at perforce.com
> Subject: [p4] perforce vs. subversion
> 
> I was wondering if anyone has experience with both Perforce and 
> Subversion and if you could tell me why you prefer one over the other.
> Thanks in advance,
> Bruce
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com 
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> 

_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user