Hi, Ben, Von: Ben Reser [mailto:b...@reser.org]
> 2) libsvn_client_mtcc_*: Should these exist at all or be moved to another > library? This conversation died out. I welcome that kind of functions. They help alternative clients, and (in theory) even allow clients which work without an SVN working copy (or implement their own wc-like logic) This feature may seem academic, but due to the nature of CODESYS SVN (which has to version a tree of objects in a database instead of a tree of directories and files which is in the file system), I guess such a feature may be useful. The costs to keep the different trees (svn working copy and the "Object Manager" database) in sync is enormous, especially due to a lot of corner cases and non-orthogonalities on both sides[1]. Actually implementing our own "Working Copy" like logic could be the smaller effort, given that we have all the APIs available which we need. The mtcc APIs seem to provide a very useful part of the "commit" / "write back to the repository" side of the thing which was not yet provided in a public API. 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. So: Yes, in my mind, these functions should exist at all. :-) 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. (Except maybe if you expect this part of the API to grow noticeably in the future, and to be useable even without linking against libsvn_client itself...) [1] Some examples on the SVN side which I had to workaround: - "svn commit" does not give any notifications for files which are unlocked during the commit operation if those files don't have any content changes. - No way to "pull in" or "expunge" externals except "svn update" which has some side-effects. (Currently, "svn update -r BASE /path/to/parentdir" seems to do the trick, but it does not work selectively enough - No supported way to "move" or "rename" the root of an external subtree without losing changes below that subtree. - "svn status" does recurse into externals, "svn info" does not (this seems to be fixed in trunk / 1.9). - There is no good way for an in-place import which includes properties. (Our current workaround has the cost of two commits: The first one for creating the project root directory, then checkout and building the directory tree, and then committing the result. Other workaround have other disadvantages...) - "svn diff" fails for files which are locally added, and someone else has committed a file in the same location on the repository. (The user wants to check what's coming in, without actually updating his working copy and getting the conflict.) There were more, and some of them were fixed in recent versions... Best regards Markus Schaber CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
