On Tue, Sep 6, 2011 at 4:45 PM, Daniel Shahaf <danielsh_at_elego.de> 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.
I don't know your specific use cases, but invite you to consider the following.
Currently, we essentially have a system modeled after a singly-linked
list, where the links go backward in time. Adding the successor id
tracking effectively turns this into a full-fledged tree, which is a
fairly well-understood data structure. Could the initial APIs be
modeled on a tree, with further functionality built upon that as use
cases require?
Probably a bit naïve,
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2011-09-07 15:33:55 CEST