Working Disconnected

How do you work disconnected from the Perforce Server?

Info & Tags

Article #:
2
Created:
02/20/07
Modified:
05/26/08

Task

Can I work on files in my client workspace without being connected to a Perforce Server?
How can I reconcile my workspace once I am reconnected to the server?
What if I have created new files?
Modified files without opening them for edit?
Deleted files?

Solution

You can work on your versioned files when disconnected from the Perforce server, however, you will not have any access to Perforce server functions when working disconnected. Also, any changes you make to your versioned files while working "offline" will make your workspace inconsistent with the Perforce Server metadata. When you reconnect to the Perforce Server, you must reconcile your offline changes.

Your client workspace is in-sync when Perforce knows which files you have in it, and which ones you have opened for adding, deleting, or editing. If you create, remove, or modify workspace files without Perforce's knowledge, your workspace gets out-of-sync. Typically this happens when you've done some work offline (for example, when you use your laptop on the train) or when you've used an application development environment that doesn't work directly with Perforce for file management.

This note describes how to reconcile your Perforce client information with workspace changes made outside of the system, and how to build a changelist after the fact. This changelist, which will describe the differences between your workspace and the files in the depot, can then be submitted.

There are four types of workspace changes that can go in the changelist:

  1. files deleted
  2. files changed
  3. new files added
  4. files renamed (optional)

Assume you are using a client named "myclient", whose workspace root is "/testclient" (UNIX) or "c:testclient" (Windows).

  1. First, open for "delete" any old files no longer present:
     p4 diff -sd //myclient/... | p4 -x - delete

    p4 diff -sd returns the names of depot files with no corresponding workspace file. All files you removed from your workspace will now be opened for delete.

  2. Next, open for "edit" any files that have changed:

     p4 diff -se //myclient/... | p4 -x - edit

    p4 diff -se returns the names of depot files whose corresponding client file differs in any way from the clients #have revision.

  3. Next, find the new files and open them for "add":

     Unix:
    cd /testclient
    find . -type f -print | p4 -x - add

    Note that the above command will not add symlinks. See Adding a Directory Tree for details.

     Windows:
    cd c:testclient
    dir /s /b /a-d | p4 -x - add
     Macintosh MPW:
    directory :testclient
    files -f -q -r -s | p4 -x - add

    This attempts to add every file in the workspace path as a new depot file. For any file that already exists in the depot you'll get a message "... - can't add existing file," which is harmless. All new files you created in your workspace will now be opened for add.

  4. Finally, determine if you renamed any files and, if so, decide if you want to add them or use p4 integrate to branch them.

    Renaming files "offline" is not recommended because there is no direct way for Perforce detect if a file was renamed or simply deleted. The rename operation in Perforce is a two step process: an integrate followed by a delete. If you did rename a file offline, then Step #1 above will detect the renamed file as a newly added file and Step #2 above will detect the old renamed file as a deleted file and will open the old file name for delete. For files renamed offline, the delete operation in Step #2 above is correct, but technically, the add operation in Step #1 is not. Instead of adding the renamed files (as in Step #1), the proper thing to do with such files is to branch the old file name into the new file name. Although adding the renamed file as a new file will work, using the integrate operation is better because it creates a link between the old and new file names that preserves change history across the rename.

    If you see a newly renamed file appear in your changelist marked for add as a result of Step #1 above, it is possible to change the add to an integrate. However, doing so requires that you perform a p4 revert operation first. If you made any content changes to the newly renamed file, those changes may be lost (as a result of the revert). For example, say you renamed file "abc.c" to "xyz.c" while working offline. After performing steps 1 through 3 above, you could then correct the errant add operation as follows:

     p4 revert xyz.c
    p4 integrate abc.c xyz.c

    Again, note that if you made changes to the file "xyz.c" after renaming it from "abc.c", the changes to "xyz.c" will be lost because of the need to revert. An alternative aproach which avoids the possibility of losing your local changes is to prevent the integrate from overwriting your local files. The commands required are an extension of those listed above:

     p4 revert xyz.c
    p4 integrate -v abc.c xyz.c
    p4 edit xyz.c
    p4 delete abc.c
    p4 submit
    p4 flush xyz.c

    Reopening the file for edit tells the server to take the local file contents rather than perform a lazy copy and running the flush command updates the clients have list to reflect the changes made.

Once you've done these steps, you'll have a changelist that contains the files you've created, removed, modified or renamed. After you've examined the changelist to make sure it doesn't refer to any extraneous files, you may go ahead and submit it.

Users of P4Win can now perform the last two diff steps by employing the built-in Check Consistency command located on the P4Win File->More menu.