Mercurial como almacén de datos versionado

En lugar de utilizar una tabla Posts SQL Server con una tabla PostRevisions correspondiente para versiones de contenido de usuario de files planos (text / HTML), prefiero dejar que Mercurial almacene de manera eficiente los cambios para mí y simplemente hacer un seguimiento del repository de files de cada usuario.

Esto haría que las copys de security fueran realmente fáciles, dependiendo de cómo quisiera compartir o fragmentar el contenido. La solución obvia es tener un único repository para almacenar todos los datos del usuario, con carpetas para cada ID de usuario.

Sin embargo, tengo un mal presentimiento sobre el performance y los problemas de concurrency con este enfoque al enviar files al repository que almacenan millones de files de usuarios.

¿Alguien ha intentado usar Mercurial como un almacén de datos secundario para files de usuario planos?

A less que vaya a aprovechar las características más fuertes que ofrece un sistema SCM como hg, le sugiero que no tome este enfoque. ¿Vas a usar twigs y fusionar? Probablemente no. Entonces, ¿qué ganas realmente usando hg aquí? La copy de security es igual de fácil con una database.

Al final del día, un RDBMS con una tabla de publicaciones y revisiones funciona bien y es una base más sólida para build que lo que básicamente es una solución basada en locking de files (hg, git, etc.). Probablemente funcionaría mucho mejor, también.

Por cierto, también debe evaluar tiendas orientadas a documentos, como Mongo o CouchDB.