Greg Hudson wrote:
>>Anyway. I propose that the API allows searches in any direction, and to
>>optionally return a list of paths.
>>
>>
>
>-0 on this. I can see allowing forward search given true rename
>tracking, but multiple results for copies is going well beyond the
>scope of this function ("where is this file as of that rev?"), even if
>we provide that kind of functionality in the future.
>
>
O.K., let's agree to disagree on this point. :-)
>>>but "svn_fs_get_node_path" sounds likea simple FS operation.
>>>
>>>
>
>
>
>>There's no reason why it shouldn't _be_ a simple operation. The fact
>>that our schema currently makes it a total pain is embarrasing, but
>>irrelevant.
>>
>>
>
>When I say "sounds like a simple FS operation," I meant it sounds like
>a simple getter function, like svn_fs_node_id. A two-dimensional
>search simply can't be that simple; it can be efficient, but it can't
>be a simple retrieval operation in any sane implementation. So a word
>like "trace" makes more sense than a word like "get".
>
>
Oh! All right, I'll buy that. And to make it consistent with current
terminology, "svn_fs_trace_node_locations" seems right -- too long
again, but right... Maybe just "svn_fs_trace_node"?
Dunno.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 1 23:29:05 2004