[p4] perforce vs. subversion

[Sam Roberts]

On Wed, May 03, 2006 at 08:25:44AM -0400, Jay Glanville wrote:
> 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.

Interesting list, thanks.

As a long-time cvs user, recent and happy svn user, and recent and quite
unhappy perforce user, I've a few questions if you have a moment. I
think I have not sucessfully absorbed how p4 expects to be used.

svn has the concept of "ignored" files, and the ability to tell you what
non-ignored files are in your working copy that have not been added. p4
does not.  This makes it very painful to search for new files and make
sure they have been added, we regularly have broken builds because files
got missed on submits.

In general, I find perforce extremely weak in reporting the state of the
working copy. Its attitude is basically "we know what your repository
looks like because you told us about everything you were going to do".
This is quite optimistic.  svn takes the approach of "use your tools to
modify your files, and we'll check the files status". p4 is
theoretically faster, but it is often wrong, and forces you to do
everything twice. First you call "p4 edit", then you edit the file. With
svn, you just edit the file. Etc.

I regularly run the following commands (wrapped into a p4stat script
with a nice output format) to determine the state of my working copy:
	'diff -se',    'Unopened and Changed'
	'diff -sd',    'Unopened and Deleted'
	'resolve -n',  'Unresolved'
	'sync -n',     'Unsynchronized'
	'diff -sa',    'Open and Changed'
	'diff -sr',    'Opened and Unchanged'
	'opened',      'Added'

As well, a number of our developers have written ad-hoc scripts to try
and find new files while accounting for build artifacts that should be
ignored.

This is so painful I suspect there is something about my workhabits that
just hasn't adjusted to p4 from cvs/svn.

> 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.

This seems to be a work-around for one of the things that most troubles
me, could you describe your workflow for doing this? I.e., to open
a file with a changelist, it appears I need to do:

  % p4 changelists -s pending -u sroberts
  Change 39474 on 2006/05/03 by sroberts at sroberts *pending* 'Changes not to be submitted. '

then use the numerical changelist number when I edit the file:

  % p4 edit -c 39474 rules.mk

Is this really the process? If so its another thing I would add to my p4
wrapper scripts, an "open but not to submit" command.


I used to change these conf files and not open them, but "p4 diff" won't
report differences on unopened files! Unless you use "p4 diff -f", but a
side effect of that is it doesn't diff against the base, it diffs
against the head in the repository, which can make it look like you have
removed lines when actually there is a new version in the repository.
Maddening.

Also, the "p4 submit" commmand (unlike svn) doesn't allow multiple
arguments. So if you have changes in src/ and doc/, but don't want to
submit changes in conf/, you have to do a "p4 submit ...", then manually
weed out the conf/ files. With svn, I would do "svn submit src doc".

So, I'd really like to know how you do this pending change list trick.

> 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.

We use Mantis, it isn't on the list of supported trackers for p4 and our
release team hasn't had the time to integrate it. We manually keep them
in sync. I absolutely agree on how useful it would be to have this
automated!

svn supports integation with bugtrackers, and Mantis has been integrated
sucessfully with svn:

  http://manual.mantisbt.org/manual.configuration.source.control.integration.php

> 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.)

No comment on the above, I've never needed it. I suspect you could do
this in svn, you would copy a specific set of files to a new branch.

svn also has simple commands for copy and rename. rename is a multi-step
command with p4.

> 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.

Not true about svn, you can choose *multiple* explicit files or
directories from the command line, which you can't with p4 submit.

How you describe svn is unfortunately how I usually use p4. Since I
can't select multiple files I submit ... and weed out the ones I don't
want to submit. :-(


> 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.)

What tool do you refer to?

All I've found is p4 diff, and I have to call it at least twice, once
with -sd, once with -se (it silently ignores all but the first "-s"
switch).

My overall impression of p4 as a user of only 6 months is that it may be
more powerful, at least I am continually assured it does things svn does
not do (and that I don't want to do), but the simple things I want to do
as a developer are harder with p4 and easier with svn. p4 seems to want
me to use its powerful but more complex mechanisms even when I want to
do simple things.


Cheers,
Sam