VSS o SVN para un proyecto .Net?

Question

En el trabajo, uno de los directores me pidió que investigara cuáles podrían ser los beneficios de cambiar el servidor de control de fuente actual (Visual Source Safe) de mi proyecto a SVN.

Realmente no tengo nada en contra de SVN, en realidad lo entiendo, pero en mi humilde opinión, cambiar a SVN no traerá ningún beneficio significativo al proyecto, y nos obligará a usar un tercero herramientas para administrar el control de código fuente desde Visual Studio (desarrollamos usando principalmente herramientas de Microsoft).

Entonces, como primer paso en mi investigación, le pregunto: ¿cuáles podrían ser los beneficios de cambiar de VSS a SVN?

Answer 1

SVN es más popular que VSS y tiene muchas ventajas. VSS es viejo y desactualizado.

• Why Not VSS
• Visual SourceSafe: Microsoft's Source Destruction System
• Source Control: Anything But SourceSafe
• Visual SourceSafe Version Control: Unsafe at any Speed?

Muchos desarrolladores hoy en dia están pasando de VSS a SVN. Si busca "SVN" y "VSS" en Google, le mostrará muchos artículos relacionados con VSS to SVN migration.

• El modelo de bloqueo-modificación-desbloqueo VSS hace que la colaboración en archivos que cambian rápidamente sea un gran dolor de cabeza. Además de la sobrecarga de necesitar un administrador para desbloquear archivos que alguien ha revisado mientras están de vacaciones.
• Con VSS, no se trata de perder datos, es CUANDO. Se supone que su repositorio de origen es una piedra; si la estación de trabajo de un desarrollador se bloquea, solo debería haber perdido los cambios de HIS. No debe perder archivos y datos aleatorios del repositorio
• VS no ha sido actualizado por MS en más de 6 años. ¿Ya puedes obtener apoyo para eso?
• Dependiendo de sus herramientas de respaldo, es posible que no pueda obtener una copia de seguridad completa de su repositorio VSS si solo le queda una persona conectada al servidor (lo que significa que dejaron abiertas sus herramientas de desarrollo o dejaron funcionando al cliente VSS) .
• VSS requiere que todos los usuarios tengan un control casi completo, a nivel del sistema de archivos (permisos NTFS), de los archivos que componen el repositorio.
• No existe una API publicada buena, utilizable y fácilmente disponible para VSS y las herramientas de terceros son, en general, débiles.
• La fusión es una mierda en VSS.
• VSS: si tiene desarrolladores distribuidos en varias zonas horarias, el solo hecho de que ambas puedan registrarse puede dañar la base de datos si se registran demasiado juntas, en el orden incorrecto.

Ahora bien, esto no quiere decir que Subversion sea irreprochable, sin duda hay cosas que podría hacer mejor y cosas que no funciona en absoluto. Pero es muy probable que todas las personas que trabajaron con VSS y SVN nunca regresen a VSS.

---

Si elige SVN.Aquí está una lista de herramientas que pueda necesitar:

• AnkhSVN es un proveedor de Subversion SourceControl para Visual Studio.
• RapidSVN es un cliente de Subversion multiplataforma.
• TortoiseSVN es un software de control SCM/fuente fácil de usar para Microsoft Windows y tal vez el mejor cliente de Subversion independiente que existe.
• VisualSVN es un complemento de Visual Studio que integra Subversion y TortoiseSVN sin problemas con Visual Studio.
• VisualSVN Server es un paquete que contiene todo lo que necesita para instalar, configurar y administrar el servidor de Subversion para su equipo en la plataforma de Windows. Incluye Subversion, Apache y una consola de administración.

---

Aquí es un gran libro sobre este tema: Version Control with Subversion por C Pilato

Version Control with Subversion http://ecx.images-amazon.com/images/I/51iwjNGkQdL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg

---

Otra buena alternativa a VSS y SVN es SourceGear Fortress que cuenta con sistema de seguimiento de problemas, además para controlar la fuente, todo en uno. O SourceGear Vault - control de fuente solamente. También hay una solución SourceAnyWhere. Si necesita la solución de Microsoft, vaya con TFS en lugar de VSS.

Answer 2

Evitar los dolores de cabeza de una caída de la base de datos de Source Safe teniendo toda su base de código con ella es una gran noticia.

No tener que preocuparse de a quién se le ha quitado un archivo es otro.

Answer 3

Encuentro que la fusión de archivos con VSS es muy engorrosa, pero es genial con SVN. Además, y no tengo ninguna evidencia de esto, pero SVN parece más rápido.

Answer 4

VSS es antiguo y desactualizado. La base de datos se corrompe con demasiada frecuencia. Hay una razón por la cual MS también creó TFS.

SVN es muy popular (lo que significa mucho soporte de la comunidad, lo que significa soporte gratuito), hay muchas herramientas que se conectan a él (CruiseControl para integración continua, por ejemplo) y es bastante simple de usar.

Tienes que considerar que hay una curva de aprendizaje si ya usas VSS y eso es algo que tienes que sopesar en tu investigación. Si los otros desarrolladores no han usado SVN (o CVS), entonces podría ser costoso, aunque lo único que necesita es una persona que realmente conozca el sistema y luego entrene al resto.

Cambiamos de VSS a SVN hace 4 años y no hemos mirado hacia atrás desde entonces.

Answer 5

SourceGear Vault es un excelente reemplazo para VSS. Comenzó siendo "funciones de VSS pero usando una base de datos real", y creció a partir de ahí.

Answer 6

Solo como un lado, hemos estado utilizando Sourcegear Vault durante varios años muy felizmente.Tener repositorios y una base de datos central de SQL Server junto con un excelente acceso a través de los internets lo convirtieron en un éxito para nuestra organización.

Creo que tiene un precio razonable y al menos vale la pena echarle un vistazo.

Answer 7

Casi Definitivamente SVN. SVN tiene una forma diferente de trabajar (copiar-modificar-fusionar en lugar de bloquear-modificar-desbloquear). Es un poco una curva de aprendizaje, pero es la forma en que las cosas han ido durante varios años, por lo que la mayoría de los desarrolladores tendrán que aprender en algún momento u otro de todos modos. Bloquear-Modificar-Desbloquear es demasiado doloroso, y existen serios problemas de colaboración a los que realmente contribuye, que me complacería explicar si tienes curiosidad.

Resolviendo los comentarios sobre qué tan malo es VSS también. Aquí hay varios enlaces que cubren el tema:

http://www.codinghorror.com/blog/archives/000660.html

http://www.developsense.com/testing/VSSDefects.html

http://wadhome.org/svn_vs_vss.html

Editar: Ver también: Source Control - Lock vs. Merge?

Answer 8

Microsoft ha admitido que nunca se utiliza VSS en cualquiera de sus proyectos internos (no puede encontrar la referencia en este momento: /). Lo usé durante dos años y fue estúpidamente malo. La base de datos estaba corrupta al menos una vez a la semana.

Además, una de mis cosas favoritas para citar a los usuarios de VSS es la primera cita en Eric Wadworth's página, según los informes de alguien de Microsoft:

"Visual SourceSafe? It would be safer to print out all your code, 
run it through a shredder, and set it on fire." 

En definitiva, con SVN. VSS es como las pesadillas de 1000 demonios.

Answer 9

AnkhSVN 2.0 es realmente muy bueno.

Si tenía la integración de Visual Studio como requisito, habría advertido contra SVN incluso hace un año, pero eso ha cambiado a lo grande. Todavía no es tan bueno como, digamos, VS Team System, pero es mucho mejor que la antigua integración VSS basada en MSSCCI. No hay razón para no usar SVN con .NET.

Answer 10

Otro "definitivamente SVN" vota aquí. Fui parte de un equipo de migración en un trabajo anterior. No puedo decirte lo lindo que fue deshacerse de VSS.

• repositorios No más corruptos
• Mucho mejor fusión
• Así mucho más rápido
• barato y fácil de ramificación
• No más exclusiva de bloqueo
• Pedido la fuente a múltiples ubicaciones muy fácil

Podría seguir, pero los recuerdos de los grilletes VSS son demasiado dolorosos. Solo di no.

Answer 11

Considere una herramienta más moderna como Git, Mercurial o Darcs.Hay muchas ventajas, dejaré Google como un ejercicio para el lector.

Answer 12

Utilizamos SVN donde trabajo y con la documentación correcta, el cliente adecuado y las herramientas es muy fácil: hasta ahora es muy confiable trabajar con él. Después de haber pasado los últimos 10 años con VSS puedo decir que no lo extraño un poco.

Me gusta SVN tanto que escribí una reseña de lo que considero que son los clientes más valiosos (algunos no) y herramientas adicionales. Este es un nuevo artículo por lo que es muy oportuno: http://codertools.wordpress.com/2009/03/24/svn-subversion-clients-and-other-tools/

No dudaría en recomendar SVN a nadie - GIT es el siguiente en mi lista para mirar .. Espero que esto sea útil.

Answer 13

Hablando como alguien que pasó por el proceso de transición VSS -> SVN para una gran base de código, yo diría que la mayor ventaja es poder dormir profundamente sabiendo que su sistema SCM no tendrá repentinamente un problema que corrompa su base de datos y usted tiene que volver a la copia de seguridad de ayer. Usted hace una copia de seguridad de su base de datos a diario, ¿verdad?

Con VSS, la corrupción ocurrió al menos una vez al mes. Con SVN (mismo hardware & OS), no una vez en más de dos años.

¡Ah, y las capacidades de bifurcación/fusión son dulces!

Answer 14

Solo una adición a la respuesta de Koista Navin.

Él dijo: Aquí es un gran libro sobre este tema: Control de versiones con Subversion por C Pilato

Hay una versión en línea gratis:

http://svnbook.red-bean.com/

Answer 15

Definitivamente, ir con SVN, por todos los motivos mencionados anteriormente. Puedes probarlo ankhsvn que es un plugin svn para visual studio. De esta forma, obtienes lo mejor de ambos mundos: usando SVN y todo el trabajo se hace dentro de Visual Studio.

Answer 16

Team Foundation Server es la elección óptima para desarrollar en el mundo .NET. Sin embargo, no es gratis y para la versión actual 2008 puede ser bastante caro. Si tiene un paquete de nivel superior para Visual Studio, obtiene la edición de grupo de trabajo TFS de forma gratuita, lo que permite el acceso de 5 usuarios sin costo adicional.

Hay algunas advertencias importantes para la edición del grupo de trabajo; debe usar uno de los 5 espacios para la cuenta de servicio TFS a menos que lo configure para que se ejecute en una cuenta de usuario que se incluirá en la lista de miembros de TFS. La otra es que una vez que alcances tu límite de 5 usuarios, el salto a 6 usuarios es un costo bastante asombroso ya que los requisitos de licencia actuales incluyen la necesidad de comprar el servidor (unos miles de dólares) Y CAL para cada miembro del equipo. Ese es un costo bastante prohibitivo para agregar un miembro más al equipo.

Sin embargo, Microsoft se ha dado cuenta de esto y lo está cambiando para 2010. Ya no tendrá que comprar el servidor y solo tendrá que comprar CAL. TFS 2010 server licensing: It's included in MSDN subscriptions