On 11/16/05, Julian Foad <julianfoad@btopenworld.com> wrote:
> 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 have no objection in concept to the idea that diff should be able to
provide such information, but after a little time looking at the
reporter code I must say I have to agree with ghudson in that I'm not
sure what the correct behavior would be for many cases when you're
diffing non-consecutive revisions, and for any of the potential
behaviors I can think of I'm not sure how to implement it without it
being potentially very slow.
> (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?)
I'm not positive, but I don't think it currently does.
> 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?
Like I said, I have no objection to providing this info, I just don't
know how exactly it should work in many cases nor how we could
implement it efficiently.
> 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.)
While it's possible that they could be implemented in terms of some
theoretical common API, at this point the two implementations have
little to nothing in common, and making them use the same code would
be a rather large project, and one that would come after tackling the
"how should it work" and "how can it be fast" parts of the problem.
> 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.
Consider the case where you have two directories, one that is private
and nobody can see its contents, and one that is public and everyone
can see it.
Clearly, if a file is copied from the private section to the public
one people are now allowed to see the file's contents, as of the
revision that it's copied. Unfortunately you can't just have replay
emit a "copy" operation in this case for two reasons. First, they
aren't allowed to see the area the copy came from, so you can't tell
them that path existed at all, second, they don't have the source file
contents, so you have to force the text delta to be relative to an
empty file instead of relative to the source file.
The current code handles this case just fine. It doesn't work right
if you copy a directory full of stuff from the private section to the
public one though. To do that correctly it will need to recurse
through the directory's contents and issue the appropriate mkdirs and
adds, again giving the client only the current version, dropping
entirely the fact that there was a source version that they are not
allowed to know about.
Ironically, this logic will probably prove useful for implementing the
"replay only a particular subtree" kind of thing that clkao wants for
SVK, because the question of "how do I deal with stuff i'm not allowed
to see" has a very similar answer to the question "how do I deal with
stuff I don't want to replay because it's outside my area of
interest".
-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 19:21:05 2005