Re: Updated Issue 209 - support drop/modified conflict

> [Stephen Leake]:
> Since the current behavior is not what I want, I think it
> should be a
> conflict, so the user can choose the current behavior (the
> 'drop'
> resolution to the conflict), or something else (the 'keep'
> or 'user'
> resolution to the conflict).
> 
> The reason I don't like the current behavior is that
> sometimes the drop
> was a mistake, and it needs to be corrected; the easiest way
> to bring
> that to the user's attention is via a merge conflict.
> 
> I'm assuming I'm not the only user with this issue.

Agree.  I remember wanting to be notified properly with a conflict when I first ran into this.

> > [Markus Wanner]:
> > IMO die-die-die works better for "well-managed"
> projects. The policy is
> > simple: never delete something you might want to revert
> someday.
> 
> [Stephen Leake]:
> Well, yes. But I'd call that "perfectly managed" :). And it
> requires
> perfect foresight. People are not perfect, so we need some
> recovery.
> 

Agree with both here.  Even though I now try and remember that a file is born, lives, and once dead is gone forever, I still make mistakes.  It also makes mixing projects with merge_into_dir awkward (but that's for another discussion).