Managing commit-edge installations

Commit-edge architecture raises certain issues that you must be aware of and learn to manage.

  • Each Edge Server maintains a unique set of workspace and work-in-progress data that must be backed up separately from the Commit Server. See Backup and recovery planning for more information.
  • Exclusive locks are global: establishing an exclusive lock requires communication with the Commit Server, which might incur network latency.

  • Parallel submits from an Edge Server to a Commit Server use standard pull threads to transfer the files. The administrator must ensure that pull threads can be run on the Commit Server by doing the following:

    • Make sure that the service user used by the Commit Server is logged into the Edge Server.

    • Make sure the ExternalAddress field of the Edge Server’s server spec is set to the address that will be used by the Commit Server’s pull threads to connect to the Edge Server.

      If the commit and Edge Servers communicate on a network separate from the network used by clients to communicate with the Edge Server, the ExternalAddress field must specify the Edge Server ip address and port number that is used for connections from the Commit Server. Furthermore, the Edge Server must listen on the two (or more) networks.

      See the p4 help submit command for more information.

  • Shelving changes in a distributed environment typically occurs on an Edge Server. Shelving can occur on a Commit Server only while using a client workspace bound to the Commit Server. Normally, changelists shelved on an Edge Server are not shared between Edge Servers.

    You can promote changelists shelved on an Edge Server to the Commit Server, making them available to other Edge Servers. See Promoting shelved changelists for details.

  • Auto-creation of users is not possible on Edge Servers.

  • You must use a command like the following to delete a client that is bound to an Edge Server: It is not sufficient to simply use the -d and -f options.

    p4 client -d -f --serverid=thatserver thatclient

    This prevents your inadvertently deleting a client from an Edge Server. Likewise, you must specify the server id and the changelist number when trying to delete a changelist whose client is bound to an Edge Server.

    p4 change -d -f --serverid=thatserver 6321
    Note

    An Edge Server that is used only for automated processing, such as builds, can be deployed without a backup/recovery solution because the edge local data is critical only during build-time.