On Wed, Jul 06, 2005 at 11:09:38PM +0200, Leif Jakob wrote: > On Tue, Jul 05, 2005 at 06:51:13PM -0700 Nathaniel Smith wrote: > > Can you add docs and a test? monotone.texi for docs, tests/README for > > tests... > yes
Awesome, thanks. > [EMAIL PROTECTED] monotone restore_missing > [EMAIL PROTECTED] monotone restore_missing @var{pathname...} > + > +This command is a variant of "monotone revert" that will never change > +existing files but will restore files that are not present in the > +working copy. It will not restore files that have been dropped but > +restore files with the original name that were renamed but the file > +vanished. This last sentence is confusing; not sure what it means. I guess it's trying to explain: > +# if we drop testfile3 it will be restored as testfile2 > +AT_CHECK(rm testfile3) > + > +AT_CHECK(MONOTONE restore_missing, [], [ignore], [ignore]) > + > +NEW_2=`SHA1(testfile2)` > +AT_CHECK(test $NEW_2 = $BASE_2) This behavior seems strange to me. So if I have a file 'foo', and I rename it to 'bar', and then accidentally delete it, and hit "restore_missing", shouldn't it re-appear as 'bar', not as 'foo'? I would certainly expect that after a 'restore_missing', then 'ls missing' would return nothing, but in this case it would say that 'bar' was missing. I'd also expect that 'restore_missing' would not create files that monotone did not expect to have exist (after all, how can they be missing if monotone thinks they don't exist?); the creation of 'foo' violates this as well... -- Nathaniel -- /* Tell the world that we're going to be the grim * reaper of innocent orphaned children. */ -- Linux kernel 2.4.5, main.c _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel