On Tue, Sep 6, 2011 at 4:45 PM, Daniel Shahaf <danie...@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@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/
