Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)

[Nathaniel Smith]

On Fri, Aug 25, 2006 at 09:18:01AM +0200, Christof Petig wrote:
> cvssync2 adds a file (called .mtn-sync-cvs which contains (more than) a
> table of ( revision[/keyword_substitution] path file_id ) per revision
> to store that information (easily delta encoded and distributed this way)).*

Would it make more sense to store these as attrs on each file,
instead of in file data?  cvs:revision or something?  Save on the
number of file formats that need inventing?

Is using file_id information to detect staleness of this information
dangerous?  I'm wondering what happens if someone does an edit,
commits it, then reverts the edit again and commits _that_, so the
file goes A -> B -> A ... it seems like an easy place to get confused,
and there are _already_ plenty sufficient places to get confused when
dealing with the mess that is cvs.

Another approach to handling staleness might be to have a cert that
says "the revision I am attached to has non-stale rcs version number
data in it".  You just put this on trees that have been synched into
cvs, and it's pretty easy to find the latest revision with such a
cert.  Then you don't really have to have the whole machinery for
figuring out which bits of data are stale, etc.?

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco