Re: [Monotone-devel] [PATCH] "monotone restore_missing" incl. testcase/texi

[Nathaniel Smith]

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.

> address@hidden monotone restore_missing
> address@hidden 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