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

[Daniel Carosone]

On Tue, Mar 20, 2007 at 12:45:16AM -0700, Nathaniel Smith wrote:
>  The solution is to have some way to stick a cvs: attr
> on a file that means "this is _like_ <such-and-such cvs rev>, but
> different", and then take that into account when calculating sync
> info.  Current IIRC cvssync does this by, effectively, putting a
> cvs:revision attr on that claims the file _is_ in sync, but then
> putting a cvs:sha attr on that that does _not_ match the existing
> file, and then later noticing this weird state and treating it
> appropriately.  But we decided that a better way to do that would be
> to just have some magic in the cvs:revision field, like "revision=1.1"
> vs. "revision=1.1+" to indicate the special case.

I think you're overstating the issue.

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).

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.

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.

When you sync back with cvs, for each new monotone revision, you need
to push a new cvs revision. There might be several of these since you
last synced, and for each you'll create a new (direct) child with the
new attr value.  

You may or may not choose to name them explicitly as a side "cvs sync
branch", but the net effect in the DAG structure is a linear revision
history subgraph that directly maps to the cvs history, and
side-revisions that represent monotone's divergence and structure
beyond what cvs can see.

I think we maybe even drew pretty ascii (ahem) pictures of all this,
last time around...

--
Dan.

pgp0ofNuP7aMg.pgp
Description: PGP signature