Garrett Rooney wrote:
> 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
While "update" doesn't care about copy-from info, I'd think that "diff", in
general, should care about it. OK, the present implementation of a user-level
"diff" command doesn't use it, but in order to write "proper" (tree-aware)
diffs I would think we want that information.
> 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.
Again, the present implementation of "diff" uses it, and we want that mode to
be available, but I would like to have a "diff" mode that just says "tree dir1
was renamed to dir2" and doesn't report all the files inside it. (Only if the
rename/move is completely within the reported tree.)
(I hope "update" already does a proper move/rename of a directory on the WC
side without re-downloading all of the stuff inside it. Again, only if the
move/rename is completely within the tree being updated. Does it?)
So, it would make sense to me to give the present "diff" API those two
capabilities. (It sounds like they'd both need to be optional.)
Even if you don't consider doing that for your "replay" purposed, is this
something we should aim to do anyway? - does it make sense?
>>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.
Hmm... I can imagine that even if both of those additional behaviours were
available from the "diff" API, it might still not correspond as closely as you
would like to the underlying repository change.
Still, something to think about.
Should, in fact, the above (existing) functions be provided at a _higher level_
than your repos_replay? It seems that perhaps they could all be implemented in
terms of it? I'm completely unfamiliar with this area so I'm probably missing
the fact that those three plus your repos_replay are already all going to be
implemented on top of a common lower-level API, or something - in other words,
that you are just adding an API wrapper at this level to functionality that is
already available lower down. (A quick brush-off response is fine; I'm not
ready to learn the details.)
You wrote elsewhere in the thread:
> The authz support bungles the case
> of a directory copied from a location you aren't allowed to see, it
> needs to recurse into the directory adding its contents, since you
> can't expect the caller to have access to the contents.
Er... I don't know about this stuff either, but it strikes me that if the
caller is not authorised to see data in a particular area then you should not
send that data to the caller. (Perhaps abort if you discover that is the
case.) Maybe I'm completely misunderstanding, in which case ignore me.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 16 11:47:10 2005