.net - tag - tortoise svn server
¿VSS o SVN para un proyecto.Net? (16)
Casi definitivamente SVN. SVN tiene una forma diferente de trabajar (Copiar-Modificar-Fusionar en lugar de Bloquear-Modificar-Desbloquear). Es un poco de una curva de aprendizaje, pero es la forma en que han ido las cosas durante varios años, por lo que la mayoría de los desarrolladores tendrán que aprenderlo en algún momento u otro. Bloquear-Modificar-Desbloquear es demasiado doloroso, y hay problemas serios de colaboración a los que realmente contribuye, que me encantaría explicarte si sientes curiosidad.
Segundando los comentarios sobre lo malo que 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 vs. Fusionar?
En el trabajo, uno de los gerentes principales me pidió que investigue cuáles podrían ser los beneficios de cambiar el servidor de control de fuente actual (Visual Source Safe) a mi 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 para el proyecto, y nos obligará a usar algunas herramientas de terceros para administrar el control de fuente desde Visual Studio (desarrollamos utilizando 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?
Definitivamente, vaya con SVN, por todas las razones mencionadas anteriormente. Puedes probarlo AnkhSVN que es un complemento svn para visual studio. De esta manera, obtienes lo mejor de ambos mundos: usar SVN y todo el trabajo aún se realiza dentro de Visual Studio.
Dejando de lado, hemos estado utilizando Sourcegear Vault durante varios años de forma bastante feliz. Tener repositorios y una base de datos central de SQL Server, junto con un gran acceso a través de Internet, lo convirtió en un slam dunk para nuestra organización.
Creo que tiene un precio razonable y al menos vale la pena echarle un vistazo.
Encuentro que combinar archivos con VSS es muy engorroso, pero es bueno con SVN. Además, y no tengo ninguna evidencia de esto, pero SVN parece más rápido.
Evitar los dolores de cabeza de una falla de la base de datos de Source Safe al llevar todo su código base es un problema.
No tener que preocuparse por quién tiene un archivo desprotegido es otra.
Hablando como alguien que pasó por el proceso de transición VSS -> SVN para una base de código grande, diría que el mayor beneficio es poder dormir profundamente sabiendo que su sistema SCM no tendrá de repente un problema que corrompa su base de datos y tiene que volver. a la copia de seguridad de ayer. Usted hace una copia de seguridad de su base de datos diariamente, ¿verdad?
Con VSS, la corrupción ocurrió al menos 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 ramificación / fusión son dulces!
Microsoft ha admitido que nunca ha usado VSS en ninguno de sus proyectos internos (aunque ahora no puedo encontrar la referencia: /). Lo utilicé durante dos años y fue estúpidamente malo. La base de datos se corrompió 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 la página de Eric Wadworth , según 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."
Definitivamente vamos con SVN. VSS es como las pesadillas de 1000 demonios.
Otro voto "definitivamente SVN" aquí. Formé parte de un equipo de migración en un trabajo anterior. No puedo decirle lo bueno que fue deshacerse de VSS.
- No más repositorios corruptos.
- Mucho mejor fusionando
- Mucho mas rapido
- Ramificación barata y fácil.
- No más bloqueo exclusivo.
- Checkout la fuente a múltiples ubicaciones muy fácilmente
Podría seguir, pero los recuerdos de las cadenas VSS son demasiado dolorosos. Solo di no.
SVN es más popular que VSS y tiene muchas ventajas. VSS es viejo y obsoleto.
- ¿Por qué no VSS?
- Visual SourceSafe: Sistema de destrucción de fuentes de Microsoft
- Control de fuente: Cualquier cosa menos SourceSafe
- Control de versión de Visual SourceSafe: ¿inseguro a cualquier velocidad?
Muchos desarrolladores hoy en día se están moviendo de VSS a SVN. Si busca "SVN" y "VSS" en Google, le mostrará muchos artículos relacionados con la migración de VSS a SVN .
- El modelo de bloqueo-modificación-desbloqueo de 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 los archivos que alguien ha revisado mientras están de vacaciones.
- Con VSS, no se trata de si perderá datos, es CUÁNDO. Se supone que su repositorio de origen es una roca: si la estación de trabajo de un desarrollador falla, solo debería haber perdido sus cambios. No debes perder archivos y datos aleatorios del repositorio.
- VSS no ha sido mantenido por MS en más de 6 años. ¿Puedes incluso obtener soporte para eso más?
- Dependiendo de sus herramientas de copia de seguridad, es posible que no pueda obtener una copia de seguridad completa de su repositorio de VSS si solo tiene una persona que ha iniciado sesión en el servidor (lo que significa que dejó sus herramientas de desarrollo abiertas o dejó el cliente de VSS en ejecución).
- VSS requiere que todos los usuarios tengan un control casi completo, a nivel del sistema de archivos (permisos NTFS), de los archivos que conforman el repositorio.
- No hay una API publicada buena, utilizable y fácilmente disponible para VSS y las herramientas de terceros son débiles en su mayor parte.
- La fusión chupa en VSS.
- VSS: si tiene desarrolladores distribuidos en varias zonas horarias, el simple hecho de que ambos ingresen puede corromper la base de datos si ingresan demasiado cerca, en el orden incorrecto.
Ahora, esto no quiere decir que Subversion sea impecable: ciertamente hay cosas que podría hacer mejor y cosas que no hace en absoluto. Pero todas las personas que trabajaron con VSS y SVN probablemente nunca regresarán a VSS.
Si vas a elegir SVN. Aquí hay una lista de herramientas que puede necesitar:
- AnkhSVN es un proveedor de Subversion SourceControl para Visual Studio.
- RapidSVN es un cliente Subversion multiplataforma.
- TortoiseSVN es un software de control de fuente / SCM fácil de usar para Microsoft Windows y quizás 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 paquete que contiene todo lo que necesita para instalar, configurar y administrar el servidor de Subversion para su equipo en la plataforma Windows. Incluye Subversion, Apache y una consola de gestión.
Aquí hay un gran libro sobre este tema: Control de versiones con Subversion por C Pilato
Otra buena alternativa a VSS y SVN es SourceGear Fortress, que tiene un sistema de seguimiento de problemas además del control de origen, todo en uno. O SourceGear Vault : solo control de fuente. También hay SourceAnyWhere solución de SourceAnyWhere . Si necesita una solución de Microsoft, vaya con TFS en lugar de VSS.
Solo una adición a la respuesta de Koista Navin.
Dijo: Aquí hay un gran libro sobre este tema: Control de versiones con subversión por C. Pilato
Hay una versión gratuita en línea:
SourceGear Vault es un excelente reemplazo para VSS. Comenzó siendo "características de VSS pero usando una base de datos real", y creció a partir de ahí.
Team Foundation Server es la opción óptima para desarrollar en el mundo .NET. Sin embargo, no es gratis y para la versión actual 2008 puede ser bastante costoso. Si tiene un paquete de nivel superior para Visual Studio, puede obtener la edición del grupo de trabajo TFS de forma gratuita, lo que permite el acceso de 5 usuarios sin costo adicional.
Hay algunas advertencias importantes en la edición del grupo de trabajo: debe usar una de las 5 ranuras para la cuenta de servicio de TFS, a menos que la configure para ejecutarse en una cuenta de usuario que se incluirá en la lista de miembros de TFS. La otra es que una vez que llegue a su límite de 5 usuarios, el salto a 6 usuarios es un costo bastante asombroso, ya que los requisitos de la licencia actual incluyen la necesidad de comprar el servidor (unos pocos 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á modificando para 2010. Ya no tendrá que comprar el servidor y solo tendrá que comprar CALs. Licencia de servidor TFS 2010: se incluye en las suscripciones de MSDN
Usamos SVN donde trabajo y con la documentación correcta, el cliente y las herramientas correctos es muy fácil, hasta ahora es altamente confiable para trabajar. Después de haber pasado los últimos 10 años con VSS, puedo decir que no me lo pierdo ni un poco.
Me gusta SVN tanto que escribí una reseña de lo que considero que son los clientes más valiosos (algunos no lo son) y herramientas adicionales. Este es un nuevo artículo, por lo que es muy oportuno: codertools.wordpress.com/2009/03/24/…
No dudaría en recomendar SVN a nadie: GIT es el siguiente en mi lista para ver ... Espero que esto sea útil.
VSS es viejo y obsoleto. La base de datos se corrompe demasiado a menudo. Hay una razón por la cual MS construyó TFS también.
SVN es muy popular (lo que significa mucho apoyo comunitario, es decir, soporte gratuito), hay muchas herramientas que se conectan a él (CruiseControl for Continuous Integration, por ejemplo) y es bastante simple de usar.
Debe tener en cuenta que hay una curva de aprendizaje si ya está utilizando VSS y eso es algo que debe evaluar en su investigación. Si los otros desarrolladores no han usado SVN (o CVS), podría ser costoso, aunque todo lo que necesita es una persona que realmente conozca el sistema y luego capacite al resto.
Hace 4 años cambiamos de VSS a SVN y desde entonces no hemos mirado atrás.
AnkhSVN es realmente muy bueno.
Si tuviera la integración de Visual Studio como un requisito, habría advertido contra SVN incluso hace un año, pero eso ha cambiado en gran medida. Todavía no es tan bueno como, digamos, VS Team System, pero es mucho mejor que la integración de VSS basada en MSSCCI. No hay razón para no usar SVN con .NET.