|
From: | William Uther |
Subject: | Re: [Monotone-devel] New cvssync.attrs branch |
Date: | Tue, 20 Mar 2007 22:30:34 +1100 |
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 thenew 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 :-}
[Prev in Thread] | Current Thread | [Next in Thread] |