--- On Thu, 7/6/12, Markus Wanner <[email protected]> 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 ?
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.