monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] nvm.alt_tmpdir


From: Stephen Leake
Subject: [Monotone-devel] nvm.alt_tmpdir
Date: Mon, 16 May 2011 16:23:17 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt)

I've started implementing a 'tmpdir' option, to allow symlinks to NFS
mounted drives in a workspace, on branch nvm.alt_tmpdir.

See the earlier thread:
http://lists.nongnu.org/archive/html/monotone-devel/2010-12/msg00035.html

The core issue is that on Linux, with an NFS mounted directory, 'mv
_MTN/detached/* foo/bar' fails, since they are on different devices.

This causes 'update', among other commands, to fail.

The solution I'm implementing is to declare a list of alternate tmpdirs,
located on the same drive as the workspace dirs, so 'mv' will succeed.

Note that after checkout, the user must manually rearrange the workspace
to mount the NFS drive (possibly via symlink) in the right place, with
the checked out files; I'm not planning on having 'mtn checkout' do that
automatically :).

The test currently passes, but since it doesn't use two drives such that
'mv' would fail, that doesn't mean much :(. The code is not complete;
see the FIXMEs in the commit.

I have several issues that I'd like to discuss:

1) Is there a way to write a better test?

    I don't see an easy way to set up two drives in a test. I think I
    can get the same effect using a simlink to a USB drive on my Linux
    box, but that's a severe manual intervention requirement!

    Note that 'mv' between two drives succeeds on Windows, so this would
    be a Linux-only test (not labeled that way yet, so I can at least
    test option parsing on Windows).

    Failing that, we could add some verbosity that reports which tmpdir
    was used.

2) method for specifying tmpdir in _MTN/options

    Currently, I just directly edit _MTN/options (in Emacs, or via
    'cat'). I'm wondering if there should be some mtn command that
    accomplishes that.

    Currently, there no commands accept the 'tmpdir' option. It's needed
    on any command that writes to the workspace, but it obviously
    belongs in _MTN/options, so adding it to all the individual commands
    seems like overkill.

    If we add 'tmpdir' to 'update' (or some other command), I would find
    it annoying to have to run one 'update --tmpdir...' to get the
    option into _MTN/options, and then run all subsequent commands
    without --tmpdir.

    I'd rather edit _MTN/options at the same time I rearrange the
    workspace to add the NFS mount, not later when I have something to
    update.

    Perhaps there should be a new command 'edit-ws-option'? That would
    also be useful when moving a database, or a keydir.

3) option syntax

    The current syntax in _MTN/options is:

        tmpdir "nfs_mounted=nfs_mounted/tmp"

    Note that I'm allowing for multiple 'tmpdir' lines.

    On a command line, that would be:

        --tmpdir "nfs_mounted=nfs_mounted/tmp"

    or:

        --tmpdir="nfs_mounted=nfs_mounted/tmp"

    There are 2 values to be specified, so something like this seems
    necessary, if we use the existing option machinery.

    If we don't add 'tmpdir' to any commands, then it would be possible
    to change things to allow two string values on a single _MTN/options
    line. That would violate some of the current options machinery; I
    don't think that's a good way to go.

    I know of no other options that need two values.

    Perhaps there is a better separator char?

4) general code approach

    One way to resolve the current FIXMEs is to expand the notion of
    'bookkeeping path' to include the new tmpdirs. That seems overly
    complicated. Otherwise anyplace that uses a bookkeeping_path to
    store the path _MTN/detached/* will need to use a system_path
    instead; that sort of change has caused problems in the past (in the
    conflict code, in particular).

    other issues?

--
-- Stephe



reply via email to

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