Re: [Monotone-devel] revert --missing misbehaves in 0.26
Jack Lloyd wrote: Montone's revert --missing seems to base paths off the current directory, rather than the base directory of the workspace. I think most people seeing this would realize the problem and self-correct, but it is strange (drop --missing seems to do the right thing and work no matter what the cwd is). I suppose in some extremely contorted case this could cause Monotone to revert the wrong file, as well. Based on the documentation this behaviour seems unintentional, and performing revert --missing from a subdirectory of a workspace should revert all missing files in or below that subdir. Three things come to mind: 1. I think that 'revert --missing' currently has different behaviour than 'drop --missing' and 'add --unknown' and I'm curious as to what people's expectations are. What 'revert --missing' does when it has a restriction (i.e. 'revert --missing path ...') is essentially to run 'ls missing path ...' and then revert the missing paths that match the restriction. The restriction applies to missing things. Conversely, 'add --unknown path ...' and 'drop --missing ...' add or drop *all* missing paths in *addition* to those that match the restriction. So in revert's case, the --missing set is intersected with the restricted set. While in the add/drop cases the --missing set is unioned with the restricted set. I haven't checked but it would probably be good if someone can confirm this actually is the current behaviour. The question I have is, is this behaviour correct or perhaps intuitive? 2. All of the ls commands that list paths do so relative to the workspace root rather than the current directory. I'm not sure what the general expectation is here but it seems somewhat odd to me. If my workspace dir is W, and I'm in W/a/b/c and say 'ls foo' I see paths like a/b/c/1 a/b/c/2 etc. The wikie page http://venge.net/monotone/wiki/RelativePathnames makes me wonder if the ls commands really should list paths relative to the currrent directory. 3. The reason that revert --missing was screwing up in the case above was pretty much that it too was expecting paths to be relative to the current directory, rather than the workspace root. It's literally using the paths from ls missing. Lots of fun UI issues still to work out! Any opinions on any of the above? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] revert --missing misbehaves in 0.26
Derek Scherger wrote: 1. I think that 'revert --missing' currently has different behaviour than 'drop --missing' and 'add --unknown' and I'm curious as to what people's expectations are. What 'revert --missing' does when it has a restriction (i.e. 'revert --missing path ...') is essentially to run 'ls missing path ...' and then revert the missing paths that match the restriction. The restriction applies to missing things. Conversely, 'add --unknown path ...' and 'drop --missing ...' add or drop *all* missing paths in *addition* to those that match the restriction. So in revert's case, the --missing set is intersected with the restricted set. While in the add/drop cases the --missing set is unioned with the restricted set. I haven't checked but it would probably be good if someone can confirm this actually is the current behaviour. The question I have is, is this behaviour correct or perhaps intuitive? Ok, I've now checked and I'm wrong here, revert --missing, drop --missing and add --unknown all work the same as far as restrictions are concerned. They first effectively run the corresponding ls command with the specified restriction and then operate on the resulting set of paths. One small problem though, 'mtn ls unknown foo' and 'mtn add --unknown foo' both fail if foo is an unknown path. The current restrictions code doesn't let you specify restrictions based on paths that unknown known. It does unknown paths that are also ignored to be specified though. If I recall correctly, this behaviour was added to fix problems like 'mtn commit foo' from doing a whole-tree commit, rather than failing if foo is unknown. The issue at the time was that unknown paths were simply removed from the restriction which ended up empty and allowed everything through. I don't think this is possible any more but I need to check further. This is dredging up some rather foggy memories! Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] revert --missing misbehaves in 0.26
Montone's revert --missing seems to base paths off the current directory, rather than the base directory of the workspace. I think most people seeing this would realize the problem and self-correct, but it is strange (drop --missing seems to do the right thing and work no matter what the cwd is). I suppose in some extremely contorted case this could cause Monotone to revert the wrong file, as well. Based on the documentation this behaviour seems unintentional, and performing revert --missing from a subdirectory of a workspace should revert all missing files in or below that subdir. Reproducing is fairly simple, drop a file from one workspace, commit+sync, rm (without dropping) the same file in another workspace, and then update. (washu ~/testing/2nd/a/b/c)$ mtn stat mtn: warning: missing a/b/c/d1 mtn: misuse: 1 missing files; use 'mtn ls missing' to view mtn: misuse: to restore consistency, on each missing file run either mtn: misuse: 'mtn drop FILE' to remove it permanently, or mtn: misuse: 'mtn revert FILE' to restore it mtn: misuse: or to handle all at once, simply 'monotone drop --missing' mtn: misuse: or 'monotone revert --missing' (washu ~/testing/2nd/a/b/c)$ mtn ls missing a/b/c/d1 (washu ~/testing/2nd/a/b/c)$ mtn revert --missing mtn: misuse: unknown path 'a/b/c/a/b/c/d1' (washu ~/testing/2nd/a/b/c)$ mtn revert --missing . mtn: misuse: unknown path 'a/b/c/a/b/c/d1' (washu ~/testing/2nd/a/b/c)$ cd .. (washu ~/testing/2nd/a/b)$ mtn revert --missing mtn: misuse: unknown path 'a/b/a/b/c/d1' (washu ~/testing/2nd/a/b)$ cd .. (washu ~/testing/2nd/a)$ mtn revert --missing mtn: misuse: unknown path 'a/a/b/c/d1' (washu ~/testing/2nd/a)$ cd .. (washu ~/testing/2nd)$ mtn revert --missing (washu ~/testing/2nd)$ Also the messages need to be updated to the new binary name. :) System info: (washu ~)$ mtn --version monotone 0.26 (base revision: 4342565107f26ceda955b66c66b5b7ec152f314e) (washu ~)$ uname -a Linux washu.randomint.net 2.6.16-1.2111_FC4 #1 Sat May 20 19:59:40 EDT 2006 i686 athlon i386 GNU/Linux (washu ~)$ gcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux Thread model: posix gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) (washu ~)$ rpm -q glibc boost glibc-2.3.6-3 boost-1.32.0-6 If you need further information just let me know. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] revert --missing misbehaves in 0.26
On Sat, 2006-06-03 at 08:29 -0400, Jack Lloyd wrote: Montone's revert --missing seems to base paths off the current directory, rather than the base directory of the workspace. Yes. This has been fixed, and will work properly in the next release. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
