Greg Stein <gstein@lyra.org> writes:
> On Thu, Nov 30, 2000 at 05:01:25PM -0600, Ben Collins-Sussman wrote:
> >...
> > > + /* Ask the network layer to update a working copy from URL.
> > > +
> > > + The network layer returns a COMMIT_EDITOR and COMMIT_BATON to the
> > > + client; the client then uses it to transmit an empty tree-delta
> > > + to the repository which describes all revision numbers in the
> > > + working copy.
> > > +
> > > + There is one special property of the COMMIT_EDITOR: its
> > > + close_edit() function. When the client calls close_edit(), the
> > > + network layer then talks the repository and proceeds to use
> > > + UPDATE_EDITOR and UPDATE_BATON to patch the working copy!
> > > +
> > > + When the update_editor->close_edit() returns, then
> > > + commit_editor->close_edit() returns too. */
> > > svn_error_t *(*svn_ra_do_update) (void *session_baton,
> > > + svn_delta_edit_fns_t **commit_editor,
> > > + void **commit__baton,
> > > + svn_delta_edit_fns_t *update_editor,
> > > + void *update_baton,
> > > svn_string_t *URL);
>
> Per my previous note, I'm unclear on why *two* passes are needed. Why can't
> we fetch updates during the initial, version-reporting crawl?
>
Are you suggesting that each time the crawler reports a
revision-number to the COMMIT editor, that this editor then turn
around and immediately patch the a small part of working copy using
the UPDATE editor?
If so, it's a more rapid-fire model than we were expecting.
I think that Karl and I were assuming that somehow the repository
needs a picture of the *entire* working copy before it sends an custom
update. But maybe this is wrong. I need to wrap my brain around how
this might work. Hmmm.
Here's an imaginary dialogue between the client and repository. The
client is in double quotes, driving a COMMIT editor, and the server's
response is indented, driving the UPDATE editor. I'm assuming that
the filesystem is at version 9.
"My root dir is at revision 6".
--> REPLACE ROOT, VERSION 9.
"Replace subdir A"
--> REPLACE A
"Replace subdir B"
--> REPLACE B
"Replace file foo.c with revision 7."
--> REPLACE FOO.C: new version 9, here's the textdelta from 7->9.
"Close subdir B"
--> CLOSE B
"Replace subdir C with revision 8"
--> REPLACE C: new version 9, here's a tree-delta...
"Close subdir C"
--> CLOSE C
"Close subdir A"
--> CLOSE A
"Close root"
--> CLOSE ROOT.
Hmmm, something tells me this isn't right. Suppose that in going from
filesystem 8 to 9, somebody added a new file to subdir M, which is a
sibling subdir to A and B. The crawler doesn't even mention this
subdir, because it's at revision 6 (like the root). Yet somehow the
UPDATE editor will be told to REPLACE M and ADD FILE within? At what
point would this happen? As soon as the repository knows that the
working copy's root is at revision 6?
I think the problem here is that Karl and I (and maybe Jimb?)
envisioned the server building a complete mental "model" of the
working copy in its entirety -- indeed, I imagined the filesystem
actually building a detached "scratch" tree made of pointers to nodes
all over the filesystem's history. Then this "scratch" tree would be
compared to the filesystem's latest tree, and a genuine (custom)
tree-delta would be generated. The filesystem would then drive an
editor (back through the network) to update the working copy.
So I'm asking jimb now: is this the right concept? Is this how you
were planning to send out updates?
> I disagree with the term "commit" in the above API. We aren't committing
> anything; we're simply reporting version numbers. Yes, the RA layer might
> use the same editor, but I doubt the RA layer will (therefore, using the
> name "commit" will be confusing).
I agree. "commit" is misleading terminology. Let's kill it and use
another term. :)
>
> Note that the URL parameter is probably a little bogus. I'm guessing that
> that information will be within the session somehow. We also have the
> SVN/repository file to clue us in.
>
Yah, that makes sense.
Received on Sat Oct 21 14:36:15 2006