[p4] perforce vs. subversion

[Jeff Jensen]

I think you are trying to drive a Ferrari like a Pinto.  ;-)

It sounds like you/your team needs a Perforce expert to explain how things
work and help the team adjust to different process and work habits.  I hope
you can find one locally.

I think one of the key things with the file and checkin issues I read about
on this thread is learning how to utilize Perforce multiple pending
changelists well.  This is the second thing I miss when not able to use
Perforce with a customer (the first is how long the SCM takes to determine
which files I need - Perforce is a second, the others are magnitudes longer,
and tens of minutes on the big projects I have been on).

Multiple pending changelists are extremely helpful for organizing work -
don't underestimate and under-use them!  :-)  At my current customer (which
I introduced, rolled out, and trained them on Perforce), using them is now a
"standard operating procedure", as their tech leads teach this process.  For
a given unit of work, developers typically create a new numbered pending
changelist.  When adding/editing a file, the user places the opened file in
the correct changelist.  This resolves the "why is that file checked out
again?", because the numbered pending changelist contains the checkin
comment already stating the goal of that unit of work.  This also prevents
accidental checkins of files that shouldn't go in yet.

This also works perfectly for the "I'm working on one assignment (e.g. bug
fix, new feature) and the boss stops by and says 'hey, please pause on that
and do this hot item'".  They especially help when you are multiple
interrupts deep!  Create multiple pending changelists - one or more for
each.  Even on the same assignment, multiple changelists organize what you
are doing for it.  Think small units of work submitted to provide easier
merging and ye ol' "back it out" if necessary.

Another common benefit covers what you described below: the files you
changed but don't want to checkin.  Create a numbered pending changelist
with a comment like "local customizations - don't submit".  This allows the
user to easily track (using the tool) exactly which files s/he changed, see
when any have changed in the depot ("needs resolve"), and won't accidentally
check them in.


So the above is an example, using multiple pending changelists, of what I
mean by learning the purpose of the features of the tool and using them to
your advantage, vs fighting the features because it doesn't work like CVS or
SVN.  Thankfully Perforce is not them.  While I like them too (I've used CVS
on & off for over 12 years and SVN for 2), neither has what Perforce has
(and contrarily, Perforce is not free!).  Perforce is not perfect, but far
more powerful and feature rich.  So far, every CVS/SVN fan I have worked
with eventually saw the light  :-).  It took many explanations,
conversations, and "show me"s, but the understanding and respect of the
Perforce approach did arrive and they became happy Perforce users.

Some more specifics are inline.
 

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Sam Roberts
> Sent: Wednesday, May 03, 2006 11:20 AM
> To: perforce-user at perforce.com
> Subject: Re: [p4] perforce vs. subversion
> 
> 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.

I think this too, based on the thread and your comments.


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

This is a symptom of not using multiple pending changelists correctly, and
always adding new files immediately.


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

Another symptom of not using the tool correctly.  One of the beauties of
pending changelists is they are an immediate snapshot of all that has
happened in the workspace.

I find exactly the opposite with SVN and CVS: it is a pain to get a concise
simple snapshot.  Screen after screen of goo rolls by from command output...


Also, while CVS doesn't require you to "checkout" the file, larger teams may
turn on the cvs edit/watch facility to have better understanding of the code
changing underneath them.  This is the CVS equivalent to p4 edit.


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

Ugh!  I think aliasing many p4 commands as cvs ones is a symptom of not
knowing how and why to use the tool for your benefit (or just simply
unwilling to learn a different solution; I've seen that type too!).  This is
a common-type issue when moving from one paradigm to another.

Also, as for predefined wrappers, there are CVS wrappers for p4 on the
Perforce related software page.


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

You are on to something... ;-)

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

This is not a workaround, but a wonderful feature that lets the user track
exactly which files are modified and in which manner (i.e. add, edit,
delete, branched).  Having a numbered pending changelist with a comment of
"local customization - do not submit" is very clear as to the intent!


Are you able to use P4V for some/more of your Perforce usage?  It (and
P4Win) enable drag and drop of files between changelists.  The command line
is far more powerful, but for the simple things like this, the GUI is easier
IMO.


Also, what is your IDE?  Does a Perforce plugin exist for it?

Most of the major IDEs have some type of Perforce plugin.  Often, the plugin
will automatically checkout the file when the user starts typing in the
file.  This is equivalent to the IDE doing a "cvs edit" for you.

My current customer uses Eclipse/WSAD/RAD, and the P4WSAD plugin does this
nicely.  It can also automatically add a new file to a pending changelist
(prompted) when the user creates one through the IDE, and when it discovers
one via a background thread.  This feature is configurable.


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

As above, use a separate pending changelist.  This allows the user to easily
track (using the tool) exactly which files s/he changed, see when any have
changed in the depot ("needs resolve"), and won't accidentally check them
in.

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

Perforce submits changelists, not files.  This is a key mind shift from CVS.
A changelist is a unit of work.  A file could represent the whole unit of
work, but typically not; typically multiple files represent a given change
(complete or just a step in the implementation).  So think in terms of
changelists - organize your work/files into them.  While SVN, I haven't seen
users utilize changelists like they should for atomic checkins of units of
work - still used as a file based checkin system.


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

Continually having to run a series of p4 commands to see what you've changed
is another symptom of not using the tool correctly.  You say it above:
Perforce requires you to tell it what you are doing (add a file, edit a
file, etc.).

CVS/SVN also require an "add" command, so that is the same.  The main
difference is the "edit" command.  It is the same if using CVS edit, but
obviously you are not used to using that feature.


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

I'm hoping we can help you work through the troubled spots so it becomes a
great tool for you (and you like it too!).

HTH!