[p4] Reasons not to allow adding junk files to Perforce
mh at pixar.com
Mon Jun 21 10:26:00 PDT 2004
Jason Williams wrote:
> Mark Harrison wrote:
>>Seriously, it's a lot better to try to find old project files if they're
>>dumped into perforce than if they're sitting on people's hard drives,
>>old laptops, etc. Suggest to them to set up a dedicated part of the
>>tree for this.
> If there's a benefit to versioning these files (job descriptions, time
> sheets, ec.), then Perforce may be useful.
> But you don't get most of the benefits of Perforce if there's no need for
> branching or even versioning of the files.
There's more to perforce than versioning. Just having a GUI based file
manager that talks to a central file repository is already a big win.
At my old company I set up a (CVS based) system for our sales guys to get
the latest marketing materials, ppt presentations, etc. I gave them a
GUI with exactly one button "Give me the latest files." It was very
nice going into customer presentations knowing that all of my files were
loaded onto the laptop that was plugged into the overhead projector.
Besides, somebody at the OP's company must be finding perforce useful,
since they are already adding files into the repository of their own
accord. Rather than try to kick them out, it's better to set up an
area where they can do this without disturbing the source code.
> Using Perforce simply as a way
> to store files can be accomplished much easier by setting up a file
> server. (NetApp, etc.)
File storage is easy. File management is not. Even if you made a set
of writable directories on a file server, you will have the usual problems...
somebody deleting the entire directory, people editing the live files,
figuring out how to synchronize files to a laptop, etc.
As you attempt to solve these various problems you will find yourself
recreating many of perforce's standard features.
I guess my main claim is "Perforce is useful even if you don't use
every one of its features."
More information about the perforce-user