monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] symlink to NFS drive vs update


From: Stephen Leake
Subject: [Monotone-devel] symlink to NFS drive vs update
Date: Wed, 15 Dec 2010 03:00:57 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt)

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?

-- 
-- Stephe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]