Hot backups to plain text make the live data storage format largely irrelevant. See `svnadmin dump --incremental`, `svnadmin hotcopy` (and its wrapper script `hot-backup.py`) as documented in the open source "Version Control with Subversion" book (another fine O'Reilly tome written by some of the core developers).
Sure, most of us have edited,v files by hand at one time or another, but Subversion has built-in commands replacing almost every non-corruption use case for that insanity. The operational procedure for handling data corruption -- which as never happened to date -- is backups, not hacking at the raw data storage format and praying.
Not yet. With a 1.0 release out, I figure something like this is likely to turn up soon.
Hot backups to plain text make the live data storage format largely irrelevant. See `svnadmin dump --incremental`, `svnadmin hotcopy` (and its wrapper script `hot-backup.py`) as documented in the open source "Version Control with Subversion" book (another fine O'Reilly tome written by some of the core developers).
h tm l#svn-ch-5-sect-3.6
,v files by hand at one time or another, but Subversion has built-in commands replacing almost every non-corruption use case for that insanity. The operational procedure for handling data corruption -- which as never happened to date -- is backups, not hacking at the raw data storage format and praying.
http://svnbook.red-bean.com/html-chunk/ch05s03.
Sure, most of us have edited
Subversion is very pluggable in on the server side. This pluggability may extend to the client as well (but I'm not certain).
Or perhaps you don't have a clue what XML-RPC is? Try the spec for clarification.
It looks like there will also be a C implementation (!). :)
Let's not forget Greg Stein's ViewCVS, a Python rewrite and improvement of WebCVS.