[p4] perforce vs. subversion

[Sweeney, Tony]

quis custodiet ipsos custodes -- Juvenal VI, 347-8 

> -----Original Message-----
> From: perforce-user-bounces at perforce.com [mailto:perforce-user-
> bounces at perforce.com] On Behalf Of Sam Roberts
> Sent: 03 May 2006 17:20
> 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.
> 
> 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. '
> 

That just reports the change.  To make a fresh, empty one, use 'p4
change'.

> then use the numerical changelist number when I edit the file:
> 
>   % p4 edit -c 39474 rules.mk

This will add your rules.mk to the existing pending changelist, yes.

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

Uh, "don't do that then"?

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

P4 diff -f filename#have does what you want.

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

'P4 submit' didn't originally take any arguments at all.  I asked them
to add one, on the grounds I often found myself running 'p4 edit
filename; p4 submit filename', and it seemed like a fairly natural
usage.  Unfortunately, people ran with it and tried to pass multiple
file names, triggering a bug, which Perforce "fixed" by restricting the
number of arguments to one (although wildcards are still allowed).  In
my view it should take arbitrary files on the command line, same as p4
edit, etc.  As a workround, you can create a change using 'p4 change',
put just the files you want into it using 'p4 reopen -c <changeno>
files' (which doesn't have the single argument restriction imposed by
submit) and 'p4 submit -c <changeno>'.

> 
> 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.integrati
on
> .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?

P4 diff -se

I think there's a way to do it in the GUI as well.

> 
> 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
> 
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user