¿Es factible usar svn para documentos?

Necesitamos tener documentos compartidos entre clientes (funcionalidad similar a CRM). Los usuarios deben ser capaces de:

  • Edite los documentos y guárdelos de nuevo
  • Adjunte documentos nuevos

Nuestra aplicación está codificada en WPF con WCF para el transporte de datos y NHibernate / SQL para los datos en el server.

lo que estamos pensando es usar SVN y hacer que la aplicación cree un check-out local de partes del repository (cuando hacen clic en un documento, se lo saca por SVN en segundo plano y se abre desde la ruta local) – Cuando se guarda silenciosamente (usando la monitorización de la ruta) se volverá a enviar al repository.

Pregunta: ¿Es esto factible o hay mejores soluciones para esto?

EDIT 1: Resumen hasta el momento:

  • Analizaré el uso de Git / Mercurial en lugar de SVN
  • El tamaño del documento (revisiones) puede ser prohibitivo en espera de testings
  • SharePoint es una opción (aunque no es viable en mi caso ya que el costo solo es prohibitivo). Examinaré las alternativas para SharePoint, aunque.
  • No hay mucha experiencia sobre el uso de repositorys para muchos usuarios aunque funciona para equipos pequeños.
  • El software Wiki podría ser una alternativa a SVN.

Gracias por todos los comentarios. Lo mantendré abierto un poco más.

EDIT 2: Resumen después de unos días de trabajo – Tengo un cliente trabajando – vea mi progreso aquí .

Depende del tipo de documentos que estés usando. Si tiene muchos files binarys modificados y comprimidos, no los use.

Sin embargo, si los documentos están en un formatting abierto como un lenguaje Wiki, (X) HTML, LaTeX o ODF descomprimido, entonces usar un sistema de control de versiones tiene sentido. Además, un montón de files ODF comprimidos o files PDF se manejan muy bien, especialmente si los files son en su mayoría de less de 5 MB.

Además, asegúrese de verificar algunos sistemas de control de versiones más recientes como Mercurial y Git antes de adherirse al SVN conceptualmente desactualizado. En su escenario, no se beneficiará mucho con la parte "distribuida" de Mercurial y Git, pero, sin embargo, son más fáciles de configurar, al less según mi experiencia. Y ofrecen funciones de control de versiones muy avanzadas que pueden salvar su día en los casos poco frecuentes en que los necesite.

En caso de que se adhiera a SVN, y si el software de su cliente se ejecuta bajo un moderno sistema Unix, también puede probar SVN-FS . Este es un sistema de files que usa un server SVN remoto. Cada lectura va a la última revisión. Cada escritura crea una nueva confirmación. Esto parece ser exactamente lo que quería build alnetworkingedor de SVN.

En base a las pesadas references de .NET, ¿está todo configurado con MSDN? Quizás pueda hacer uso de SharePoint … que posiblemente ya esté incluido en su count de MSDN.

También es posible que desee considerar el uso de una Wiki para la administración de documentos: he visto esto hecho y hacerlo por mi propia organización. Estamos usando Wiki Confluence de Atlassian. Confluence proporciona versiones y administración general de documentos.

No usaría SVN para esto, SVN no es muy eficiente cuando se trata de files binarys. Al usar SVN como un canal secundario para algunos contenidos en su aplicación, simplemente complica las cosas al agregar otra tecnología y dependencia, pero no utilizará gran parte de su potencial real.

Guardaría los documentos como blobs en la database y los obtendría / almacenaría a través de WCF.

En general, no creo que sea bueno utilizar SVN o cualquier sistema de control de versiones para compartir documentos. La principal desventaja es el sistema diff en files binarys … Su repository SVN crecerá rápidamente …

Tal vez debería intentar usar algunas de las herramientas comerciales diseñadas para compartir documentos (por ejemplo, Microsoft Sharepoint). O algunas alternativas de código abierto … Tal vez deberías leer esta publicación …

Creo que usar tecnología ya hecha y probada es una gran idea. Me gustaría ver su progreso si realmente vas por ese path.

Definitivamente iría CONTRA SharePoint: te vincularás a Microsoft de maneras que son difíciles de describir aquí. Desde mi punto de vista, SharePoint es una tecnología que necesita cuidado por sí misma.