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

[Daniel Carosone]

On Tue, Mar 20, 2007 at 08:49:28PM +1100, William Uther wrote:
> 
> 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.

Hmm..

I think the only time you care whether its in sync with cvs is the
next time you're syncing.  At that point, by definition, you can look
at the CVS HEAD as well.  So, you start with the monotone head you're
syncing with cvs, and enumerate all the files that have higher cvs
versions than the attr values carried forward from the last sync.

For all of those, you need to go back to the intervening versions
anyway - there might be multiple monotone changes, and you want to
sync each of them to cvs as individual commits (rather than one big
summary change). (Plus you need to add new files that lack attrs,
etc).

Perhaps we have different mental models in mind, but from this basis
I'm not sure I see the real benefit of the cert.  

Let's put it another way: when is it convenient to quickly know the
last "in sync" revision? is that still interesting if you don't know
the present cvs state because you're offline, or only looking at a
cert?

I suppose it might be good to know "you have local changes you haven't
sent to cvs", but I think by previous graph-structure argument, you
can see that from the DAG pretty readily, even if a cert adds some
convenience.

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

I'm not sure what you mean by "up to date" here.  By my definition,
the only thing that changes the attr is a cvs_sync.  It's a feature
that the attr's don't get changed when the content does, but do get
carried forward attached to the file, so long as you take the meaning
as "based upon" or "last synced with" rather than "in sync with".

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

It's more than that. We want to find the attr value in the current
revision, without having to walk back up to (possibly multiple,
complex strucutred, maybe ambiguous) ancestors.  All that ambiguity is
resolved via merging and conflict resolution on the way to the head
we're using to sync.

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

Yeah, but I think you're doing that work anyway, as above.

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

Don't you lose the cvs revision correspondence for all but the final
revision, so the attr might jump from 1.17 to 1.25 in one hit.  We can
debate whether that's anything of importance, but tell me what happens
when there are new revs in both CVS and monotone?  

In my model/suggestion from the previous discussion, the incoming revs
from CVS are just more divergence for monotone to handle -- so long as
they're attached against the right ancestors (the linear cvs
subhistory) for the merge algorithm to do its thing.  When such revs
come in, the implicit merge in cvs update you'd have to do before
committing a new CVS HEAD becomes an explcit merge in monotone before
(or maybe even during, especially if clean) cvs_sync.

--
Dan.

pgprBjUkmPLFe.pgp
Description: PGP signature