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

[William Uther]

On 20/03/2007, at 9:36 PM, Daniel Carosone wrote:

> 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

There is no such thing as "sync".  There is "push" and "pull".   
"pull" will attach all the stuff pulled to the last synced revision,  
not the head.  So in that case, I use the cert to _find_ the  
"monotone [revision] you're syncing with cvs".

For "push", I need to know which revs are not in CVS.  The current  
algorithm makes sure you are merged, then finds the last synced  
revision and commits to CVS all monotone revisions along one path to  
the head.

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

yup

> We can
> debate whether that's anything of importance, but tell me what happens
> when there are new revs in both CVS and monotone?

Then you first "pull" from CVS.  Then you merge.  Then you "push" to  
CVS.

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

Incoming from CVS just attach to the linear CVS sub-history.   
Outgoing to CVS need a new node.  If you have a whole sequence of  
outgoing nodes I didn't want to bother keeping track of them all.   
You could, and you'd end up with something that looked like a zipper- 
merge.  But I couldn't see a use case.  (I could probably invent some  
wacky use-case, but the point wasn't to be a perfect converter, it  
was to be 'good enough' for me to use ASAP.)

Be well,

Will          :-}