[p4] P4 Submit
Jeff A. Bowles
jab at piccoloeng.com
Thu Sep 13 13:21:48 PDT 2001
At 12:31 PM 9/13/2001 -0700, you wrote:
>Oh please Simon. If I'm paying 600 bucks a seat, I think I'm entitled to at
>least a little griping. Please enlighten me why the user should do the
>heavy lifting of telling Perforce what files he is editing when there is a
>perfectly capable CPU of doing that for him...
Okay, you asked.
Perforce is, first and foremost, a FAST source management
system. Cruft that gets in the way of performance is not
included in the default configuation and, in some cases, not
Example: data is not compressed between client and server,
because that takes CPU cycles. You can enable this using
"p4 client" but it's not enabled by default.
Example: the model for editing files within perforce is that
you tell it the files you're editing. This makes "p4 diff" run
much faster (it doesn't have to compare against every file
you have, only the ones you've checked out) and "p4 submit"
is faster, for the same reason. Moreover, you can immediately
know if someone else is editing the file.
There are certain things that Perforce does better than
any: its branch model/mechanism is remarkably good,
although occasionally people will complain that it's not
as sophisticated as ClearCase at producing "ancestors"
of files that are being merged. (Why? Because, I suspect,
the most-often-needed revision for ancestor relationships
is the revision immediately prior to the one you're merging
content from. So it asks you to explicitly spell out ancestor
relationships if that's not the case, to save substantial
time and complexity on the server end.)
Sometimes, you have to provide more than just simple
and clean interfaces. (Unix provided the cleanest I/O
interfaces imaginable for dealing with files and with
hardware, but ultimately, ended up needing to convolute
that model a bit to make it perform for database and
networking needs.) However, the model underlying
Perforce is to make things simple and clean, getting
the speed from the simplicity (and very smart
implementation of certain algorithms).
The things you asked for are things that you can write
front-end wrappers for and, as someone pointed out
on this list, someone already has. It's called "c4".
However, the things you're asking for are also things
that aren't Perforce primitives because they either
have a high cost (not to develop or implement, but
to the user) or they're just stupid.
There, I said it. You REALLY want people to check
out all files just because they're too lazy to write an
editor macro to run "p4 edit" when they want to modify
a file? You'd trade away the ability to know who is
CURRENTLY working on something in exchange for
a lazy developer mindset?
I turn red when people tell me to "RTFM" because I
think it's patronizing.
But have *you* cracked the FM enough to know
what Perforce can do and cannot do? Its model
isn't CVS (and the things you're asking for aren't
part of the standard CVS model either) and if you
want CVS, get it.
You'll miss out on a number of incredibly helpful
things. The branching model in Perforce is excellent,
mining data to give reports to QA for handoffs is
straight-forward, and doing an incremental update
of a workspace is blindingly fast. You won't find
a system that does NT *and* Unix work as seamlessly,
and the Perforce client program ("p4") is available
on just about any platform with a C compiler and
a TCP/IP library. Yes, even VMS. Even IBM S/390.
You're encountering a lot of hostility from this
mailing list because you're asking why developers
will need to learn new keystrokes for a new tool.
Would they tell a customer, who's switching away
from a competitor's product, that their product
can be used with no changes in procedure?
If so, how do you convince the customer to
buy your product that's identical in behavior
to the competitor that they're switching away from?
More information about the perforce-user