Jump to content


Versioning the Perforce executables

p4 administration

  • Please log in to reply
2 replies to this topic

#1 Chance

Chance

    Advanced Member

  • Members
  • PipPipPip
  • 31 posts

Posted 09 July 2014 - 02:40 PM

My office runs Linux.  I'd like everyone to have the most up to date client software, p4 and p4v.  To make this easy, I installed p4 and p4v on an NFS share, but the problem is whenever people work disconnected or the NFS server has issues, they can't access Perforce because they don't have the executables.  I'd also like people to avoid the process of updating the sofware themselves, which is the case with a local copy.

My idea was to version the executables themselves, so that at the workspace root there is a bin/ directory and lib/ directory (supporting files for p4v), and people would add this to their path.  That way the admin can just update their copy and submit and everyone has the latest version.  I know the one glaring problem is that someone would have to get Perforce to get Perforce, but most people already have it in the office, they just aren't up to date. Plus they can use the NFS version for the first time.

Any thoughts on this approach?  Has anyone tried it?

#2 Dan Wierenga

Dan Wierenga

    Member

  • Members
  • PipPip
  • 16 posts

Posted 09 July 2014 - 04:31 PM

I have my linux sysadmins push the p4 binary out to /usr/local/bin on all of our machines via a configuration management tool (it used to be cfengine, now I've heard rumors we've moved to puppet or chef.  I don't know or care!).  That avoids the "bootstrap" problem of storing it in Perforce (i.e. how to get Perforce from Perforce when you don't have Perforce?).  It also puts the p4 executable on the same footing as any other linux package - if it's missing on a machine, it's the sysadmin team's problem, not just a Perforce problem. At least in my organization, there's a lot more of them than there are of me.

If you're intent on doing this, I would at least run a P4Web version somewhere so that people can just use a browser to get the most recent p4 executable.

#3 G Barthelemy

G Barthelemy

    Advanced Member

  • Members
  • PipPipPip
  • 65 posts
  • LocationUnited Kingdom

Posted 15 July 2014 - 01:17 PM

View PostDan Wierenga, on 09 July 2014 - 04:31 PM, said:

I have my linux sysadmins push the p4 binary out to /usr/local/bin on all of our machines via a configuration management tool (it used to be cfengine, now I've heard rumors we've moved to puppet or chef.  I don't know or care!).  That avoids the "bootstrap" problem of storing it in Perforce (i.e. how to get Perforce from Perforce when you don't have Perforce?).


You could extend this concept by actually using Perforce as a back end to cfengine (or puppet or chef). This is what the Linux sysadmins do at my company, and that gives them all the advantages of revision control (audit / traceability, parallel development of cfengine promises and content) while allowing them to delegate the maintenance of some scripts, binaries, etc... to others (non superusers), thanks to Perforce protection rules and groups.
To perform a global deployment of new Perforce binaries, all I have to do is submit a new version of the binaries (for all the flavours of platform and O/S that we support) in the it/cfengine depot, and lo and behold, hundreds of hosts will be upgraded in the minutes that follow (there is a bit of a catch 22 to handle when upgrading the actual p4d binaries destined for the Perforce server, but we still use that deployment method for them).





Also tagged with one or more of these keywords: p4, administration

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users