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 :-} _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
