Re: Thoughts on the DAV MERGE request.

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