[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: fs-successor-ids: public API

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 7 Sep 2011 09:30:05 -0400

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

Mark Phippard
Received on 2011-09-07 15:30:36 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.