On 11/15/05, Jim Blandy <jimb@red-bean.com> wrote:
> If I'm understanding the big picture here, the essential problem is
> that none of the existing svn_ra.h functions give you a complete
> description of a revision's effects on the tree. If I've got
> something confused, please let me know.
>
> - svn_ra_get_commit_editor2 carries everything --- prop changes, text
> changes, rename/copy history --- but it's going in the wrong
> direction: to the server. We want data coming from the server.
Correct.
> - svn_ra_do_update is going in the right direction, server->client,
> but doesn't carry copy information, because the WC doesn't care and it
> costs something to recover that information.
> - svn_ra_do_diff2 goes in the right direction, but if I'm reading
> right, it doesn't provide history.
Both update and diff have two problems. First, they fail to carry
along copyfrom info, so you have to get that info from log, if you get
it from log you then find that you don't actually have enough
information to derive everything you need, because you can't tell the
difference between a copy and a copy with additional textual
modifications. Second, if I do a copy of a directory the update and
diff APIs will happily tell me that every single file under those
directories has been changed. It really hasn't, but from the point of
view of the users of diff or update it might as well have, since you
need that info to generate a diff or update a working copy.
> So your new replay method is a fourth function that sends deltas from
> client to repository, but that actually gives full information.
Close, I want all the info, and I want it in a way that actually
corresponds to the underlying change to the repository filesystem, not
the percieved change from the outside.
> I guess I'm surprised that we need three ways of doing essentially the
> same thing: comparing revisions in the repository and transmitting
> their differences.
It's a combination of providing the right info and avoiding sending
info that isn't required. Personally, it seems like the fact that we
already have this kind of API underneath (we use it for svnadmin dump,
for example) indicates that there is a use case for exposing this sort
of API, as opposed to requiring people to do backflips to make the
existing APIs bend to their needs.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 16 02:29:53 2005