monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] nvm.alt_tmpdir


From: Richard Levitte
Subject: Re: [Monotone-devel] nvm.alt_tmpdir
Date: Wed, 18 May 2011 17:24:02 +0200 (CEST)

So, am I getting this right, the issue is actually to move a file from
one device to another?  It seems a bit overcomplicated to have a
tmpdir option when we could simply detect if source and destination
are on the same device (the structure returned by stat() has the
fields st_dev which is to be used for this), and select to do
something corresponding to 'mv' if it's the same, or 'cp' followed by
'rm' if not.

Cheers,
Richard

In message <address@hidden> on Mon, 16 May 2011 16:23:17 -0400, Stephen Leake 
<address@hidden> said:

stephen_leake> I've started implementing a 'tmpdir' option, to allow symlinks 
to NFS
stephen_leake> mounted drives in a workspace, on branch nvm.alt_tmpdir.
stephen_leake> 
stephen_leake> See the earlier thread:
stephen_leake> 
http://lists.nongnu.org/archive/html/monotone-devel/2010-12/msg00035.html
stephen_leake> 
stephen_leake> The core issue is that on Linux, with an NFS mounted directory, 
'mv
stephen_leake> _MTN/detached/* foo/bar' fails, since they are on different 
devices.
stephen_leake> 
stephen_leake> This causes 'update', among other commands, to fail.
stephen_leake> 
stephen_leake> The solution I'm implementing is to declare a list of alternate 
tmpdirs,
stephen_leake> located on the same drive as the workspace dirs, so 'mv' will 
succeed.
stephen_leake> 
stephen_leake> Note that after checkout, the user must manually rearrange the 
workspace
stephen_leake> to mount the NFS drive (possibly via symlink) in the right 
place, with
stephen_leake> the checked out files; I'm not planning on having 'mtn checkout' 
do that
stephen_leake> automatically :).
stephen_leake> 
stephen_leake> The test currently passes, but since it doesn't use two drives 
such that
stephen_leake> 'mv' would fail, that doesn't mean much :(. The code is not 
complete;
stephen_leake> see the FIXMEs in the commit.
stephen_leake> 
stephen_leake> I have several issues that I'd like to discuss:
stephen_leake> 
stephen_leake> 1) Is there a way to write a better test?
stephen_leake> 
stephen_leake>     I don't see an easy way to set up two drives in a test. I 
think I
stephen_leake>     can get the same effect using a simlink to a USB drive on my 
Linux
stephen_leake>     box, but that's a severe manual intervention requirement!
stephen_leake> 
stephen_leake>     Note that 'mv' between two drives succeeds on Windows, so 
this would
stephen_leake>     be a Linux-only test (not labeled that way yet, so I can at 
least
stephen_leake>     test option parsing on Windows).
stephen_leake> 
stephen_leake>     Failing that, we could add some verbosity that reports which 
tmpdir
stephen_leake>     was used.
stephen_leake> 
stephen_leake> 2) method for specifying tmpdir in _MTN/options
stephen_leake> 
stephen_leake>     Currently, I just directly edit _MTN/options (in Emacs, or 
via
stephen_leake>     'cat'). I'm wondering if there should be some mtn command 
that
stephen_leake>     accomplishes that.
stephen_leake> 
stephen_leake>     Currently, there no commands accept the 'tmpdir' option. 
It's needed
stephen_leake>     on any command that writes to the workspace, but it obviously
stephen_leake>     belongs in _MTN/options, so adding it to all the individual 
commands
stephen_leake>     seems like overkill.
stephen_leake> 
stephen_leake>     If we add 'tmpdir' to 'update' (or some other command), I 
would find
stephen_leake>     it annoying to have to run one 'update --tmpdir...' to get 
the
stephen_leake>     option into _MTN/options, and then run all subsequent 
commands
stephen_leake>     without --tmpdir.
stephen_leake> 
stephen_leake>     I'd rather edit _MTN/options at the same time I rearrange the
stephen_leake>     workspace to add the NFS mount, not later when I have 
something to
stephen_leake>     update.
stephen_leake> 
stephen_leake>     Perhaps there should be a new command 'edit-ws-option'? That 
would
stephen_leake>     also be useful when moving a database, or a keydir.
stephen_leake> 
stephen_leake> 3) option syntax
stephen_leake> 
stephen_leake>     The current syntax in _MTN/options is:
stephen_leake> 
stephen_leake>         tmpdir "nfs_mounted=nfs_mounted/tmp"
stephen_leake> 
stephen_leake>     Note that I'm allowing for multiple 'tmpdir' lines.
stephen_leake> 
stephen_leake>     On a command line, that would be:
stephen_leake> 
stephen_leake>         --tmpdir "nfs_mounted=nfs_mounted/tmp"
stephen_leake> 
stephen_leake>     or:
stephen_leake> 
stephen_leake>         --tmpdir="nfs_mounted=nfs_mounted/tmp"
stephen_leake> 
stephen_leake>     There are 2 values to be specified, so something like this 
seems
stephen_leake>     necessary, if we use the existing option machinery.
stephen_leake> 
stephen_leake>     If we don't add 'tmpdir' to any commands, then it would be 
possible
stephen_leake>     to change things to allow two string values on a single 
_MTN/options
stephen_leake>     line. That would violate some of the current options 
machinery; I
stephen_leake>     don't think that's a good way to go.
stephen_leake> 
stephen_leake>     I know of no other options that need two values.
stephen_leake> 
stephen_leake>     Perhaps there is a better separator char?
stephen_leake> 
stephen_leake> 4) general code approach
stephen_leake> 
stephen_leake>     One way to resolve the current FIXMEs is to expand the 
notion of
stephen_leake>     'bookkeeping path' to include the new tmpdirs. That seems 
overly
stephen_leake>     complicated. Otherwise anyplace that uses a bookkeeping_path 
to
stephen_leake>     store the path _MTN/detached/* will need to use a system_path
stephen_leake>     instead; that sort of change has caused problems in the past 
(in the
stephen_leake>     conflict code, in particular).
stephen_leake> 
stephen_leake>     other issues?
stephen_leake> 
stephen_leake> --
stephen_leake> -- Stephe
stephen_leake> 
stephen_leake> _______________________________________________
stephen_leake> Monotone-devel mailing list
stephen_leake> address@hidden
stephen_leake> https://lists.nongnu.org/mailman/listinfo/monotone-devel



reply via email to

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