Perforce Public Knowledge Base - Local vs Global commands - Using Federated Architecture to Best Advantage
× PRODUCTS SOLUTIONS CUSTOMERS LEARN SUPPORT
Downloads Company Partners Careers Contact Free Trials
Menu Search
Perforce
Reset Search
 

 

Article

Local vs Global commands - Using Federated Architecture to Best Advantage

« Go Back

Information

 
Problem

Edge-Commit architecture is a good solution for geographically distributed work groups, and it can offer significant performance advantages whether clients are widely distributed or not. It is made up of a commit server and one or more edge servers that are connected to the commit server:

  • The commit server stores the canonical archives and permanent metadata.

    It processes write operations and operations that affect global data.

  • The edge server contains a replicated copy of the commit server data and a unique, local copy of some workspace and work-in-progress information.

    It can process read-only operations and operations like p4 edit that only write to the local data.

This architecture trades off performance and visibility. As much of the work as possible is entrusted to the edge server, thus avoiding the performance degradation that happens over high latency networks or that happens when the commit server is burdened with all the work. However, that also means that local work is not visible to users connected to other edge servers. The only way data can be shared across edge servers, is to make it global, which implies making the data available to the commit server.

This article explains how work is distributed between the edge server and the commit server and provides guidelines that can help you use this architecture to best advantage.

(For detailed information about setting up and managing this architecture, see http://www.perforce.com/perforce/doc.current/manuals/p4dist/chapter.distributed.html)

Solution

Local and Global Commands

Local commands are executed on the edge server to which the client is connected; global commands are executed on the commit server. It might help you to fine tune performance if you understand this difference and know where P4D commands are executed.

Local commands execute faster because they execute locally or, at worst, travel over a local area network:

  • All read-only commands are local

  • Commands related to workspace state are always local

  • A label can be local

  • Edge specific shelves are local, until they are promoted.

Global commands execute more slowly than local commands because they must often travel over wide area networks and because the type of work they do tends to be more resource intensive.

  • Commands that update data stored on the commit server are global, for example Submit

  • Changelist numbers & description are always global

  • Workspace name (and, since 15.2+, its view) are global

  • Any change in the state of files of type +l must be global

  • A label can be local or global, but its *name* is always global

  • Promoted shelves or the act of promoting a shelf is global

For example, p4 sync:

Hence p4 sync is a local command that can be run on an edge server without any connection to the commit server

In the case of some commands, the specified options might determine whether the command is executed locally or remotely. For example, branch –o is a read-only command, hence local; whereas branch –i is an updating command, hence global.

The tables at the end of this article indicate which commands are global and which, local.

Making Local Data Global

Common cases in which you might want to make data global concern shelved changelists, client views, and locks. Be aware that global visibility might degrade performance.

For detailed information, see http://www.perforce.com/perforce/doc.current/manuals/p4dist/chapter.distributed.html

Global Commands

CommandsDescriptionComments
branch -iCreate, modify, or delete a branch view specification. The -i flag causes a branch spec to be read from the standard input. The user's editor is not invoked.This is an updating command, hence will work globally
changeCreate or edit a changelist descriptionAdd – No Edit – works locally on Edge, but fails to update Commit server
changelistCreate or edit a changelist description 
clientCreate or edit a client specification and its viewCreate – No Edit – works locally on Edge, but fails to update Commit Server.
counterset, or delete a counter 
depotCreate or edit a depot specification 
fixMark jobs as being fixed by named changelists 
groupChange members of a user group 
istatShow integrations needed for a stream 
jobCreate or edit a job (defect) specification 
keyDisplay, set, or delete a key/value pair 
labelCreate or edit a label specification and its view 
labelsyncSynchronize label with the current client contentsYes, if label exists, and is local to the edge server.
lockLock an opened file against changelist submissionNew 2015.2 'lock -g' flag will not work.
loggerReport what jobs and changelists have changed 
loginLogin to Perforce by obtaining a session ticket 
logoutLogout of Perforce by removing or invalidating a ticket 
passwdSet the user's password on the server (and Windows client) 
populatePopulate a branch or stream with files 
protectModify protections in the server namespace 
pruneRemove unmodified branched files from a stream 
shelveStore files from a pending changelist into the depotMay not work: 1) if you are promoting a shelve for global consumption, or 2) unshelving a global shelve
streamCreate or edit a stream specification 
submitSubmit open files to the depot 
tagTag files with a labelYes, if label exists, and is local to the edge server.
unlockRelease a locked file but leave it openNew 2015.2 'unlock -g' flag will not work.
userCreate or edit a user specification 
workspaceCreate or edit a client specification and its view 

Local Commands

CommandsDescriptionWill work?
addOpen a new file to add it to the depotWill work for files that have an exclusive lock on them
annotatePrint file lines along with their revisions 
attributeSet per-revision attributes on revisionsBut does not work for submitted files. Not recommended in a Federated architecture
branch -oCreate, modify, or delete a branch view specification. The -o flag writes the branch spec to standard output. The user's editor is not invoked.This is a read-only command, hence will work locally
branchesDisplay list of branches 
changesDisplay list of pending and submitted changelists 
changelistsDisplay list of pending and submitted changelists 
cleanDelete or refresh local files to match depot state 
clientsDisplay list of known clients 
copySchedule copy of latest rev from one file to anotherWill work for files that have an exclusive lock on them
counterDisplay a counter 
countersDisplay list of known counters 
cstatDump change/sync status for current client 
deleteOpen an existing file to delete it from the depotWill not work for files that have an exclusive lock on them
depotsDisplay list of depots 
describeDisplay a changelist description 
diffDisplay diff of client file with depot file 
diff2Display diff of two depot files 
dirsList subdirectories of a given depot directory 
editOpen an existing file for editWill not work for files that have an exclusive lock on them
filelogList revision history of files 
filesList files in the depot 
fixesList what changelists fix what job 
flushFake a 'p4 sync' by not moving files 
fstatDump file info 
grepPrint lines from text files matching a pattern 
groupsList groups (of users) 
haveList revisions last synced 
helpPrint the requested help message 
infoPrint out client/server information 
integrateSchedule integration from one file to anotherWill not work for files that has an exclusive lock on them
integratedShow integrations that have been submitted 
interchangesReport changes that have not yet been integrated 
jobsDisplay list of jobs 
keysDisplay list of known keys and their values 
labelsDisplay list of labels 
labelsyncSynchronize label with the current client contentsYes, if label exists, and is local to the edge server.
listCreate an in-memory (label) list of depot files 
lockLock an opened file against changelist submissionNew 2015.2 'lock -g' flag will not work.
mergeSchedule merge (integration) from one file to anotherMay not work for files that have an exclusive lock on them
moveMoves files from one location to another 
openedDisplay list of files opened for pending changelist 
printRetrieve a depot file to the standard output 
protectsDisplay protections in place for a given user/path 
recReconcile client to offline workspace changes 
reconcileReconcile client to offline workspace changes 
renameMoves files from one location to another 
reopenChange the type or changelist number of an opened file 
resolveMerge open files with other revisions or files 
resolvedShow files that have been merged but not submitted 
revertDiscard changes from an opened fileIf "revert" has to revert an exclusive locked file. It needs to contact the Commit Server, hence in that scenario this won't work
reviewList and track changelists (for the review daemon)But not with -t flag
reviewsShow what users are subscribed to review files 
setSet variables in the registry (Windows only) 
statusPreview reconcile of client to offline workspace changes 
sizesDisplay size information for files in the depot 
streamsDisplay list of streams 
syncSynchronize the client with its view of the depot 
tagTag files with a labelYes, if label exists, and is local to the edge server.
ticketsDisplay list of session tickets for this user 
unlockRelease a locked file but leave it openNew 2015.2 'unlock -g' flag will not work.
unshelveRestore shelved files from a pending changelistMay not work for 1) files that have an exclusive lock on them, or 2) unshelving a global shelve
updateUpdate the client with its view of the depot 
usersDisplay list of known users 
whereShow how file names map through the client view 
workspacesDisplay list of known clients 
  • Updates workspace state only (and does not update global data).

  • Does not modify any changelist specifications.

  • Does not modify your workspace specifications.

  • Does not change the state of any exclusively locked (+l) files.

  • Does not create any labels.

  • Does not promote any shelves:

    • Changelists shelved on an edge server, which would normally be inaccessible from other edge servers, can be automatically or explicitly promoted to the commit server. Promoted shelved changelists are available to any edge server.

    • You can use the server.global.client.views configurable to specify whether the view maps of a non-stream client on an edge server are made global when the client is modified. This configurable can be set globally or individually for each server, thus allowing client maps to be global on most edge servers while keeping them local on those edge servers that don't need them to be global.

    • You can use the -g flag of the p4 lock command to lock the files locally and globally. The -g option must be used with the -c changelist option. This lock is removed by the p4 unlock -g command or by any submit command for the specified changelist

Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255