Re: [Monotone-devel] Lack of conflicts checking

[Nathaniel Smith]

On Tue, Aug 07, 2007 at 10:17:57AM +1000, Brian May wrote:
> I really don't like this. In means if somebody accidently or
> deliberately deletes a file that shouldn't have been deleted, commits
> the result in the same branch, and then propagates the change, data
> may be lost. Consider for example if other people are working on the
> files which get deleted. When revisions are merged, the changes will
> be lost.

Don't worry, *no-one* likes it.  I absolutely hate it, and I'm the
one who built it this way.  It's just work to fix, because somehow you
have to track when deletes happened, *but* you need to do so in a way
that doesn't cause monotone's per-tree metadata to grow without bound
when people are doing repeated add/delete cycles.  (I.e., there are
workflows -- I think OpenEmbedded does this, actually -- where the
tree never gets bigger, but the number of deleted files grows without
bound, and we don't want to make common operations get arbitrarily
expensive because of this, just to support the important-but-rare
case of merging deletes and resurrections.)

-- Nathaniel

-- 
Eternity is very long, especially towards the end.
  -- Woody Allen