Next: Refreshing the VC-state, Previous: Checking the state, Up: Version-control support
At least CVS can be used in a mode called “Client/Server” which
means the root repository is located on a remote machine. We call a
repository which can not being mounted by the client-machine (which
contains the working directory) a remote repository. In most
cases getting the fresh and real VC-state for such repositories will
be unacceptable slow or often users will work offline means with no
connection available to the remote host. To avoid problems like these
ECB offers first an option ecb-vc-directory-exclude-regexps
to
exclude such directories with a remote repository from the VC-support
of ECB and secondary the identify-backend-funtion
ecb-vc-dir-managed-by-CVS
behaves smart with that respect
(see Identifying backends). See also
ecb-vc-xemacs-exclude-remote-cvs-repository
!
ECB supports working with remote directories like TRAMP- or
EFS-directories (see Remote directories). Do not confuse remote
directories with remote repositories. A local directory located on
your disk and set in ecb-source-path
can have a remote
repository if managed by a VC-system. A remote directory means a path
in the format of TRAMP, ANGE-FTP or EFS set in ecb-source-path
.
Its very likely that getting the VC-state of files contained in such a
remote directory would be extremly expensive and therefore ECB would
be blocked quite long even if the VC-check is performed stealthy
(see Stealthy background tasks).
To avoid problems with such remote directories ECB prevents per
default such directories from being processed by the VC-support of
ECB. But if a user is dying to having the VC-state being displayed in
the tree-buffers ECB offers two ways to switch on the VC-support - see
the option ecb-vc-enable-support
: This option is set per
default to the value unless-remote
which means remote paths
will not be processed but it can be set to t
which means
process all directories regardless if remote or not. It's strongly
recommended to use unless-remote
!