FreeLists / openbeos / [openbeos] More on Perforce

["Mikael Jansson (mailing lists)" <lists@xxxxxxxxxxxxxxxxx>]

Hello again,

This will be my last off-topic post on the subject until my opinion is 
asked for. :)

As Perforce has nifty triggers, you can say things like: Don't allow 
for any submits to the release line that doesn't fix an existing job.
It also integrates well with other bug tracking software.  So if 
someone finds a bug in //depot/release/r1/..., but people are working 
on //depot/release/main/... (in this case probably r2), you'd file a 
bug (or "job" in p4 lingo) with the r1 release, and then you wouldn't 
be allowed to submit change lists to that branch that doesn't 
explicitly fix a submitted job.

Also, you can do stuff like making sure there's always a README added 
whenver there's a .exe added (example ripped from the excellent P4 
User's Guide, ~150 pages - it's worth the dead trees).  Of course, we 
don't have .exe, but the example could be extended to other things - 
for example, if there won't be a version of P4d that supports 
attributes correctly, one could make an application that checks for 
.rsrc files and automatically rejects the file as the attributes would 
be lost, and telling the user to zip it up first. As "triggers" work on 
a server level, I'm not quite sure how easy it would be to do the 
zipping automagically on the client side.

Here's the online version of the User's Guide, but it's also available 
in PDF:
http://perforce.com/perforce/doc.042/manuals/p4guide/index.html

Also, for the guy administrating the depot (it seems that the general 
consensus is that you generally don't need more than one checking the 
Perforce server now and then, as opposed to other SCMs.):
http://perforce.com/perforce/doc.042/manuals/p4sag/index.html


Regards,
--
Mikael Jansson
http://mikael.jansson.be