SVN? VSS? ¿Por qué es uno mejor que el otro?

Question

Tiendo a tener la sensación de que la mayoría de la gente cree que SVN es un bien dorado, mientras que VSS es el peor programa jamás concebido (al menos como Control de versiones).

Dicho esto, ¿por qué? He usado algunos CVS, y mi trabajo actual usa VSS, y por un gruñido en la perspectiva del equipo, realmente no puedo decir mucha diferencia. La mayoría de las diferencias que he visto son cosméticas. Por supuesto, no he intentado hacer ninguna bifurcación/fusión en ninguna de las dos, pero como codificador que entra, comprueba archivos, trabaja en esos archivos y los revisa al final del día, ¿por qué querría 1 sobre el ¿otro?

Answer 1

"Visual SourceSafe? Sería más seguro imprimir todo su código, ejecutarlo a través de una trituradora y prenderle fuego. " - (Atribuido a un empleado de Microsoft no identificado).

SourceSafe tiene muchos problemas y no tiene funciones de canje. Hay varias alternativas disponibles y multiplataforma que son más seguras, más rápidas y más potentes. La subversión es probablemente la más utilizada de estas. Algunas personas prefieren sistemas de control de versiones distribuidas como Git, Mercurial o Bazaar.

leer un poco acerca de por qué es tan malo VSS:

• Visual SourceSafe: Microsoft's Source Destruction System
• Visual SourceSafe Version Control: Unsafe at any Speed?
• (Y my own experiences)

Answer 2

Lo remito a las respuestas a What is so great about Subversion?.

Answer 3

Microsoft, que hace que Visual Source Safe, no lo use internamente para proyectos de cualquier tamaño significativo. Esa es una marca importante en contra, en mi libro. Y al usarlo para proyectos grandes, entiendes por qué; es LENTO, y Dios te ayude si alguna vez decides dejar que se fusione automáticamente algo.

Answer 4

VSS tiene una historia realmente mala que tiene que superar. Las versiones más recientes parecen ser más estables, pero todavía tiene una tonelada métrica de equipaje negativo que está cargando.

Answer 5

Mi penúltimo una compañía cambiaron de VSS a SVN debido

1. expansión. La cantidad de programadores se duplicó y no deseamos desembolsar las licencias de VSS adicionales
2. Errores. VSS es bueno para mantener la última versión de un archivo, pero las historias a menudo se corrompen.
3. Más errores. Las herramientas de comprobación/recuperación fueron inútiles, ya que comenzaron a fallar cuando la base de datos se hizo muy grande.

Answer 6

SVN tiene algunas características importantes sobre CVS/VSS, como compromisos atómicos, copias baratas, almacenamiento más eficiente en el lado del servidor.

SVN no es, sin embargo, el único sistema de control de revisiones disponible ... Hay muchas aplicaciones diferentes de control de revisiones. Una nueva tendencia parece ser hacia el control de revisión distribuida, como Git o Mercurial.

Answer 7

Bien CVS y VSS son prácticamente lo mismo en cuanto a la funcionalidad. Entonces no son un buen punto de partida para comparar cada uno de ellos.

Sin embargo, probablemente nunca verás una diferencia entre SVN y VSS si solo los usas como un gruñido en el equipo. Realmente tiene que empezar a usarlos como administrador de proyectos para ver realmente las diferencias, como ramificación, fusión, etc.

Answer 8

SVN funciona bien desde el punto de vista del desarrollador, pero la forma en que almacena la información de configuración en todo el árbol de directorios es Enloquecedor para los administradores del sistema (especialmente los encargados de moverlo a otro servidor cuando los desarrolladores se niegan a realizar un proceso de confirmación/re-revisión). :) ¡Entonces, no es TODA la bondad dorada!

Answer 9

VSS no es atomic, por lo que si recibe una actualización durante un check-in grande de otro usuario, se producirá un archivo incompleto. Esto también empeora si trabaja en una WAN debido al diseño de VSS para trabajar con las acciones.

Answer 10

De hecho, creo que Perforce es la bondad dorada. Las herramientas de GUI son lo suficientemente buenas como para poder dárselas a un diseñador o artista y hacer que usen el control de código fuente como nosotros desarrolladores. Estoy bastante seguro de que la ventana Archivo VSS-> Agregar archivos es anterior a Windows 95.Todo el concepto de archivos en uso bloqueados es absurdo. ¿No lo resolvimos hace décadas con el control de versiones CONCURRENT? He sufrido corrupción en la historia y (corríjanme si me equivoco), pero VSS ni siquiera admite sucursales y fusiones.

Answer 11

Debe ejecutar desde VSS tan pronto como sea posible. Si no has tenido problemas con esto en el pasado, deberías hacerlo. Es como una bomba de tiempo de la ruleta rusa: nunca se sabe cuándo va a explotar.

SVN es una gran herramienta y muy fácil de configurar, administrar. Las herramientas de administración para realizar copias de seguridad o replicar son muy buenas.

Recomendaría SVN sobre VSS anyday.

Answer 12

sé que es fácil de recoger en VSS, pero es importante recordar algunas cosas (salir de las malas hierbas por un segundo!)

• Para los pequeños equipos de desarrollo de Microsoft, VSS es una solución muy fácil de implementar, donde la alternativa es NO CONTROLAR LA VERSIÓN.
• VSS no tiene costo, no requiere ningún servidor (que no sea un recurso compartido de archivos).
• El demoninador común más bajo.
• Por lo general, funciona, y varias tiendas lo usan.
• Preferiría tener VSS como opción que para que no exista.

No tiene porque estar de acuerdo conmigo en todos estos puntos, solo estoy demostrando que tiene su lugar, y tiene valor en diferentes escenarios.

Answer 13

El viejo argumento de integración en Visual Studio ya no funciona. AnkhSVN 2.0 ofrece una solución integrada y VisualSVN integra TortoiseSVN en Visual Studio.

Y TortoiseSVN es suficiente razón para cambiar para muchos usuarios.

Answer 14

Tengo problemas con VSS con el código de Java. Mientras que es una getLatestVersion, VSS no puede manejar la estructura anidada de proyectos y paquetes en java. Obtuve estructuras de carpetas inifitas para el mismo. SVN es bastante simple en este sentido.