Re: fs-successor-ids: public API

2011-09-09 Thread Daniel Shahaf
[ sorry for the delay; didn't want to reply past-midnight ] Branko Čibej wrote on Wed, Sep 07, 2011 at 17:18:11 +0200: > On 07.09.2011 06:05, Branko Čibej wrote: > > What specific questions are we likely to ask about a particular node > > revision? The obvious ones are: > > > > * when was this "

Re: fs-successor-ids: public API

2011-09-07 Thread Branko Čibej
On 07.09.2011 17:54, Daniel Shahaf wrote: > Brane, FYI, I tried to reply offlist but it bounced: > > : 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 Well, well. Funny that this list's traffic goes to that address,

Re: fs-successor-ids: public API

2011-09-07 Thread Daniel Shahaf
Brane, FYI, I tried to reply offlist but it bounced: : 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 sh

Re: fs-successor-ids: public API

2011-09-07 Thread Branko Čibej
On 07.09.2011 15:33, Hyrum K Wright wrote: > 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

Re: fs-successor-ids: public API

2011-09-07 Thread Branko Čibej
On 07.09.2011 06:05, Branko Čibej wrote: > 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) >

Re: fs-successor-ids: public API

2011-09-07 Thread Hyrum K Wright
On Tue, Sep 6, 2011 at 4:45 PM, 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 th

Re: fs-successor-ids: public API

2011-09-07 Thread Mark Phippard
2011/9/7 Branko Čibej : > 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 a

Re: fs-successor-ids: public API

2011-09-06 Thread Branko Čibej
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. > > - Wh

fs-successor-ids: public API

2011-09-06 Thread Daniel Shahaf
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? Modification