Brane, FYI, I tried to reply offlist but it bounced:
<br...@e-reka.si>: Host or domain name not found. Name service error for
name=e-reka.si type=A: Host found but no data record of requested type
Branko Čibej wrote on Wed, Sep 07, 2011 at 06:05:05 +0200:
> 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)
>
> 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@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
