On 9/5/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> On Wed, Sep 05, 2007 at 01:49:05PM -0700, sussman@tigris.org wrote:
> > Merge copy-on-updates branch to trunk.
> >
>
> Nice. Does it work? (the only reason I ask is that you only added a
> single XFail test, so I'm not sure what the status of the branch is
> currently).
No, the feature doesn't actually exist yet. All that branch work was
simply to change our internal architecture so that the behavior we
want *can* be written.
The new behaviors are:
* the server now supplies copyfrom arguments to add_file() during an
update, if applicable.
* if the server passes copyfrom args to add_file(), it also might
follow up with apply_textdelta() against the copied file.
* the update_editor responds to the copyfrom args by doing an
svn_ra_get_file() off to the side to install the file, so that it's
ready for any subsequent textdeltas.
* the update_editor is now ready to "grow some smarts" -- execute
some algorithms to figure out whether it already has the file in the
wc. The svn_ra_get_file() call should (in theory) be the last-ditch
fallback behavior.
Note that I'm going for the 80% solution here -- solve the most common
cases of user pain. We're not handling directories, only files. What
I'd really like help with is now is designing some algorithms to
locate files in the WC.
Another snafu: how do we know if an WC file is the file we want? For
example, if the server sends copyfrom args of "foo.c@7", and the
client notices that it has foo.c@8, how does it know if that's the
same thing? It makes me wish we had an RA call to do node-id
filesystem comparisons.
> One other comment: it'd be nice if we were able to make libsvn_client's
> file_fetcher slightly smarter, so that it's responsible for opening the
> second RA session on-demand. Otherwise, we'll always open an extra
> connection to the server every update, even if we don't need it for
> anything. This seems like a waste of server resources.
Good idea! Patches welcome. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 6 03:27:57 2007