[p4] Newbie Question
jab at pobox.com
Wed Jan 7 13:38:07 PST 2004
On Jan 7, 2004, at 1:12 PM, Brooke Gravitt wrote:
>> [At home is fine: run a copy of the two-user/two-workspace server on a
>> local Win/NT or Win/2000
>> machine for this. Just don't mix this experiment with your production
> Don't have this luxury.
Don't have the luxury of running through a tutorial to decide how to
check a tree of files into the server? Try this, then...
I guarantee, when you run:
find . type f -print | p4 -x - add
It will check the files into Perforce SO FAST that you'll think it was
a debugging-output and nothing was actually done.
I'd bet folding money on it. Heck, I'd bet a symphony ticket on it.
That's what you'll see when you run through the tutorial.
If you don't have the time for this, do these three things:
1. Start up a server on a machine. Now, go to a second machine, so
you don't accidently screw up and place your test-files in the
2. On the second machine, run these commands:
(save the 'p4 client' info in the editor - just save/quit.)
3. Copy your 6-10 different product trees into $HOME/playarea, in the
You don't have to use these exact names, but it's handy to set up
unrelated products in separate areas, and Perforce will store them
separate directories. No "p4 depot" commands are needed.
4. Now, check them in:
find . -type f -print | p4 -x - add
(type in a description and save it in the editor. Make sure that
field begins with white-space.)
If you're on Linux, do the same thing from the command-line. Don't be
by the fact that this email refers to command-line; everything herein
can be done
from the Windows GUI client, easily, but it's easier to describe and
the command-line. I don't have screen-captures to mail you for GUI
usage, and will
say out-right that it's easier to track what you're doing, as you
learn, if you start
from command-line while you're learning. (That's for YOU. Your users
from command-line or GUI.)
5. Now, run things like "p4 changes" and "p4 edit filename / p4
submit" and so on.
> I have to evaluate whether we stay on the current
> CM tool or migrate to Perforce (which our newly aquired business unit
Ask BEA for advice on this, if you can; they acquired a company using
Perforce, back about 1999, and decided to use Perforce based on the
very strong support it had within the acquired company (Weblogic).
It's hard not to gush about Perforce's ease of use and low overhead.
The other items you are describing don't really measure up, and
has a very high cost - staff-time and hardware - to get working and
>> Avoid the command "p4 depot" (or "p4 depots") until you've used
>> Perforce for weeks/months.
>> It's a more advanced thing that you probably won't need, initially.
> Unfortunately, I need to be able to load up several *seperate*
> (main, support, and customer customizations) of each of product we
> The only way to do this (it appears) is to have seperate depots.
Put them in different directories. //depot/thing1, //depot/thing2, and
> Also, upon reading through the docs, it looks like Perforce's defect
> tracking and proccess management functionality isn't quite on par with
> Harvest, Dimensions, or ClearCase/ClearQuest.
Perforce integrates to various bug databases and also has its "jobs"
as a way of tracking work. It is as full-fledged a bug database as one
separately? No. It doesn't claim to be. But it can buy you time to
decide what you
want. There are many integrations done to make it work with bug
databases, if you
More information about the perforce-user