Re: [Monotone-devel] New cvssync.attrs branch

[Nathaniel Smith]

On Tue, Mar 20, 2007 at 08:18:06PM +1100, Daniel Carosone wrote:
> From memory of the last time we discussed this, the attr doesn't
> *need* to say it's in sync at all.  The attr simply says the file is
> "based on" the named cvs version, much like the workspace old_revision
> indicates the content base for local changes.  We can infer the
> not-in-sync difference from the fact that the content hash is
> different than when the attr gained its current value (no need to
> store it again).

Read again -- the tricky thing about the 'takeover' case is that we
are creating a new tree from scratch, and setting the attr.  So
obviously, the file will have the same content as it did when the attr
gained its current value.  However, despite this, we still want to
treat this file as modified since the named cvs revision.  (Yes, this
is weird, staring at the use case for a bit might help.)

> I'm not even sure of the merit/need of a separate "is in sync" cert,
> other than general convenience; if an author is creating revisions
> with bad cvs-sync attr's, I'm not sure that's much different from any
> other bad changes they might publish, and you should stop trusting
> their certs.

The point of the "is in sync" cert is to reduce implicitness, and
magic.  One particular advantage of explicit and non-magic designs
that comes to mind is -- they are a lot easier to fix up by hand when
necessary.  If somehow you lost sync between monotone and cvs, and
wanted to fix it up by hand, it's much easier to imagine fiddling
with the attrs by hand, checking you got them right, and _then_
issuing a cert, as opposed to every time you touched an attr, that
implicitly marked this as a new sync point, possibly breaking things
even more...

(It does also help protect against someone who touches those values
accidentally, yes.  Or, say, if we decide that we don't need those
attrs anymore so we delete them all from head, and then realize we
were wrong, in one case we have lost sync and in the other cvssync can
trivially recover...)

> When you sync back with cvs, you can compare the diff monotone
> produces between the current content, and the content when the attr
> was last set, and the diff cvs produces between the current content
> and the version in the attr. They should be the same diff.

The diff monotone produces is not appropriate, because monotone knows
about renames.  For sync'ing with cvs, you want to pretty much ignore
such cleverness, and just compare manifest-to-manifest.

-- Nathaniel

-- 
Damn the Solar System.  Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
  -- Lord Jeffrey