usados - svn server
¿Por qué usar SVN? ¿Hay algún profesional oculto(sobre GIT/Mercurial/Bazar) allí? (8)
Posibles duplicados:
¿Por qué git es mejor que Subversion?
Ya he leído mucho (aunque no lo suficiente como para obtener la imagen perfecta) sobre los sistemas de versiones, y la conclusión obvia es que GIT es simplemente el mejor. O bazar tal vez. O Mercurial. Pero si así fuera, entonces nadie usaría SVN, pero aún lo hacen. ¿Por qué? Yo mismo no tengo una opinión propia sobre qué vcs es generalmente el mejor hasta ahora debido a la falta de experiencia con ellos. ¿Podrías compartir tus pensamientos?
Actualmente estoy manteniendo un servicio de control de versiones para una institución de investigación estadounidense. No solo soportamos SVN además de Git y Mercurial, sino también CVS.
La "característica asesina" de SVN entre nuestros usuarios es clones estrechos. Puede realizar una comprobación de solo un subdirectorio en una jerarquía, descargar solo los archivos relacionados con ese directorio y aún así poder realizar confirmaciones. Muy recientemente, Git dio una variación similar, pero no tan útil en esta función, llamada "checkout" (vea también " Sparse checkout" en Git 1.7.0? ). Esto le permite filtrar su árbol de trabajo, pero aún así lo obliga a descargar el historial completo de todo el proyecto, lo que puede ser prohibitivo incluso cuando no están involucrados grandes binarios. Tenga en cuenta que el disco es barato, y si absorbe el golpe del clon inicial por adelantado, los tirones subsiguientes son lo suficientemente rápidos, pero esto no ayuda a las personas que se fueron de viaje antes de darse cuenta de que necesitaban clonar, y en cualquier caso, incluso Las escasas comprobaciones de Git no te permitirán comenzar tu árbol de trabajo cinco niveles más abajo, por lo que se ve un poco feo.
Además, los usuarios encuentran que los archivos de authz más fáciles de escribir que los ganchos de confirmación de Git, se sienten más cómodos con la sintaxis y metodología de SVN que cualquier DVCS, y quizás lo más importante de todo, ya tienen muchos miles de confirmaciones en la historia de SVN . Los experimentos sobre la migración de grandes repositorios de Subversion a Git o Mercurial han brindado resultados mixtos, y estos son científicos que intentan trabajar en sus propios proyectos, sin donar su tiempo para el desarrollo de un DVCS.
CVS todavía tiene seguidores por una razón similar. Imagínese, como usuario de Git, tener comprobaciones dispersas que también le permitan reasignar arbitrariamente los archivos de la rama en su árbol de trabajo, utilizando un formato que está versionado junto con el repositorio y se distribuye con cada extracción habitual, que le permite para escribir definiciones que pueden tener grupos que pueden incluir otros grupos, y que solo se despliegan los archivos necesarios para la ubicación del sistema de archivos en un clon. Eso es sencillo en los módulos CVS, e imposible en todos los DVCS. Por todos los pecados de CVS (y créanme, somos muy conscientes de ellos y nos esforzamos por desalentar los nuevos proyectos de CVS a menos que no puedan vivir sin módulos), es imposible convencer a un grupo que usa esa función. para migrar a otro sistema de control de versiones.
El software DVCS ha traído algunas innovaciones asombrosas, pero también faltan cosas que algunos desarrolladores dan por sentado. Asegúrese de saber de antemano cuáles son sus requisitos antes de elegir uno.
Aparte de las otras cosas que mencionan las personas (grandes cantidades de datos binarios, maduros, estables, etc.) es que svn se basa en un modelo jerárquico clásico que es fundamentalmente diferente de las revisiones basadas en parches / cambios.
Nuestra compañía tomó la decisión de permanecer con SVN porque este modelo se ajusta a la forma en que manejamos nuestro ciclo de lanzamiento y ramificación. Vemos la progresión directa de las versiones como una bendición, no una perdición. Las actualizaciones se envían a un repositorio centralizado, y ciertas revisiones consideradas "estables" se verifican en un entorno real. En cualquier momento, queda claro de inmediato cuál es el estado de cada entorno para todos los involucrados. (sí, esto es posible con git). Incluso la administración que no sabe nada sobre el control de revisión o el desarrollo de software puede decir: "Nos gustó cómo lo tenía cuando estaba en la versión 2547".
Por otro lado, debo mencionar que uso darcs y git para proyectos en los que trabajamos juntos, con mis amigos y colegas de FOSS, ya que el modelo distribuido basado en parches funciona para nosotros. Podemos movernos ad hoc a través de la línea de tiempo del proyecto y seleccionar todo tipo de cambios.
Realmente, la ventaja de SVN, mi empresa, es su fuerte jerarquía y accesibilidad para los no programadores que ya están familiarizados con los conceptos de "iniciar sesión" y "descargar".
Hablando de la compañía para la que trabajo, la razón más importante para usar SVN es poder mantener archivos binarios enormes, de formato propietario, bajo el control de versiones. En concreto, las bibliotecas de miles de archivos CAD. En este caso, tiene sentido que el VCS esté basado en archivos como SVN, en lugar de en información textual como Git.
Dejando de lado si puede o no realizar "desprotecciones" superficiales con Git, o qué tan bien almacena datos binarios, el hecho es que está diseñado para rastrear líneas de información textual que flotan alrededor de un árbol de código fuente. Además de hacer esto, ese modelo no es adecuado para rastrear bibliotecas de datos binarios.
Sinceramente, sin embargo, esa es la única razón sólida por la que lo recomendaría: P
La gente sigue usando Subversion porque está diseñado con el primer paradigma que viene con los sistemas de control de versiones (centralizado). Cambiar a distribuido (y basado en cambio en lugar de basado en versión) puede tomar algún tiempo para acostumbrarse (como se puede ver en la experiencia de Joel ), y muchos equipos deciden no usarlo debido a la resistencia al cambio.
Las herramientas mercuriales son bastante maduras, en mi opinión son comparables a las de SVN.
SVN está establecida y madura, con herramientas igualmente maduras.
Si bien svn está establecido / maduro, debo admitirlo, Kenji Kina tiene razón: está viviendo en el pasado con un modelo de control de versiones que está desactualizado. Solo he usado svn, pero después de leer / ver a Linus y Joel hablando sobre DVCS, suena como una idea brillante. Creo que Perforce hace algo similar.
Esto no significa que svn sea malo (¡funciona bastante bien!), Pero es más fácil administrar su código y tener confirmaciones más frecuentes con un DVCS. Porque si rompes algo, es fácil deshacerlo. Si se ramifica, es fácil de fusionar. En general, solucionaron muchos de los principales dolores de cabeza que tienen la mayoría con Subversion.
Si nunca ha usado otro sistema de control de versiones anteriormente, y es bueno implementarlo usted mismo y escribir código (y no documentos o imágenes o cosas para las que no necesita elementos textuales / diferencias), hágase un favor y busque en DVCS. Entonces no necesitarás ser re-educated .
Subversion tiene una ventaja cuando un repositorio contiene muchos datos binarios, que no se comprimen delta bien. Una comprobación de Subversion solo aspira a la cabeza, pero Git clona todo el historial, que puede tener un peso de varios gigabytes. Sí, esto es bueno para el modo avión, pero recuperar el clon inicial puede llevar horas.