Helix DVCS - Administer like a Pro
If you have seen my previous posts on DVCS you are probably keen to start using DVCS for real by cloning one of your projects from your central Perforce Helix server. But more likely than not you will find that when you execute that clone command you will get an error message instead:
Remote server 'perforce:1666' not configured to clone (server.allowfetch)
Why is that? Well, a typical Perforce Helix server contains all the intellectual properties of an enterprise and its administrators went through great lengths to ensure the security of that server. Opening up such a server to cloning via a simply upgrade to 15.1 would have sprung a nasty surprise on these administrators; therefore, fetching - and by implication, cloning (which is effectively a ‘p4 init’ followed by a ‘p4 fetch’) and pushing is disabled by default.
To see and modify your configuration you need to have administration rights. With these you can run the command
p4 configure show
and look out for the following entries:
server.allowfetch server.allowpush server.allowrewrite
While the names of these configurables are self-explaining (we will cover server.allowrewrite in another post), the values are not. Fortunately, a simple ‘p4 help configurables’ can help here:
server.allowfetch Whether changes can be fetched:
1: This server can fetch from other servers
2: Other servers can fetch from this server
3: Both (1) and (2) are allowed
server.allowpush Whether changes can be pushed:
1: This server can push to other servers
2: Other servers can push to this server
3: Both (1) and (2) are allowed
So fetching and pushing go both ways: I can control if my server is the source or the target or both. By default, the following values are set:
The central server has push and fetch disabled, as discussed above. To enable cloning and to be able to accept push operations from those cloned servers, the administrator needs to set both configurables:
p4 configure set server.allowpush=1 p4 configure set server.allowfetch=1
Now any authenticated user can clone files to which he or she has read access. If the user has write access, any local changes can be pushed back to the central server as well.
Your personal server, created via ‘p4 init’ or ‘p4 clone’, allows you to fetch changes, but it also allows others to clone and fetch from you (if they can access the server at all). On the other hand, no one can push to your personal server without your knowledge and explicit permission.
How can I open up my personal server to other users, you ask? After all, the personal server is locally accessed through the RSH mechanism; no network is involved. Simple: start up a p4d process. All you will need is the root directory of your personal server (for example, ‘p4 set P4INITROOT’ and a free network port. For example, on Linux and Mac:
p4d –r `p4 set -q P4INITROOT | sed 's/P4INITROOT=//'`/.p4root -p 1234 –d
(Notice the back quotes)
For your personal server you are super user (didn’t you always want to have super powers?), so you can add users, set protections and triggers at your heart’s content.
And speaking of triggers: once 2015.2 is in beta, I will explain the upcoming push-triggers in another post.