[p4] perforce vs. subversion

[Arnt Gulbrandsen]

Sam Roberts writes:
> ...
> 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 beg to differ. p4 edit isn't equivalent to the editing of the file. 
It's equivalent in time and attention to any single editor command. For 
example, in emacs, c-x p e switches from looking at a file to editing 
it, and c-c c-q reindents the current function.

p4 edit really is a minuscule command - it takes no input and usually 
produces no output. There's no inherent reason why invoking it should 
require noticeable time and attention.

When p4 edit produces output, it's extremely valuable. It tells you 
something about the file that often surprises you, usually that someone 
else is also working on the file or that you're not on the latest 
revision. If you're the kind of person who likes compiling with 
warnings enabled, I think you'll learn to appreciate these warnings, 
too.

I expect you have some kind of editor macro or shell script which 
creates a new, empty file, adds include guards and whatever verbiage 
your coding standards call for. My emacs file-find-hook inserts 
'#include "foo.h"' whenever I create a new foo.cpp, for example. Add a 
call to 'p4 add' there, and you can forget most about your 
after-the-fact housecleaning. AND you let lazy colleagues use 'p4 
opened -a ...' as a quick way to see who else is working on code in a 
directory. AND you get a warning before you waste any time developing 
foo.cpp if a colleague also started on the same task without telling 
anyone.

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

IMO, there's a different world-view. In perforce, the depot comes first 
and a client view comes second. The depot is holy. In cvs/svn, it's the 
other way around. The depot is the clients' servant.

Arnt