Re: nvm.alt_tmpdir

Richard Levitte <[email protected]>
Newsgroups gmane.comp.version-control.monotone.devel
Message-ID <[email protected]>
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 <[email protected]> on Mon, 16 May 2011 16:23:17 -0400, Stephen Leake <[email protected]> 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> [email protected]
stephen_leake> https://lists.nongnu.org/mailman/listinfo/monotone-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.