[p4] perforce vs. subversion
Jay Glanville
Jay.Glanville at naturalconvergence.com
Wed May 3 05:25:44 PDT 2006
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
>
More information about the perforce-user
mailing list