Re: [Monotone-devel] resolving name conflicts; file suturing vs drop

[Patrick Georgi]

Am Tue, 6 May 2008 19:54:19 +0200
schrieb Thomas Moschny <address@hidden>:
> The problem is, that the all deleted files will have to stay in the
> rosters forever. This is not so much a problem storage-wise, because
Couldn't resurrection be done with a revision item like

resurrect "original path"
from [ancestor rev]
as "new path"
with "content hash"
?

This way, the file would be "truly dead" inbetween (rev 5 in the
example below) and doesn't have to be kept in the roster. The
resurrected file would get the old node-id (not sure what should happen
with the birthmark).

To make this "safe" (so two revisions that resurrect the same file get
the same revision text - we do quite some ordering and checking in
the revision basic_io format, to ensure a well-defined format), this
could require that the ancestor rev is the one where the file was
deleted, but:

  0     file a exists
 / \
1   3   file a is changed (differently in both 1 and 3)
|   |
2   4   file a is deleted (both in 2 and 4)
 \ /
  5
  |
  6     file a is resurrected

Which version should mtn resurrect? (it could ask the user, but we
don't do that for other non-content issues, so what would be the
default?)


Regards,
Patrick