Greg Stein <gstein@lyra.org> writes:
> > So ra will need to make two editors available for driving: one for
> > reporting a skelta to the repository, and one for committing.
>
> Why? I don't understand what the first step is accomplishing. Are you
> talking about doing a "preflight" to see if the all of the changed files are
> current or something?
>
> But we took care of that with the postfix delta. We can walk the tree,
> fetch version numbers and compare them, and after all that, then we upload
> the actual changes and commit them.
>
> Why two steps?
Oh -- misunderstanding here. There aren't two steps for committing.
When we commit, we simply send local mods to the editor. That's it,
end of story. As you said above, the repository can reject us at any
point, *before* we send all the postfix text-deltas.
The "new" crawler algorithm that I'm talking about is for *updates*.
When we want the repository to update our working copy, we first need
to tell the repository what our working copy looks like. Then the
respository sends a custom update, patching exactly whatever is needed
to make the working copy resemble a pristine tree.
So the "new" crawler doesn't report local mods at all. Instead, it
looks at the revision number of the working copy's root directory.
Then it crawls the working copy and reports only those files and dirs
whose revision numbers are *different*.
(Of course, there are other ways to do this. Once upon a time we had
odd visions of special data structures that allowed us to send a
"list" of all working copy revision numbers. But it turns out that
you can give the repository a complete description by driving an
editor in this particular way. It's less network traffic too.)
Received on Sat Oct 21 14:36:15 2006