VSS o SVN para un proyecto .Net?

En el trabajo, uno de los directores me pidió que investigara cuáles podrían ser los beneficios de cambiar el actual server de control de fuente (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 algunas herramientas de terceros para administrar el control de fuente de 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?

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

  • Por qué no VSS
  • Visual SourceSafe: el sistema de destrucción de fonts de Microsoft
  • Control de fuente: todo less SourceSafe
  • Control de versión de Visual SourceSafe: ¿inseguro a cualquier velocidad?

Muchos desarrolladores ahora se están moviendo de VSS a SVN. Si busca "SVN" y "VSS" en Google, le mostrará muchos artículos relacionados con la migration de VSS a SVN .

  • El model de locking-modificación-deslocking de VSS hace que la queueboración en files que cambian rápidamente sea un gran dolor de cabeza. Además de la sobrecarga de necesitar un administrador para desbloquear files que alguien ha revisado mientras están de vacaciones.
  • Con VSS, no se trata de perder datos: es CUANDO. Se supone que su repository 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 files y datos aleatorios del repository
  • VS no ha sido mantenido por MS en más de 6 años. ¿Ya puedes get apoyo para eso?
  • Dependiendo de sus herramientas de respaldo, es posible que no pueda get una copy de security completa de su repository de VSS si solo le queda una persona conectada al server (lo que significa que dejaron abiertas sus herramientas de desarrollo o dejaron en ejecución el cliente de VSS).
  • VSS requiere que todos los usuarios tengan un control casi total, a nivel del sistema de files (permissions NTFS), de los files que componen el repository.
  • No existe una API publicada buena, utilizable y de fácil acceso para VSS, y las herramientas de terceros son débiles en su mayor parte.
  • 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 database si se registran demasiado juntas, en el order incorrecto.

Ahora bien, esto no quiere decir que Subversion sea impecable; 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í hay una list de herramientas que puede necesitar:

  • AnkhSVN es un proveedor de control de fuente de Subversion para Visual Studio.
  • RapidSVN es un cliente de Subversion multiplataforma.
  • TortoiseSVN es un software SCM / control de origen 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 a la perfección con Visual Studio.
  • VisualSVN Server es un package que contiene todo lo que necesita para instalar, configurar y administrar el server de Subversion para su equipo en la plataforma de Windows. Incluye Subversion, Apache y una console de administración.

Aquí hay un gran libro sobre este tema: Control de versiones con Subversion de C Pilato

Control de versiones con 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 para VSS y SVN es SourceGear Fortress, que tiene el sistema Issue Tracking además del control de fuente, todo en uno. O SourceGear Vault : solo control de origen. También existe la solución SourceAnyWhere . Si necesita la solución de Microsoft, vaya con TFS en lugar de VSS.

Microsoft ha admitido que nunca usa VSS en ninguno de sus proyectos internos (aunque ahora no puede encontrar la reference: /). Lo usé durante dos años y fue estúpidamente malo. La database estaba corrupta al less una vez a la semana.

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

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

Definitivamente ve con SVN. VSS es como las pesadillas de 1000 demonios.

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

Usamos SVN donde trabajo y con la documentation 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 tanto SVN 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 cualquiera: GIT es el siguiente en mi list para mirar. Espero que esto sea útil.

Evitar los dolores de cabeza de una caída de la database de Source Safe llevándose toda su base de código es una gran cosa.

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

Encuentro que fusionar files con VSS es muy engorroso, pero es genial con SVN. Además, y no tengo ninguna evidencia de esto, pero SVN parece más rápido.

VSS es viejo y desactualizado. La database 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 continuous integration, por ejemplo) y es bastante simple de usar.

Debes considerar que hay una curva de aprendizaje si ya usas VSS y eso es algo que debes 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 rest.

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

Solo como un lado, hemos estado usando Sourcegear Vault durante varios años bastante feliz. Tener repositorys y una database 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 less vale la pena echarle un vistazo.

AnkhSVN 2.0 es realmente muy bueno.

Si tuviera 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, por ejemplo, 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.

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

  • No más repositorys corruptos
  • Mucho mejor fusión
  • Mucho más rápido
  • Ramificación barata y fácil
  • No más locking exclusivo
  • Verifique la fuente a múltiples ubicaciones de manera muy fácil

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

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

Casi Definitivamente SVN. SVN tiene una forma diferente de trabajar (copyr-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 queueboración a los que realmente contribuye, que me gustaría explicar si tienes curiosidad.

Seconding 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: Control de fuente – ¿Bloquear contra combinar?

Hablando como alguien que pasó por el process de transición VSS -> SVN para una gran base de código, yo diría que el mayor beneficio es poder dormir profundamente sabiendo que su sistema SCM de repente no tendrá un inconveniente que corrompa su database y usted tiene que retroceder a la copy de security de ayer. Usted hace una copy de security de su database a diario, ¿verdad?

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

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

Definitivamente, vaya con SVN, por todos los motivos mencionados anteriormente. Podrías 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.

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

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

Hay una versión gratuita en línea:

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

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 package 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 count de service TFS a less que lo configure para que se ejecute en una count de usuario que se includeá en la list de miembros de TFS. La otra es que una vez que scopes tu límite de 5 usuarios, el salto a 6 usuarios es un costo bastante asombroso ya que los requisitos actuales de la licencia incluyen la necesidad de comprar el server (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 count de esto y lo está cambiando para 2010. Ya no necesitará comprar el server en sí y solo tendrá que comprar licencias CAL. Licencias de server de TFS 2010: está incluido en las suscripciones de MSDN