Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict

[richhguard-monotone]

--- On Thu, 7/6/12, Markus Wanner <address@hidden> wrote:

> However, another perfectly valid use case is wanting to
> permanently
> delete a file in a child branch, which might continue to get
> modified in
> the parent branch. You'd not want that to conflict every
> time you
> propagate, do you? (The warning is annoying enough,
> already).

Agree here too, the trouble is knowing which method you want and when monotone 
should apply it.  In my own projects I also agree with your earlier sentiment 
about die-die-die 

"the policy is simple, don't delete anything..."

so I make use of the "Attic" directory workaround.

> However, I'm concerned about how to expose these two kinds
> of deletes to
> the user. I don't expect the average user to be able to
> understand the
> difference. Certainly not at the point in time of the
> delete. Maybe at
> the point in time of a merge (which currently emits the
> warning).

A big reason I use monotone is it offers a simple interface and keeps track of 
things for me (I'm stupid, clumsy and forgetful): it shows me exactly what went 
in, and uses only that exact info to calculate further info. ie. merging, 
renames, file/directory conflicts, etc

> Maybe, the user even wants different revisions to merge
> differently for
> the same deleted file. So it's not a property of the delete,
> but... of
> what else?
> 

Good point, or even 2 users with conflicting merge ideas: 1 says drop, 1 says 
keep.

I'm worried that the cure will be worse than the disease.  Also in terms of 
backwards compatibility will we need to migrate existing databases and change 
existing merges.  Is it compatible to go in our 1.x line as it changes/replaces 
die-die-die or should it go in a 2.x line ?