Usar un sistema de control de versiones como back-end de datos

Estoy involucrado en un proyecto que, entre otras cosas, implica almacenar modificaciones y cambios en un gran documento jerárquico (text con formatting HTML). Queremos include versiones de cambios textuales y de cambios estructurales.

Actualmente mantenemos las secciones del tree de documentos en una database relacional, pero a medida que comenzamos a trabajar en la administración de las versiones de los cambios estructurales, está claro que corremos el riesgo de tener que escribir muchas de las funciones que un control de versiones sistema proporciona.

No queremos redevise la rueda. ¿Es posible que podamos usar un sistema de control de versiones existente como almacén de datos, al less para el documento en sí? Presumiblemente, podríamos hacerlo escribiendo nuevas versiones en el sistema de files y manteniendo ese directory bajo control de versiones (y haciendo commits programáticamente, etc.) pero sería mejor si pudiéramos interactuar directamente con el repository a través del código.

El VCS con el que estamos más familiarizados es Subversion, pero no estoy muy contento con la forma en que Subversion representa cambios en la estructura del directory. Sería bueno si pudiéramos ver que una revisión en particular incluye mover una sección del Capítulo 2 al Capítulo 6 , en lugar de solo ver una nueva versión del tree. Esto se parece más a la forma en que un sistema como Mercurial maneja los cambios en la estructura.

¿Algún consejo? ¿Los VCS tienen API públicas, etc.? El proyecto está en Java (con Spring) si es importante.

Tal vez podrías usar un repository compatible con JCR (JSR-170) como Jackrabbit . Para mí, lo que estás describiendo es exactamente para lo que JCR es. Eche un vistazo a este artículo .

Sin duda, puedes progtwigr SCM a través de API. Consulte SVNKit para Java y Subversion, o JGit para Java y Git. Mercurial no parece ofrecer tal API.

Hagas lo que hagas, finaliza tu implementación en una API adecuada, de modo que puedas intercambiar un SCM por otro, o tal vez bin el concepto de SCM en algún momento en el futuro. Sin embargo, puede ser una solución pragmática para su problema y merece más investigación.

Pruebe http://svnkit.com/ para Subversion.

Aquí tiene un SVN lib SVN lib de Java puro que puede ser utilizado por la integración de Eclipse SVN, por lo que debería ser bastante estable.