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
Received on Thu Nov 13 08:35:34 2003