fs-successor-ids: public API

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.

Particular APIs:

- svn_repos_deleted_rev() may be re-implemented using successors, when
  the FS supports them.

- svn_fs_history_next() has been mentioned. To handle the fact that one
  PATH_at_REV may have multiple successors, svn_fs_history_next() should
  return multiple svn_fs_history_t objects, either directly (by
  returning a set of such objects) or indirectly (by taking a callback
  function that gets called repeatedly, each time with one
  svn_fs_history_t object).

http://colabti.org/irclogger/irclogger_log/svn-dev?date=2011-08-31#l126

To summarize, I'm asking how the FS API for this should look.
A concrete suggestion would be an svn_fs_history_next() that, given
a PATH_at_REV, returns a set of svn_fs_history_t objects representing
PATHn_at_REVn tuples that correspond to modifications and copies of
PATH_at_REV.

Daniel
(a bit out of focus)
Received on 2011-09-06 23:46:11 CEST