software - svn server

Subversion vs CVS (8)

Aunque preferiría Subversion a CVS en la mayoría de los casos, debería saber lo que se está perdiendo con Subversion:

CVS ve las etiquetas y las ramas como cosas diferentes; Subversion no. Esto significa que las herramientas de terceros construidas sobre Subversion (p. Ej. IDE con integración de control de origen) tienen un trabajo más difícil al conocer la diferencia. Por lo general, debe realizar una configuración especial para indicar dónde se encuentran sus etiquetas y sucursales, y debe asegurarse de que los usuarios se adhieren a un determinado diseño de sistema de archivos.
Subversion no puede ver un archivo y decirle en qué momento alguien creó una rama o etiqueta de él. Herramientas como CVSGraph pueden usar esta información para dibujar un árbol del historial de un archivo. Para hacer eso con Subversion, necesitaría buscar en todos los directorios de ramas / etiquetas, y no he visto ninguna herramienta que lo haga bien.
CVS ha existido por más tiempo, y las herramientas de terceros son más estables, según mi experiencia.

He usado SVN y CVS un poco, pero tendré que elegir uno para un nuevo proyecto que comenzaré.

¿Alguien que haya usado ambos ampliamente puede ofrecer algunos pros y contras y que ellos piensan que es mejor? También se agradecerán los mejores recursos de aprendizaje.

Esto será para un proyecto pequeño, solo uno o dos desarrolladores para comenzar.

Generalmente Subversion ... Sin embargo, debes tener cuidado con los problemas de recursos.

Cuando estaba trabajando para una compañía de juegos, teníamos algunos directorios que contenían cientos de archivos diminutos y otros directorios que contenían unos pocos cientos de archivos meg. Cuando intercambiamos de CVS a Subversion, la velocidad de pago del repositorio disminuyó de una hora a cuatro o cinco horas. La actualización también fue sustancialmente más lenta.

Esto es casi seguro debido al uso de http o ssh para transmitir datos de archivos, en comparación con el csv pserver nativo, sin embargo, dado que es tan fácil configurar svn en ssh o webdav, las personas tienden a no pensar en la sobrecarga del protocolo. Sin embargo, puede utilizar un protocolo svn nativo y esto debería aliviar el problema, no probamos esto en mi empresa anterior.

Otro problema que a menudo se ignora es el espacio de almacenamiento, encontramos que la subversión usó varias veces tanto almacenamiento local como CVS. Me parece recordar que almacena una copia local de los datos de repos para acelerar la difusión, esto no será un gran problema a menos que almacene varios gigabytes en su repositorio.

He usado Subversion por 3.5 años, ahora me mudé a otra compañía que usa CVS para control de fuente. Al principio, no hay muchas diferencias entre los dos, pero al llegar a la operación de fusión (que es la mayor parte de mis preocupaciones) podría decir que CVS hizo un mejor trabajo. Los conceptos de ramas / etiquetas en SVN son confusos, aunque muy claros en CVS. también fusionar (en mi caso, integrar una rama) es mucho más fácil en CVS que en SVN. La debilidad de CVS es hasta ahora en mi idea solo el compromiso atómico. de lo contrario, sería una buena elección.

He usado ambos. No hay comparación; quieres svn La única razón para usar CVS es porque está ingresando o asumiendo un sistema heredado con una administración que no desea cambiar el status quo. Si está comenzando un nuevo proyecto, es prácticamente imposible lógicamente argumentar que CVS es mejor que Subversion.

Si buscas en Google, deberías encontrar muchas comparaciones y fundamentos para usar Subversion a través de CVS. Algunas de las ventajas de Subversion sobre CVS:

puede mover o renombrar archivos o directorios limpiamente
compromisos atómicos
copia y ramificación "baratas"
commits son conjuntos de cambios en todo el árbol (no solo historias en archivos individuales)

Habiendo dicho todo esto, le recomiendo que también explore algunos de los VCS distribuidos como Bazaar, Mercurial y git. Yo personalmente uso git en todos mis proyectos.

Llámame anticuado, pero prefería mucho el modelo de ramificación / etiquetado en CVS.

En CVS, las ramas y las etiquetas son cosas diferentes. Una etiqueta es una etiqueta para una revisión. Son muy útiles para cosas como marcar una etiqueta de PRODUCCIÓN para que los archivos se sincronicen con su servidor web. No tiene que fusionarse para actualizar los archivos de PRODUCCIÓN ; solo mueve la etiqueta.

Las sucursales viven en el mismo ''espacio de nombres'' que el archivo principal; es fácil rastrear todas las modificaciones de un archivo en particular.

En SVN no hay cosas como una etiqueta. Solo hay ramas. Si quieres etiquetas, necesitas crear una rama y pretender que es una etiqueta. Las ramas son básicamente copias de archivos. La última vez que utilicé SVN para las ramas / fusiones, tenía que registrar la revisión del archivo previamente ramificado si alguna vez esperaba fusionarlo de nuevo (tenga en cuenta que no soy un experto SVN, por lo que esto puede haber cambiado).

Dicho esto, creo que SVN es mejor en todos los demás aspectos y probablemente no deberías comenzar un nuevo proyecto con CVS.

Subversion es como `un mejor CVS ''. Se maneja bien moviendo archivos Y directorios. Tiene soporte de ramificación, aunque es inferior a los VCS distribuidos.

También puede considerar usar un VCS distribuido como git, bazar o mercurial.

Editar: Aquí hay un enlace a una pregunta similar

Subversion tiene algunas ganancias sustanciales sobre CVS:

buenas opciones remotas http / https / svn vs pserver
compromisos atómicos
soporte de herramienta ubicuo
rebautizar
versiones de directorio

Sin embargo, tiene serias deficiencias. El más grande por el momento es que Branches and Tags no son ciudadanos de primera clase en svn, solo son directorios que se adhieren a una convención. Además de perder algunos de los beneficios de la ramificación real y el etiquetado (mencionado en otros comentarios), el mayor problema que crea es que si lo hace es muy fácil arruinarlo.

El uso de la convención por parte de Subversion en lugar de la configuración significa que debe pensar en la estructura de sus repositorios por adelantado y asegurarse de que todos se adhieran a ella. De lo contrario, crear un mundo de dolor para las generaciones futuras, y mucho menos cualquier herramienta que necesite asimilar.

La fusión y la duplicación eran casi inexistentes (asistencia de pozo para) pre 1.5. 1.5 ha tomado medidas para hacer frente a ambos, pero todavía hay margen de mejora. Fusionarse en la subversión sigue siendo mucho más difícil de lo que debe ser.

SVN sobre CVS es casi una obviedad. Sin embargo, sería negligente no considerar al menos lo que DVCS tiene para ofrecer (Git, Hg, Bzr) o si su presupuesto permite que haya herramientas comerciales con excelente reputación (Accurev, Perforce).

Es probable que Subversion sea la opción correcta, pero debe hacer su tarea para obtener los mejores resultados. Comience con el Libro rojo http://svnbook.red-bean.com/

Tendrás muchas respuestas a esto, sospecho. Quizás todos estén de acuerdo.

Entre esas dos opciones, creo que no hay duda de que debes usar Subversion. Subversion se construyó como un "mejor CVS" y, como resultado, nadie mantiene activamente CVS por más tiempo. Subversion tiene la capacidad de cambiar el nombre y mover archivos sin perder historial, admite commits atómicos, tiene un formato de depósito más robusto, tiene métodos de acceso más modernos, tiene un mejor soporte de herramientas de terceros y la lista continúa.