Here's my workspace setup, on a Linux box:
work_stephe
_MTN
build
code_1
code_2
runtime -> <lynx box>/root/runtime
'build' contains makefiles and related files for compiling code. The
compiler is a cross-compiler (from x86 Linux to x86 Lynx OS).
'code_n' contain source code that gets compiled.
'runtime' is a symbolic link to a directory on an NFS-mounted drive on
the Lynx box. For example, suppose
lynx:/home/stephe/work_stephe
is NFS mounted to
linux:/home/stephe/lynx
then
linux:/home/stephe/root/runtime
is linked to
linux:/home/stephe/lynx/work_stephe/runtime.
The makefiles compile an executable and copy it to the corresponding
directory on the Lynx drive. When the executable runs on the Lynx box
CPU, it uses files in the 'runtime' directory; those files need to be
under monotone control.
The problem comes when I try to 'update' or 'revert' a file in runtime;
mtn first writes the files to work_stephe/_MTN/..., then tries to rename
to work_stephe/runtime/... , which fails because it is on a different
device.
One fix is to put all the files in runtime into a separate mtn branch,
with runtime/_MTN, but I think that's overkill.
A better fix is to provide a workspace-specific option that tells mtn to
use a different staging area for files in runtime. For example, in
_MTN/options:
tmpdir "runtime" "runtime/tmp"
The user would presumably add "runtime/tmp" to .mtn-ignore.
This would be passed to file_io.cc:write_data as a map; write_data would
search the map for a matching prefix of the directory being written to.
In the typical case of no 'tmpdir' in _MTN/options, the map would be
empty, causing no speed impact.
Other ideas?