[p4] Reasons not to allow adding junk files to Perforce

Janulewicz, Matthew mjanulew at alarismed.com
Fri Jun 18 11:42:45 PDT 2004


I agree with this 100%, but I thought the original question was about
'management', timesheets and job descriptions. Should HR be using version
control for documents? I don't see the benefit.
 
When I think of 'management', I think of people higher up than project
managers. I'm thinking VP's and CEO's, HR people, etc. I'm not sure I would
want to undertake a project that entailed training all these non-engineers
in regards to what version control is and how to use it, especially when I
don't think I can show any ROI for them to use it.
 
So, let me clarify my earlier point, before I start getting hate mail again
;)
 
Anything having to do with your code assets, projects, etc (design docs,
requirements docs, build instructions, release process docs, etc.) should
definitely be in source control. Even though they are generally hard to
diff/version, you need to track those assets. If you industry is regulated
by a government entity and you don't have these things tracked, God help you
during your next audit.
 
Time sheets, job descriptions, sticky notes, e-mails, etc., why bother?
 
 
-Matt
 

-----Original Message-----
From: Grills, Jeff [mailto:jgrills at soe.sony.com] 
Sent: Friday, June 18, 2004 11:26 AM
To: HB. Nguyen; perforce-user at perforce.com
Subject: RE: [p4] Reasons not to allow adding junk files to Perforce


I highly support the behavior you seem to not like.  But it's best to put
those sorts of things in their own place.  We have (where current is our
mainline branch): 
 
    //depot/studio/doc/...

    //depot/swg/current/data/...
    //depot/swg/current/doc/...
    //depot/swg/current/src/...
    and so on   
 
The //depot/studio/doc/... directory is where stuff not related to the game
project goes, and //depot/swg/current/doc/... is obviously where most of the
game-related documentation goes.  We even add private user directories for
those who ask for them, such as this:
 
    //depot/user/jgrills/...
 
When I was a system administrator, I found it very useful to keep much of
/etc on my unix machines in source control.  And we're in the process of
migrating all of our live server configuration files into perforce as well.
 
Version control is your friend.  Use it.  As long as your hierarchy is laid
out well, people should be able to avoid mapping in files they don't care
about, and your server performance will be basically unaffected.  The only
concern I think you may justifiably have is disk space.  Versions of files
never go away - perforce only ever grows (discounting obliterate, of
course).
 
j
 

-----Original Message-----
From: perforce-user-admin at perforce.com
[mailto:perforce-user-admin at perforce.com]On Behalf Of HB. Nguyen
Sent: Friday, June 18, 2004 12:22 PM
To: perforce-user at perforce.com
Subject: [p4] Reasons not to allow adding junk files to Perforce


Hi all,
Our management people are adding lots of stuffs that are not "Source Codes"
into Perforce (ex: job descriptions, time sheets ... ). 
 
Please give me 3 reasons to convince them not to add it to Perforce.
Thanks
 
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.perforce.com/pipermail/perforce-user/attachments/20040618/b4560969/attachment-0008.html>


More information about the perforce-user mailing list