mkdir a && cd a
darcs init
cd ../
mkdir b && cd b
darcs get ../a
cd ../a
echo foo > f
darcs record
cd ../b/a
echo bar > f
darcs pull
cat f

outputs foo! our unrecorded work on f is lost!

I can confirm that this happens.  Here is a slightly simplified version.

mkdir a && cd a && darcs init && cd ..
darcs get a b

cd a
echo foo > f
darcs record -a -m 'foo > f' --author=moi
cd ..

cd b
echo bar > f
darcs pull -a
cat f

This (luckily) seems to be just a mundane, almost UI issue; file f has
not yet been added, so darcs cannot know it should do something with it.
But it seems like when we're in the working directory, we should detect
addfiles or moves that overwrite some pre-existing file.  Would the
right solution consist of moving the pre-existing file away?

If the files _is_ managed by darcs, and contains unrecorded changes, darcs
merges these with the pull (or does conflict markup). So perhaps it would be
intuitive to consider an unmanaged file's content as unrecorded changes as soon
as the file is added "in the middle" of the pull, and merge or conflict markup it?

Tommy's solution sounds like the right thing to do. There is a practical problem
in the source code. 'apply' in PatchApply.lhs is stuck in the WritableDirectory
monad (defined in DarcsIO.lhs), while 'add_to_pending' and similar procedures
need IO.

A good thing with merging unmanaged files is that the clash is handled in a
way already familiar to a darcs user. A bad thing (besides being hard to
implement) is that it will always be a massive two entire files conflict,
and the unmanaged file part probably has nothing to do with the pulled file
part. When I think about it, the _only_ good thing is that the user
immediately will recognize what the problem is and know how to deal with
it, which might indeed be a rather good thing. But since it's an unrecorded
conflict, there is no easy way to back out. And there's also the problem
with a directory being "in the way".

Another idea is to simply let the pull fail with a complaint about the
blocking unmanaged file (or directory). Or interactively ask the user if to
replace it (or merge it).

Well, the more ideas we have the better gets the chance of the best one
being a truly good one...

The unstable branch now has a feature for backing up files in the working
directory before clobbering them.  That should solve the problem.

Tue Aug 21 07:19:42 CEST 2007  Eric Kow <eric.kow@loria.fr>
  * [issue319, issue440] Backup unmanged working dir files as needed.