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

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.