2011/9/7 Branko Čibej <brane_at_e-reka.si>:
> On 06.09.2011 23:45, Daniel Shahaf wrote:
>> How should the fs-successor-ids branch's new functionality be reflected
>> in the API and the public API?
>>
>> The basic question is "Given PATH_at_REV, will it be moved or copied in the
>> future?", and the use-cases Stefan has also boil down to that.
>>
>> - What operations should the API report?
>>
>> Modifications? Copies? Deletes? Moves? Deletes of a parent?
>>
>> For now we can implement the minimum required API --- ie, one that
>> answers the above question, and nothing more. (We could later have
>> higher-level public FS APIs that wrap it (eg, to make the FS do more
>> work in one API call).) Also, some callers that require specific
>> semantics can enforce those in repos-layer wrappers.
>
> You might be concentrating a bit too much on the successor-id feauture.
> The thing to do is to consider what is useful to know about PATH_at_REV,
> then see which answers the existing APIs already provide, and if their
> implementations can be trivially extended to provide more answers based
> on having knowledge about a node revision's future.
>
> What specific questions are we likely to ask about a particular node
> revision? The obvious ones are:
>
> * when was this "thing" created? (-> path_at_rev)
> * when was it deleted? (-> path_at_rev)
> * what is its immediate predecessor? (-> path_at_rev)
> * what are its immediate successors? (-> list of path_at_rev, includes
> copied-to)
> * what is the its PATH at REV1? (-> path)
> * where did its content come from? (-> list of path_at_rev, includes
> merged-from)
> * where did its content go to? (-> list of path_at_rev, includes merged-to)
Not sure what the API would look like, but one of the features that
this cache should enable is revision graphs. I could envision an API
that lets me pass PATH_at_REV and receive back the entire history of that
file going forward and backward. One option might be to return svn
log output for all changes to all locations for this item. Another
option, might be to just to return all of the PATH_at_REV where this file
was copied/deleted in the repos. I *think* this would be enough to
draw a basic structure of the history and you could probably
supplement the picture by calling svn log for each of these paths you
receive.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-09-07 15:30:36 CEST