You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2000/12/14 11:44:26 UTC
update processing
I posited the other day, that the comments in svn_ra.h about a "two step"
update process were probably incorrect -- that we should be able to
streamily send "current state" to the server and perform the update/fetch at
the same time. (rather than wait for close_edit from the current state
processing)
After some pondering... nope. I'm quite wrong on that one.
The simplest test case is a directory at v5. On the server, it is v6. When
we send the directory info to the server, what should the server do?
*) It can certainly say "the directory is out of date, so fetch it"
*) It can't say anything about the contained files. The server doesn't know
if we're about to sending state info saying that all the files are at v6,
or possibly some mix of v5/v6 files.
*) The contained files can only be reported when a "close directory" occurs.
Depending on the communication between the client and server, this event
may or may not be transmitted:
a) We send multiple requests to the server about each of the pieces of
state on the client.
Given HTTP's stateless nature, this implies that we cannot have a "dir
open" and "dir close" pair of methods. Therefore, no "close dir" ever
occurs in this model.
b) We send one big mother request about the client state.
This corresponds to the "close_edit" strategy that Ben mentions in
svn_ra.h.
Model (a) has some serious problems. If we are sending information requests
only for a subset of the working copy (e.g. Dir1 is v5, File5 is v6, but we
say nothing about File1..4 because they are also v5), then how do we get the
proper info for File1..4? Each request (dir or file) has one of three
responses:
1) the file/dir is up to date
2) the file/dir is an older revision, but the latest revision is exactly
the same (update the metadata, but not the content)
3) the file/dir is an older revision and needs to be updated
What model (a) boils down to is sending a PROPFIND request for each
directory in the working copy. The PROPFIND would report on the current
state of each child, and the client would then sort out what to do.
There is no specific DAV mechanism for model (b), although we can easily use
a Subversion-specific "report" to do this. The server will have much more
work because it is going to need to sort out the Mother Request and report
on all the updates. There is also a latency issue: we must wait until the
client has generated the complete request, and the server must generate the
report containing the update info. (the client then issues additional
requests to fetch content/properties)
Model (a) is similar to the checkout process (a series of PROPFINDs followed
by GETs). Model (b) is a big hunka hunka server work.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: update processing
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
> The body isn't a "tree delta" and pretending it is some variant does a
> disservice. The body is simply reporting local state, not a difference. The
> request is going to be a WebDAV REPORT request, and we should try to make it
> as generic as possible. Hell, it is already going to lock the
> client and server together
What do you mean by "lock the client and server together"?
Re: update processing
Posted by Ben Collins-Sussman <su...@newton.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Note ... I think we might want to re-introduce libsvn_svr as a utility
> layer over the FS. That layer would share some funcs between mod_dav_svn and
> libsvn_ra_local. I'm not sure what it would do (we'd need to start ra_local
> to really tell), but we've got the concept there...
Hmmm, yeah, I know where you're coming from.
The original point of libsvn_svr was to provide:
* broad access-control policies to the repository
* a system of mapping multiple users and authentication methods to
a *single* filesystem user. (i.e. if an FS node has an ACL
describing what user "jimb" can or can't do, how do we know that
that "jimb@red-bean.com/ssh" is the same person as
"jimb@redhat.com/kerberos"?)
The layer was thrown out because we decided that Apache could
essentially do these things.
But now it seems that libsvn_ra_local will *lack* the ability to do
these things!
Re: update processing
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Dec 17, 2000 at 02:29:44AM +0100, Branko Cibej wrote:
> Ben Collins-Sussman wrote:
> > The only appeal of this model was it's symmetric niftiness, I suppose.
> > That, and the fact that there would be a lot of shared code on the
> > filesystem side. In the current situation, libsvn_ra_local needs to
> > learn to drive the filesystem API for it's own specific needs -- it
> > probably can't just duplicate code out of libsvn_ra_dav. And I'm
> > guessing the filesystem API is a bit hairier than the editor API.
>
> Libsvn_ra_dav doesn't touch the filesystem API at all; it's on the wrong
> side of the network connection, with mod_dav_svn on the other side.
Right!
> Libsvn_ra_local and mod_dav_svn should share the bits for accessing the
> filesystem. Maybe mod_dav_svn could live on top of libsvn_ra_local once
> it's implemented, and ra_local would become the "real" public filesystem
> API. Whether that makes sense for mod_dav_svn, I have no idea; GregS can
> answer that one, no doubt.
Nah... that would actually suck :-)
The basic problem is that the editor interface is *very* stateful. You have
batons flying everywhere. On the other hand, server requests (HTTP and DAV)
are effectively stateless. Whoop... where's the root_baton?! Furg.
So, no... we actually want to avoid the editor interface between mod_dav_svn
and the FS API.
> > But practicality is important, too. It's no big deal. :)
>
> Decoupling mod_dav_svn from libsvn_fs would be practical, too. :-)
Gah. mod_dav has a pluggable back-end. mod_dav_svn is all about plugging
mod_dav into the FS. We certainly don't need to abstract anything on the
DAV/server side. But the question probably revolves more around the coupling
with the FS interface... On that side, we should be able to find some common
stuff to share [with the ra_local mechanism].
Note ... I think we might want to re-introduce libsvn_svr as a utility
layer over the FS. That layer would share some funcs between mod_dav_svn and
libsvn_ra_local. I'm not sure what it would do (we'd need to start ra_local
to really tell), but we've got the concept there...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: update processing
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> The only appeal of this model was it's symmetric niftiness, I suppose.
> That, and the fact that there would be a lot of shared code on the
> filesystem side. In the current situation, libsvn_ra_local needs to
> learn to drive the filesystem API for it's own specific needs -- it
> probably can't just duplicate code out of libsvn_ra_dav. And I'm
> guessing the filesystem API is a bit hairier than the editor API.
Libsvn_ra_dav doesn't touch the filesystem API at all; it's on the wrong
side of the network connection, with mod_dav_svn on the other side.
Libsvn_ra_local and mod_dav_svn should share the bits for accessing the
filesystem. Maybe mod_dav_svn could live on top of libsvn_ra_local once
it's implemented, and ra_local would become the "real" public filesystem
API. Whether that makes sense for mod_dav_svn, I have no idea; GregS can
answer that one, no doubt.
> But practicality is important, too. It's no big deal. :)
Decoupling mod_dav_svn from libsvn_fs would be practical, too. :-)
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: update processing
Posted by Ben Collins-Sussman <su...@newton.collab.net>.
Jim Blandy <ji...@zwingli.cygnus.com> writes:
> > Huh? Doesn't the FS provide an editor for committing transactions?
> > And doesn't the FS drive an editor for updating a working copy? I
> > thought this was a basic part of the design.
>
> The FS interface is less restrictive. It provides functions which
> make it very easy to write editors, but don't actually require a
> depth-first traversal.
OK: so let me see if I understand.
* The filesystem currently has nothing whatsoever to do with editors;
it neither provides one nor drives one.
* libsvn_ra_dav *both* provides and drives an editor when talking to
libsvn_client, but with the filesystem it speaks directly.
* libsvn_ra_local, when it's eventually written, will similarly need
to both provide and drive an editor on the client side, and speak
the filesystem API directly.
I guess this makes sense, but it kind of blows a hole in the
idealistic vision we had that the "client and server can be directly
linked together." Once upon a time, we assumed that this was the
case; that each half could just magically "connect" using editors, and
that there'd be no way to detect that the network layer was in the
middle, because it too was using editors on both ends.
The only appeal of this model was it's symmetric niftiness, I suppose.
That, and the fact that there would be a lot of shared code on the
filesystem side. In the current situation, libsvn_ra_local needs to
learn to drive the filesystem API for it's own specific needs -- it
probably can't just duplicate code out of libsvn_ra_dav. And I'm
guessing the filesystem API is a bit hairier than the editor API.
But practicality is important, too. It's no big deal. :)
Re: update processing
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Ben Collins-Sussman <su...@newton.collab.net> writes:
>
> Greg Stein <gs...@lyra.org> writes:
>
> > The tree-delta XML DTD != using the delta editor. You can use one without
> > the other. I just suggested a different XML format; who said I wasn't going
> > to use the delta editor? :-) :-)
>
> Ohhhhhhhhhhhhhhhhhhh. :-)
>
>
> > Actually, the FS layer doesn't use the editor interface. There is going to
> > be some glue (in ra_local) when you link them together.
>
> Huh? Doesn't the FS provide an editor for committing transactions?
> And doesn't the FS drive an editor for updating a working copy? I
> thought this was a basic part of the design.
The FS interface is less restrictive. It provides functions which
make it very easy to write editors, but don't actually require a
depth-first traversal.
Re: update processing
Posted by Ben Collins-Sussman <su...@newton.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> > Oh, well... right, as long as there's an editor *somewhere* that can
> > drive the filesystem API -- sure.
>
> Yup. That guy would live somewhere in libsvn_ra_local, I presume.
>
That makes sense.
* libsvn_client sends commits by driving this editor.
* when libsvn_client wants to update, it drives a second editor to
describe working copy state, and provides an editor to update the
working copy in return.
What's important here, as Karl said, is that both of those editors
above are *also* available in libsvn_ra_dav. libsvn_client should
have no clue as to whether the repository is local or remote; it's all
the same interface specified in svn_ra.h. (If you can generate your
own XML "report" format over the wire, all the power to you!) :)
Re: update processing
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 15, 2000 at 05:28:01PM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gs...@lyra.org> writes:
>
> > *was* being the key word :-)
> >
> > Nowadays, the FS is much more like a random access filesystem, than an
> > editor. (which is totally fine by me since it matches the semantics that I'm
> > looking for; I think it also works better for Jim)
> >
> > The glue would supply the appropriate editors and just call into the FS. Not
> > a big problem, I'd think.
>
> Oh, well... right, as long as there's an editor *somewhere* that can
> drive the filesystem API -- sure.
Yup. That guy would live somewhere in libsvn_ra_local, I presume.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: update processing
Posted by Ben Collins-Sussman <su...@newton.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> *was* being the key word :-)
>
> Nowadays, the FS is much more like a random access filesystem, than an
> editor. (which is totally fine by me since it matches the semantics that I'm
> looking for; I think it also works better for Jim)
>
> The glue would supply the appropriate editors and just call into the FS. Not
> a big problem, I'd think.
Oh, well... right, as long as there's an editor *somewhere* that can
drive the filesystem API -- sure. I never expected the filesystem API
to be "exactly equal to" the editor interface!
Re: update processing
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 15, 2000 at 04:37:11PM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gs...@lyra.org> writes:
>...
> > Actually, the FS layer doesn't use the editor interface. There is going to
> > be some glue (in ra_local) when you link them together.
>
> Huh? Doesn't the FS provide an editor for committing transactions?
> And doesn't the FS drive an editor for updating a working copy? I
> thought this was a basic part of the design.
*was* being the key word :-)
Nowadays, the FS is much more like a random access filesystem, than an
editor. (which is totally fine by me since it matches the semantics that I'm
looking for; I think it also works better for Jim)
The glue would supply the appropriate editors and just call into the FS. Not
a big problem, I'd think.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: update processing
Posted by Ben Collins-Sussman <su...@newton.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> The tree-delta XML DTD != using the delta editor. You can use one without
> the other. I just suggested a different XML format; who said I wasn't going
> to use the delta editor? :-) :-)
Ohhhhhhhhhhhhhhhhhhh. :-)
> Actually, the FS layer doesn't use the editor interface. There is going to
> be some glue (in ra_local) when you link them together.
Huh? Doesn't the FS provide an editor for committing transactions?
And doesn't the FS drive an editor for updating a working copy? I
thought this was a basic part of the design.
Re: update processing
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 15, 2000 at 11:48:52AM -0600, Karl Fogel wrote:
> Greg, hmmm... let me ask a possibly indelicate question. :-)
hehe... no such thing.
> Are you against using the delta editor mechanism to report working
> copy state because you feel that mechanism is inherently
> inappropriate, or because it doesn't map well to the DAV protocol?
You and Ben made an incorrect assumption :-)
The tree-delta XML DTD != using the delta editor. You can use one without
the other. I just suggested a different XML format; who said I wasn't going
to use the delta editor? :-) :-)
> If the former, I confess that my instincts run completely the other
> way: it's hard for me to imagine a *more* appropriate mechanism. I
> mean, the working copy has to report its state precisely because that
> state differs from a given pristine version tree (otherwise, it'd just
> report a version number and be done with it). And what's a good
> mechanism for streamily reporting a delta against a base tree, even a
> delta that consists entirely of ancestry differences? Sounds like
> `svn_delta_edit_fns_t' to me. :-)
It is. I'm just going to construct XML that is more tuned to the actual
problem semantics: reporting versions. The notion of "add/replace" is not
meaningful in this context.
> But if the latter, hmmm, I'm not sure what to say, then. I think we
> all agree that the network layer's semantics shouldn't perturb the
> rest of Subversion (at least, that was one of the assumptions we
> started out with).
Agreed. My intent is to working *within* the Subversion model. The state
reporting does not map to available WebDAV functionality, but there is a
"framework" for it (the REPORT method). So, I'm mapping to REPORT rather
than pushing back on the SVN model.
[ WebDAV does have something close for this, called "baselines", but it
means recording the client state on the server. We don't want that :-) ]
> Imagine that the working copy and repository fs
> layer were linked directly together, same memory space and all that:
> in that case, there can be little doubt that the best way for them to
> talk to each other would be by swapping editors, each driving the
> other's. It's just so natural -- how could anything that feels so
> good be wrong? :-)
Actually, the FS layer doesn't use the editor interface. There is going to
be some glue (in ra_local) when you link them together.
But this point is somewhat moot at the moment... we were talking about the
XML that goes over the wire.
> The network layer shouldn't change this model, it should just make it
> happen over the wire, when the memory spaces aren't shared. In fact,
> we've always assumed that working copies and repositories don't even
> *know* whether a given transaction is happening over a network or
> locally. If DAV semantics start flowing down into those libraries,
> there'll be no end of trouble, I think.
Agreed.
> So if the problem is a paradigm mismatch between DAV and
> svn_delta_edit_fns_t, let's talk about it in those terms and see if
> there isn't some way to make it work...
No mismatch. You guys just assumed that "different XML" meant "not the delta
editor". Tsk tsk. :-) :-)
Cheers,
-g
>
> ?,
> -K
>
> Ben Collins-Sussman <su...@newton.collab.net> writes:
> > Greg Stein <gs...@lyra.org> writes:
> >
> > > The body isn't a "tree delta" and pretending it is some variant does
> > > a disservice. The body is simply reporting local state, not a
> > > difference.
> >
> > You sound like Karl, about 4 months ago. :)
> >
> > Why are "reporting local state" and "tree diff" mutually exclusive
> > concepts? The idea here is that one can express a working copy's
> > state *as* a difference against some pristine tree. Just because
> > we're omitting text-deltas doesn't mean it's still not a legitmate
> > tree-delta. There's no dishonest twisting of semantics going on.
> >
> > The reason why we liked this idea is that it allows us to use the
> > existing "editor" interface, rather than coming up with a whole new
> > system of describing a working copy.
> >
> > Also: it's more efficient than explicitly listing each and every
> > revision number in the working copy. If a working-copy resource is
> > the same revision number as the root dir, we don't report it at all.
--
Greg Stein, http://www.lyra.org/
Re: update processing
Posted by Karl Fogel <kf...@galois.collab.net>.
Greg, hmmm... let me ask a possibly indelicate question. :-)
Are you against using the delta editor mechanism to report working
copy state because you feel that mechanism is inherently
inappropriate, or because it doesn't map well to the DAV protocol?
If the former, I confess that my instincts run completely the other
way: it's hard for me to imagine a *more* appropriate mechanism. I
mean, the working copy has to report its state precisely because that
state differs from a given pristine version tree (otherwise, it'd just
report a version number and be done with it). And what's a good
mechanism for streamily reporting a delta against a base tree, even a
delta that consists entirely of ancestry differences? Sounds like
`svn_delta_edit_fns_t' to me. :-)
But if the latter, hmmm, I'm not sure what to say, then. I think we
all agree that the network layer's semantics shouldn't perturb the
rest of Subversion (at least, that was one of the assumptions we
started out with). Imagine that the working copy and repository fs
layer were linked directly together, same memory space and all that:
in that case, there can be little doubt that the best way for them to
talk to each other would be by swapping editors, each driving the
other's. It's just so natural -- how could anything that feels so
good be wrong? :-)
The network layer shouldn't change this model, it should just make it
happen over the wire, when the memory spaces aren't shared. In fact,
we've always assumed that working copies and repositories don't even
*know* whether a given transaction is happening over a network or
locally. If DAV semantics start flowing down into those libraries,
there'll be no end of trouble, I think.
So if the problem is a paradigm mismatch between DAV and
svn_delta_edit_fns_t, let's talk about it in those terms and see if
there isn't some way to make it work...
?,
-K
Ben Collins-Sussman <su...@newton.collab.net> writes:
> Greg Stein <gs...@lyra.org> writes:
>
> > The body isn't a "tree delta" and pretending it is some variant does
> > a disservice. The body is simply reporting local state, not a
> > difference.
>
> You sound like Karl, about 4 months ago. :)
>
> Why are "reporting local state" and "tree diff" mutually exclusive
> concepts? The idea here is that one can express a working copy's
> state *as* a difference against some pristine tree. Just because
> we're omitting text-deltas doesn't mean it's still not a legitmate
> tree-delta. There's no dishonest twisting of semantics going on.
>
> The reason why we liked this idea is that it allows us to use the
> existing "editor" interface, rather than coming up with a whole new
> system of describing a working copy.
>
> Also: it's more efficient than explicitly listing each and every
> revision number in the working copy. If a working-copy resource is
> the same revision number as the root dir, we don't report it at all.
Re: update processing
Posted by Ben Collins-Sussman <su...@newton.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> The body isn't a "tree delta" and pretending it is some variant does
> a disservice. The body is simply reporting local state, not a
> difference.
You sound like Karl, about 4 months ago. :)
Why are "reporting local state" and "tree diff" mutually exclusive
concepts? The idea here is that one can express a working copy's
state *as* a difference against some pristine tree. Just because
we're omitting text-deltas doesn't mean it's still not a legitmate
tree-delta. There's no dishonest twisting of semantics going on.
The reason why we liked this idea is that it allows us to use the
existing "editor" interface, rather than coming up with a whole new
system of describing a working copy.
Also: it's more efficient than explicitly listing each and every
revision number in the working copy. If a working-copy resource is
the same revision number as the root dir, we don't report it at all.
Re: update processing
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Dec 14, 2000 at 09:38:48AM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gs...@lyra.org> writes:
>
> > b) We send one big mother request about the client state.
> >
> > This corresponds to the "close_edit" strategy that Ben mentions in
> > svn_ra.h.
>
> Indeed, this is the only real thing we can do, and it's a big "hunka"
> server work, as you said. Specifically, it's a big hunka filesystem
> work.
>
> The client sends a tree-delta devoid of text-deltas; this tree-delta
> gives a root revision #, and then "replaces" any file or dir which is
> at a *different* revision #.
>
> The filesystem then builds a mini-node-tree, floating in space, which
> is a model of the working copy. The filesystem then compares this
> tree to the "head" tree, and sends back a custom tree-delta.
>
> Does everyone agree on this model now?
Nope :-)
The body isn't a "tree delta" and pretending it is some variant does a
disservice. The body is simply reporting local state, not a difference. The
request is going to be a WebDAV REPORT request, and we should try to make it
as generic as possible. Hell, it is already going to lock the client and
server together :-(, so I'd rather not code it too strongly to SVN.
The request is going to look something like:
REPORT /repos/myproj HTTP/1.1
Host: www.lyra.org
Content-Type: text/xml; charset="utf-8"
Transfer-Encoding: chunked
<?xml version="1.0" encoding="utf-8"?>
<update-status-report xmlns="http://subversion..." xmlns:D="DAV:">
<directory name="/" ver="8">
<file name="foo.c" ver="7"/>
<file name="bar.h" ver="7"/>
<directory name="subdir" ver="8">
<file name="baz.c" ver="6"/>
<directory name="sub2" ver="7">
</directory>
</directory>
</directory>
</update-status-report>
After pondering on the problem today (while running errands and whatnot),
the server isn't going to have too hard of a time to figure out what is
going on. Recall that server doesn't need to come up with diffs while
processing the REPORT (because the changes need to be fetched separately
using GET and PROPFIND methods). It only needs to resolve each resource as
being in one of three states:
1) the client has the latest revision of the resource
2) the client has an older revision, but no actual changes were made between
the older revision and the latest
3) the client has an older revision and must fetch some changes
[ where changes can be content or properties ]
For each resource, mod_dav_svn (or a utility function in FS) will do:
Step 1: if the client revision == latest revision, then the resource is in
state #1 (and stop)
Step 2: fetch the node ID for the client's file/revision, and fetch the node
ID for the latest file/revision.
Step 3: if the node IDs are the same, the resource is in state #2;
else it is in state #3
These states are reported back to the client, along with the necessary URLs
for fetching updates.
Step (2) could be simplified if the client supplies the node ID in the
request (that it stored/cached at fetch time). That means the server only
needs to open the "latest" revision tree to look up node IDs.
The client receives the report and does one of three things, according to
the state of the resource:
1) do nothing
2) record the new version URL, but don't fetch anything
3) fetch new content and/or properties [the report will probably want to
indicate, in some way, which or both of these aspects to fetch]
Note that the report may contain information about resources that weren't in
the original request. In the example above, "/" is an older revision and
(implicitly) its contained files are older, too (unless otherwise
specified). The REPORT response will contain information about each of those
contained files.
[ oh. there will need to be some kind of response state that says "that
resource was deleted". dunno if "add" is anything beyond reporting a
resource that the client hasn't seen before. ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: update processing
Posted by Ben Collins-Sussman <su...@newton.collab.net>.
Jim Blandy <ji...@zwingli.cygnus.com> writes:
> I think this can be done by beginning a transaction based on the
> working directory's root revision, opening nodes from various other
> revisions and plunking them into place with svn_fs_copy (which won't
> actually do any copying), calling `svn_fs_dir_delta' to get the delta,
> and then calling `svn_fs_abort_txn' to throw away the copy of the
> working directory's base tree.
Exactly!
Re: update processing
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
> The client sends a tree-delta devoid of text-deltas; this tree-delta
> gives a root revision #, and then "replaces" any file or dir which is
> at a *different* revision #.
>
> The filesystem then builds a mini-node-tree, floating in space, which
> is a model of the working copy. The filesystem then compares this
> tree to the "head" tree, and sends back a custom tree-delta.
I think this can be done by beginning a transaction based on the
working directory's root revision, opening nodes from various other
revisions and plunking them into place with svn_fs_copy (which won't
actually do any copying), calling `svn_fs_dir_delta' to get the delta,
and then calling `svn_fs_abort_txn' to throw away the copy of the
working directory's base tree.
Re: update processing
Posted by Karl Fogel <kf...@galois.collab.net>.
Jim Blandy <ji...@zwingli.cygnus.com> writes:
> Not having actually written code to do this, it doesn't sound too hard
> at all. It maps directly onto the semantics of the operations we have
> now.
Oh, I just meant it's a hunk of work for the fs to do at run time, not
a hunk of work for someone to implement.
It's basically "Build the tree, never link it into the revision table,
walk along it comparing against whatever, and garbage collect it when
done", right?
Re: update processing
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Karl Fogel <kf...@galois.collab.net> writes:
>
> Ben Collins-Sussman <su...@newton.collab.net> writes:
> > Indeed, this is the only real thing we can do, and it's a big "hunka"
> > server work, as you said. Specifically, it's a big hunka filesystem
> > work.
> >
> > The client sends a tree-delta devoid of text-deltas; this tree-delta
> > gives a root revision #, and then "replaces" any file or dir which is
> > at a *different* revision #.
> >
> > The filesystem then builds a mini-node-tree, floating in space, which
> > is a model of the working copy. The filesystem then compares this
> > tree to the "head" tree, and sends back a custom tree-delta.
> >
> > Does everyone agree on this model now?
>
> Yep.
>
> It is a hunk of work for the repository, but it has the advantage of
> being extremely comprehensible for the humans who will have to work
> with it. Anyway, I can't think of another way to do it, though that
> might just be because I'm a human. :-)
Not having actually written code to do this, it doesn't sound too hard
at all. It maps directly onto the semantics of the operations we have
now.
Re: update processing
Posted by Karl Fogel <kf...@galois.collab.net>.
Ben Collins-Sussman <su...@newton.collab.net> writes:
> Indeed, this is the only real thing we can do, and it's a big "hunka"
> server work, as you said. Specifically, it's a big hunka filesystem
> work.
>
> The client sends a tree-delta devoid of text-deltas; this tree-delta
> gives a root revision #, and then "replaces" any file or dir which is
> at a *different* revision #.
>
> The filesystem then builds a mini-node-tree, floating in space, which
> is a model of the working copy. The filesystem then compares this
> tree to the "head" tree, and sends back a custom tree-delta.
>
> Does everyone agree on this model now?
Yep.
It is a hunk of work for the repository, but it has the advantage of
being extremely comprehensible for the humans who will have to work
with it. Anyway, I can't think of another way to do it, though that
might just be because I'm a human. :-)
Re: update processing
Posted by Ben Collins-Sussman <su...@newton.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> b) We send one big mother request about the client state.
>
> This corresponds to the "close_edit" strategy that Ben mentions in
> svn_ra.h.
Indeed, this is the only real thing we can do, and it's a big "hunka"
server work, as you said. Specifically, it's a big hunka filesystem
work.
The client sends a tree-delta devoid of text-deltas; this tree-delta
gives a root revision #, and then "replaces" any file or dir which is
at a *different* revision #.
The filesystem then builds a mini-node-tree, floating in space, which
is a model of the working copy. The filesystem then compares this
tree to the "head" tree, and sends back a custom tree-delta.
Does everyone agree on this model now?