[p4] perforce vs. subversion

[Chuck Karish]

On 5/3/06, Sam Roberts <sroberts at bycast.com> wrote:
> 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.

svn NEEDS the concept of "ignored" files because it writes junk
into your client workspace.  To me, this is not an attractive feature.

Perforce doesn't have lots of features to manage the state of your
client workspace because it makes a more complete separation
than svn or cvs does between files that it maintains and files that
it expects you to maintain.  It's easy to use Perforce to find new files.
My way:

#! /bin/bash

( find "$@" -type f | p4 -x - files > /dev/null ) 2>&1 |
  sed 's/ - no such file(s).//; s/^\.\///'

Add your own file filter to the sed script as you see fit.

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

This is a matter of using cvs/svn habits where they're not appropriate.
Perforce users get used to informing Perforce when they're changing
something.

>         'resolve -n',  'Unresolved'
>         'sync -n',     'Unsynchronized'

Needed no matter what SCM system you use.  Many users would
routinely run these commands without the '-n' because working at the
head revision is what makes it practical for them to collaborate with
their teammates.

>         'diff -sa',    'Open and Changed'
>         'diff -sr',    'Opened and Unchanged'
>         'opened',      'Added'

I usually get the client state information that interests me by typing
'p4 opened'.

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

Your build system is broken.  It stores state information where it can
easily be corrupted by the user.  Again, the wrapper script to find
unmanaged files is simple and easy to extend to meet your needs.

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

Or you could just leave such files in your default changelist.

> I used to change these conf files and not open them, but "p4 diff" won't
> report differences on unopened files!

Fix the configuration system to allow for alternate configurations for
development and QA.  Don't blame the source control system for not
helping you create uncontrolled hacks to work around a broken development
system.

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

If you're not working in a code base with a lot of branches you're not using
the feature that makes Perforce much more valuable to some of us: proper
tracking of pending integrations.

--
Chuck Karish   karish at well.com   (415) 317-0182