8. The inner workings of remote version control

Unlike EFS, TRAMP has full shell access to the remote machine. This makes it possible to provide version control for files accessed under TRAMP.

The actual version control binaries must be installed on the remote machine, accessible in the directories specified in tramp-remote-path.

This transparent integration with the version control systems is one of the most valuable features provided by TRAMP, but it is far from perfect. Work is ongoing to improve the transparency of the system.

8.1 Determining if a file is under version control

The VC package uses the existence of on-disk revision control master files to determine if a given file is under revision control. These file tests happen on the remote machine through the standard TRAMP mechanisms.

8.2 Executing the version control commands on the remote machine

There are no hooks provided by VC to allow intercepting of the version control command execution. The calls occur through the call-process mechanism, a function that is somewhat more efficient than the shell-command function but that does not provide hooks for remote execution of commands.

To work around this, the functions vc-do-command and vc-simple-command have been advised to intercept requests for operations on files accessed via TRAMP.

In the case of a remote file, the shell-command interface is used, with some wrapper code, to provide the same functionality on the remote machine as would be seen on the local machine.

8.3 Detecting if the working file has changed

As there is currently no way to get access to the mtime of a file on a remote machine in a portable way, the vc-workfile-unchanged-p function is advised to call an TRAMP specific function for remote files.

The tramp-vc-workfile-unchanged-p function uses the functioning VC diff functionality to determine if any changes have occurred between the workfile and the version control master.

This requires that a shell command be executed remotely, a process that is notably heavier-weight than the mtime comparison used for local files. Unfortunately, unless a portable solution to the issue is found, this will remain the cost of remote version control.

8.4 Bringing the workfile out of the repository

VC will, by default, check for remote files and refuse to act on them when checking out files from the repository. To work around this problem, the function vc-checkout knows about TRAMP files and allows version control to occur.

8.5 Things related to Version Control that don't fit elsewhere

Minor implementation details, &c.

8.5.1 How VC determines who owns a workfile

XEmacs provides the user-full-name function to return the login name of the current user as well as mapping from arbitrary user id values back to login names. The VC code uses this functionality to map from the uid of the owner of a workfile to the login name in some circumstances.

This will not, for obvious reasons, work if the remote system has a different set of logins. As such, it is necessary to delegate to the remote machine the job of determining the login name associated with a uid.

Unfortunately, with the profusion of distributed management systems such as NIS, NIS+ and NetInfo, there is no simple, reliable and portable method for performing this mapping.

Thankfully, the only place in the VC code that depends on the mapping of a uid to a login name is the vc-file-owner function. This returns the login of the owner of the file as a string.

This function has been advised to use the output of ls on the remote machine to determine the login name, delegating the problem of mapping the uid to the login to the remote system which should know more about it than I do.

8.5.2 How VC determines what release your RCS is

VC needs to know what release your revision control binaries you are running as not all features VC supports are available with older versions of rcs(1), cvs(1) or sccs(1).

The default implementation of VC determines this value the first time it is needed and then stores the value globally to avoid the overhead of executing a process and parsing its output each time the information is needed.

Unfortunately, life is not quite so easy when remote version control comes into the picture. Each remote machine may have a different version of the version control tools and, while this is painful, we need to ensure that unavailable features are not used remotely.

To resolve this issue, TRAMP currently takes the sledgehammer approach of making the release values of the revision control tools local to each TRAMP buffer, forcing VC to determine these values again each time a new file is visited.

This has, quite obviously, some performance implications. Thankfully, most of the common operations performed by VC do not actually require that the remote version be known. This makes the problem far less apparent.

Eventually these values will be captured by TRAMP on a system by system basis and the results cached to improve performance.

This document was generated by XEmacs shared group account on December, 19 2009 using texi2html 1.65.