monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: William Uther
Subject: Re: [Monotone-devel] New cvssync.attrs branch
Date: Tue, 20 Mar 2007 20:49:28 +1100


On 20/03/2007, at 8:18 PM, Daniel Carosone wrote:

I'm not even sure of the merit/need of a separate "is in sync" cert,
other than general convenience;

Um, when I want to find the most recently synced revision I don't want to have to check all files in each revision to check that they all match their corresponding cvs version. And then when one doesn't, do the same thing with the parent revisions... etc. Yuck.

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.

In general it isn't that someone is explicitly making bad attrs, it is that the attrs are getting out of sync naturally because the normal mtn tools don't keep them up to date. We could just stick them all in a cert on the revisions that were in sync, but we want the deltified storage you get from having them in 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.

Diffing an entire revision is much slower than checking a cert.

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.

Currently I just create one new mtn rev to hold the attrs after all the mtn revs have been pushed. It is easier and I don't think you lose anything of importance.

Be well,

Will          :-}





reply via email to

[Prev in Thread] Current Thread [Next in Thread]