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)
I don't think you actually need to answer questions like "when was this
renamed", i expect you more often want to know /if/ something was
renamed between REV1 and REV2, and that's easy enough to figure out from
the path.
You'll notice that answering some of these questions is intrinsically
expensive (read: requires a sequential scan of the node's entire
history) unless you can uniquely identify each node in the repository.
PATH_at_REV is not a unique identifier for this purpose.
Another thing to note is that the answers to these questions may be
different depending on whether or not "copy" and "branch" are the same
thing. I'll not get started on why they shouldn't be. :)
-- Brane
Received on 2011-09-07 06:06:06 CEST