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