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. 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@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@REV, returns a set of svn_fs_history_t objects representing PATHn@REVn tuples that correspond to modifications and copies of PATH@REV. Daniel (a bit out of focus)
