You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2003/11/13 07:34:24 UTC
Thoughts on the DAV MERGE request.
I was thinking about the MERGE request/response tonight, what it does,
how it has evolved over time, and I got to wondering if in the process
of some incremental evolution, the big picture was completely
lost. And I realize that if so, it's my own fault.
The point of the MERGE response is to tell the client what resources
changed as a result of the MERGE. For our purposes, that means
reporting all the items actually committed, not including bubble-up
directories.
Now, back in the day, this was done by calling svn_fs_dir_delta() and
driving an editor between the two revisions. The editor would keep
track of, for example, if a directory was really changed (i.e., did it
get propchanges) or if it was just an intermediate step toward some
other real change. And the result was this nice XML list of changed
things.
Along came the "changes" table, and svn_repos_replay(). Now we have a
more reliable -- and much faster -- way to drive our editor, which we
don't even have to change to make it work with its new driver. Bonus!
But tonight I had one of those moments.
It's kinda like when your i486's hard drive goes out. And you're
bummed, right? Then you win a screaming 2-GHz Athlon machine with all
the goodies, and you're so excited because you finally have a new
harddrive you can rip out and use to fix your i486. About the middle
of the next week, it hits you.
Yeah, one of those moments.
So now I'm wondering -- why are we using an editor at all for MERGE
handling? The whole point of svn_repos_replay() is to take a set of
known paths and drive an editor with them -- in other words, to take a
flat dataset and give you nice path-based heirarchy. But all the
MERGE editor does is flatten that stuff back out into a list of
resources, which I'm pretty sure is just the list of paths that we got
from the "changes" table in the first place.
I'm gonna spend a little time trying to cut out the middle m[ae]n
here. And if it all works out, then my apologies to those who have
suffered MERGE timeouts as a result.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts on the DAV MERGE request.
Posted by kf...@collab.net.
Greg Stein <gs...@collab.net> writes:
> Right. That is the definition / process for MERGE.
>
> *However* ... we disabled that walk some time ago. It was creating an O(n)
> behavior for commits. For regular DeltaV clients, they'll get a "proper"
> MERGE response. The SVN client tells the server "don't bother. I already
> know the changed resources."
>
> See the 'disable_merge_response' variable in merge.c
Surely we still have O(n) behavior for commits, though :-). (Would be
impressive, not to say astonishing, if we didn't...)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts on the DAV MERGE request.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2003-11-13 at 10:13, C. Michael Pilato wrote:
> /* If the caller didn't give us any way of storing wcprops, then
> there's no point in getting back a MERGE response full of VR's. */
> if (ras->callbacks->push_wc_prop == NULL)
> cc->disable_merge_response = TRUE;
You are correct, Mike. I think I'm the one who created this variable.
Our main motivation was branching ("svn cp URL URL")... we were adamant
about forcing that operation to be truly O(1).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts on the DAV MERGE request.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> On Thu, Nov 13, 2003 at 10:13:25AM -0600, C. Michael Pilato wrote:
> >...
> > I see that variable, but ... it's variable. And unless ethereal is
> > making stuff up, we most certainly do use the MERGE. If my reading is
> > correct, we only disable the MERGE details (the resource) stuff when
> > the user is doing a working-copy-less commit (svn rmdir URL, svn
> > import URL, etc.). This from get_commit_editor():
>
> Ah! Right. For some reason, I thought it was always used by the client.
> But I see now... okee dokee.
>
> So back to the original question: yes, things could certainly be arranged
> to avoid a delta and just replay the changes table. Should work just fine.
> The actual MERGE response is flat, anyways.
Cool. The code is written; passes 'make davcheck' and a battery of
hand tests aimed at jukin' it. But I'm going to hold off until after
the 0.33 release to commit the change.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts on the DAV MERGE request.
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Nov 13, 2003 at 10:13:25AM -0600, C. Michael Pilato wrote:
>...
> I see that variable, but ... it's variable. And unless ethereal is
> making stuff up, we most certainly do use the MERGE. If my reading is
> correct, we only disable the MERGE details (the resource) stuff when
> the user is doing a working-copy-less commit (svn rmdir URL, svn
> import URL, etc.). This from get_commit_editor():
Ah! Right. For some reason, I thought it was always used by the client.
But I see now... okee dokee.
So back to the original question: yes, things could certainly be arranged
to avoid a delta and just replay the changes table. Should work just fine.
The actual MERGE response is flat, anyways.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts on the DAV MERGE request.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Stein <gs...@collab.net> writes:
> On Thu, Nov 13, 2003 at 01:34:24AM -0600, C. Michael Pilato wrote:
> >...
> > The point of the MERGE response is to tell the client what resources
> > changed as a result of the MERGE. For our purposes, that means
> > reporting all the items actually committed, not including bubble-up
> > directories.
>
> Right. That is the definition / process for MERGE.
>
> *However* ... we disabled that walk some time ago. It was creating an O(n)
> behavior for commits. For regular DeltaV clients, they'll get a "proper"
> MERGE response. The SVN client tells the server "don't bother. I already
> know the changed resources."
>
> See the 'disable_merge_response' variable in merge.c
I see that variable, but ... it's variable. And unless ethereal is
making stuff up, we most certainly do use the MERGE. If my reading is
correct, we only disable the MERGE details (the resource) stuff when
the user is doing a working-copy-less commit (svn rmdir URL, svn
import URL, etc.). This from get_commit_editor():
/* If the caller didn't give us any way of storing wcprops, then
there's no point in getting back a MERGE response full of VR's. */
if (ras->callbacks->push_wc_prop == NULL)
cc->disable_merge_response = TRUE;
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts on the DAV MERGE request.
Posted by Greg Stein <gs...@collab.net>.
On Thu, Nov 13, 2003 at 01:34:24AM -0600, C. Michael Pilato wrote:
>...
> The point of the MERGE response is to tell the client what resources
> changed as a result of the MERGE. For our purposes, that means
> reporting all the items actually committed, not including bubble-up
> directories.
Right. That is the definition / process for MERGE.
*However* ... we disabled that walk some time ago. It was creating an O(n)
behavior for commits. For regular DeltaV clients, they'll get a "proper"
MERGE response. The SVN client tells the server "don't bother. I already
know the changed resources."
See the 'disable_merge_response' variable in merge.c
>...
> It's kinda like when your i486's hard drive goes out. And you're
> bummed, right? Then you win a screaming 2-GHz Athlon machine with all
> the goodies, and you're so excited because you finally have a new
> harddrive you can rip out and use to fix your i486. About the middle
> of the next week, it hits you.
Heh :-)
>...
> So now I'm wondering -- why are we using an editor at all for MERGE
> handling? The whole point of svn_repos_replay() is to take a set of
> known paths and drive an editor with them -- in other words, to take a
> flat dataset and give you nice path-based heirarchy. But all the
> MERGE editor does is flatten that stuff back out into a list of
> resources, which I'm pretty sure is just the list of paths that we got
> from the "changes" table in the first place.
Ah. Quite true.
> I'm gonna spend a little time trying to cut out the middle m[ae]n
> here. And if it all works out, then my apologies to those who have
> suffered MERGE timeouts as a result.
No need. We don't normally run that editor anyways.
Cheers,
-g
--
Greg Stein, Director of Software Engineering
CollabNet, Inc. http://www.collab.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org