2011/9/7 Branko Čibej <br...@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@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@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@rev) > * when was it deleted? (-> path@rev) > * what is its immediate predecessor? (-> path@rev) > * what are its immediate successors? (-> list of path@rev, includes > copied-to) > * what is the its PATH at REV1? (-> path) > * where did its content come from? (-> list of path@rev, includes > merged-from) > * where did its content go to? (-> list of path@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@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@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/