darcs

Issue 2382 Renaming directory into shadowed file gives bad error message

Title Renaming directory into shadowed file gives bad error message
Priority Status unknown
Milestone Resolved in
Superseder Nosy List owst
Assigned To
Topics

Created on 2014-04-27.20:43:19 by owst, last changed 2014-04-27.21:32:18 by bf.

Messages
msg17400 (view) Author: owst Date: 2014-04-27.20:43:17
1. Summarise the issue (what were doing, what went wrong?)

Imagine a user does this:

# foo is recorded as a file 
$ rm foo
$ mkdir foo
$ darcs wh

Darcs currently fails with:

    openBinaryFile: inappropriate type (is a directory)

Although this is the fault of the user, we could be more useful here.

2. What behaviour were you expecting instead?

Well, the user has presented quite a tricky situation for darcs.
I think it's best to warn the user that something weird will happen.

I'd like darcs to say something like:

The recorded file, foo has been deleted and replaced by a directory.
If this was not intended, rename the directory foo in the working
directory, 
and use `darcs revert' to recover the recorded version of the file.

when the users asks whatsnew, and before record.

If a patch is recorded, it should act as if file removal was recorded
and (non-recursively) the directory was added. The user should be able
to explicitly `darcs add` any contents of the directory.

Alternatively, darcs could refuse to do anything until the directory has
been renamed away, but with a nicer error message than is currently
given, something like:

the working directory is inconsistent with the repository state.
foo was recorded as a file, but is now a directory, please rename
this directory to allow darcs to continue.
msg17401 (view) Author: owst Date: 2014-04-27.20:57:07
Discussion on IRC: http://irclog.perlgeek.de/darcs/2014-04-27#i_8645442

The summary is: e'd like the behawviour to be that whatsnew just shows
foo as a hunk/rmfile foo. whatsnew --look-for-adds could also show foo
as a new directory
msg17402 (view) Author: bf Date: 2014-04-27.21:32:17
See also issue2378.
History
Date User Action Args
2014-04-27 20:43:19owstcreate
2014-04-27 20:57:08owstsetmessages: + msg17401
2014-04-27 21:32:18bfsetmessages: + msg17402