On 28.01.2014 08:14, Markus Schaber wrote: > SVNKit actively supports this way of working, at least according to their > homepage: "Arbitrary object model versioning: SVNKit provides API to version > virtually any object model with standard Subversion repository; there is no > need to keep anything in the filesystem.". So there seems to be a "market" > for that mode of operation.
That's just another way of saying they support the SVNKit equivalent RA API. And as I pointed out, svn_mtcc is just another wrapper around that same API. (That doesn't mean its useless, of course). > To be honest, I don't care that much in which library those functions are, > but I think having them in their own library may be a little bit of overkill. The ideas is to separate our core functionality from extensions built on top of it, such as svnmucc and svnversion. I would like /everything/ of that sort to go into a new library. As long as we have separate libs for separate API layers, we should be consistent; otherwise we may as well stuff svn_wc, svn_client and svn_ra into one library, and svn_repos and svn_fs into another. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
