visual studio - tortoise - ¿Cómo puedo convencer a mi equipo para que deje de estar protegido por las fuentes y se mude a SVN?

visual studio code gitlab (30)

Confiabilidad

SVN es mucho más confiable con grandes bases de datos
SVN todavía es apoyado activamente
Confirmación atómica: en VSS cuando obtiene la versión más reciente mientras otro usuario realiza el checkin, puede obtener un estado incoherente, lo que le obliga a repetir la "Obtener la última versión" en un mejor caso, pero a veces, cuando tiene mala suerte, puede quedar con una base de código que compila pero no funciona Esto no puede suceder en SVN gracias a los compromisos atómicos.

Caracteristicas

SVN branch / merge es mucho mejor
SVN tiene soporte incorporado para acceso remoto
SVN es más configurable (integración de herramientas externas Diff / Merge)
SVN es más extensible (ganchos)

Mejor productividad

SVN "Update" es mucho más rápido en comparación con SS "Get latest version"
La línea de comando de SVN es mucho más fácil y más limpia, esto es útil para las herramientas automatizadas de compilación o prueba

El mismo nivel de integración IDE

VSS tuvo una mejor integración VS hasta hace poco, pero con AnkhSVN 2.0 esto ya no es cierto.

Abierto

SVN está abierto y hay muchas herramientas diferentes que usan SVN o cooperan con él. Algunos ejemplos incluyen:

integración con muchos rastreadores de errores o productos de gestión del ciclo del producto
integración de shell
integración en varios productos
varias herramientas de gestión y análisis
la fuente está disponible, puede ajustarla a su necesidad, solucionar los problemas (o contratar a alguien para que lo haga por usted) si surge la necesidad

Costo

No tiene que pagar ninguna licencia o cuota de mantenimiento

Mi equipo de desarrollo usa fuente segura en un nivel muy básico. Estamos avanzando en algunos ciclos de desarrollo más avanzados y extendidos, y no puedo evitar pensar que no utilizar bifurcaciones y fusiones para gestionar los cambios nos va a afectar muy pronto.

¿Qué argumentos le parecieron más útiles para convencer a su equipo de que busque una solución mejor, como SVN?

¿Qué programas usaste para cerrar la brecha de funcionalidad para que el equipo no se pierda la integración de idessafe?

¿O debería aceptar simplemente sourcesafe e intentar calzarme con mejores prácticas?

Cuando estaba en el lanzamiento de VS2005 logré acorralar a Microsofty y preguntar por qué SourceSafe era tan horrible de usar. La respuesta que obtuve fue bastante impactante, no solo por lo que dijo, sino porque estaba tan al tanto de lo que había dicho.

Me dijo que solo estaba destinado a que una persona lo usara y que incluso así no era muy bueno para hacerlo.

Mis colegas y yo estábamos un poco sorprendidos de que no pudiéramos pensar en otra cosa que hacer aparte de reírnos en voz alta, ¡como lo hizo la Microsofty! Luego nos dijo que no se usó internamente.

Entonces, cambiamos a subversión poco después de eso. Casi habíamos decidido apostar antes del evento de lanzamiento, pero eso solo confirmó que habíamos tomado la decisión correcta.

Dígales que lean esto just

Dígales que traten el código fuente como si fuera dinero y apúntenlos a los numerosos ejemplos de SourceSafe que cae en llamas y se lleva consigo la fuente. Cosas como esas simplemente no deberían suceder en un sistema de control de fuente apropiado.

El mejor argumento en contra de SourceSafe es que just isn''t Safe , todo lo demás puede denominarse "funciones que no necesitamos".

El complemento AnkhSVN para VS es bastante bueno. Tiene algunas rarezas, pero en general funciona bien.

Convencer al equipo de que se mude es un trabajo arduo; nunca lo logré :-( Probablemente uno de los argumentos más prácticos es la velocidad: VSS es lento cuando tienes una base de datos fuente de 1GB y varios usuarios.

edit ¡ Ha pasado tanto tiempo desde que utilicé VSS que olvidé que estaba bloqueado! Sí, como se menciona aquí, la posibilidad de pasar a un modelo de cambios no exclusivo / de fusión debería ser útil si tiene más de un puñado de desarrolladores. Ahorra gritando "¿Alguien puede verificar en el campo común?" En toda la oficina.

El factor decisivo para nosotros fue la velocidad (es decir, la falta) de VSS sobre VPN y redes de hoteles de ancho de banda bajo en la carretera y los problemas de tratar de atravesar los cortafuegos para que dos equipos en dos sitios diferentes pudieran realizar de forma rápida, segura y confiable trabajar desde el mismo repositorio de código. Estábamos ejecutando dos repositorios de VSS y empaquetando las "entregas" que debían fusionarse en el repositorio del otro sitio para mantenerlas sincronizadas.

El equipo gruñó por un momento, pero rápidamente lo superó. TortoiseSVN es fantástico en sí mismo y el complemento AnkhSVN para Visual Studio realmente facilitó el cambio a todos.

Mirando hacia atrás, no puedo creer cuántos "¿Puedes registrar el archivo SoAndSo?" correos electrónicos que enviamos, sin mencionar los correos electrónicos "SourceSafe no funciona. Tenemos que restaurar el repositorio".

Sheesh. Después de leer estos comentarios y escribir esta respuesta, no puedo creer que hayamos aguantado a VSS durante todo el tiempo que lo hicimos.

En primer lugar, documente todos los problemas que tenga que puedan rastrearse hasta las causas raíz dentro del sistema de control de origen. Mantenga un seguimiento de ellos durante un mes más o menos. Agregue las oportunidades perdidas como resultado de no usarlo. (Si dice "costos de oportunidad de no usar subversión", puede impresionar a un administrador de tipo MBA). Estas cifras son en realidad una subestimación del costo de oportunidad porque, presumiblemente, podría haber estado haciendo un trabajo que proporciona más de la tasa de valor de su factura por hora si no estuviera jugando con VSS.

Por ejemplo, ¿tiene problemas donde los archivos están bloqueados a los que debe acceder más de una persona? ¿Has tenido problemas con los controles parciales (no atómicos)? ¿Tiene problemas donde le resulta difícil realizar un seguimiento de las versiones del software y recrear el repositorio como lo hacía en el pasado? ¿Tiene problemas para obtener una copia del código en un servidor que no tiene un cliente de sourcesafe? ¿Tiene problemas para automatizar su proceso de compilación y prueba porque las herramientas de integración continua no pueden supervisar sus sistemas de control de versiones para las actualizaciones? Estoy seguro de que puedes pensar en muchos otros.

Si puede calcular el costo aproximado de tiempo / dinero de los problemas causados por la protección de fuentes y los beneficios de las cosas que proporciona la subversión (utilizando un número genérico como $ 100 / h para costos laborales o solo horas) y cualquier costo de entrega tardía de proyectos, hágalo . Si ha recopilado datos durante un mes más o menos, puede mostrar el beneficio utilizando la subversión por mes.

Luego, presente el tiempo / costo aproximado para pasar a la subversión. (Alrededor de 8 horas para configurar y migrar el código, y 2 horas por desarrollador para conectarse, pagar y mover proyectos, algo así) El riesgo es bajo, ya que SourceAfe todavía está ahí para deshacer.

Si el costo es más que el beneficio mensual, puede dividir el costo por el beneficio para calcular el período de recuperación. También debe sumarlo más de 3 años para mostrar el beneficio a largo plazo. Nuevamente, enfatice que el costo real de oportunidad no es directamente calculable porque podría haber estado agregando valor durante el tiempo que estuvo tratando de administrar lanzamientos no ramificados en sourcesafe.

Encuentre alguna excusa para comenzar a usar caracteres que no sean ASCII en su código C # (los chinos y los japoneses son excelentes para esto).

A SourceSafe no le gusta Unicode (aunque sí lo hace Visual Studio), por lo que si elige el texto Unicode correcto y verifica que un archivo entra y sale, todo su archivo aparecerá como un galimatías corrupto. La belleza de esto es que, debido a que SS usa un sistema de control de versiones "diff", esto en realidad corrompe el archivo hasta la versión original de check-in y no se puede corregir automáticamente.

Cuando esto ocurre solo una vez (como me sucedió a mí cuando trabajé en una aplicación que tenía que ser compatible con japonés), es probable que considere que es un argumento decisivo a favor de descartar SourceSafe.

Estoy planeando abandonar SourceSafe en las próximas semanas, después de más de una década de aguantarlo. Mayormente lo he usado dentro del contexto de un equipo pequeño (<5 personas), y no tuve que hacer muchas ramificaciones porque no ha habido llamadas para hacerlo.

Sin embargo, el problema n. ° 1 para mí, y siempre lo ha sido, es que la maldita cosa es tan propensa a la corrupción, si tiene su base de datos SS (lol, base de datos, colección de archivos aleatoriamente nombrados que la describe con más precisión) en una unidad de red , y algo le sucede a su conexión LAN parcialmente a través de una operación de agregar / registrar: 9 veces de cada diez obtiene "identificador inválido" y la maldita cosa está corrupta de alguna manera, y luego puede jugar a la Ruleta Rusa con la herramienta Analizador.

Me di cuenta, hace un par de meses, que durante la última década había estado haciendo copias comprimidas locales de la fuente en cada versión del software en el que estaba trabajando, porque no confiaba en el sistema de control de origen. Que perdida de tiempo.

Entonces, va. Probablemente usaré Subversion y TortoiseSVN, porque creo que el equipo necesitará una interfaz de usuario para facilitar la transición.

Hagas lo que hagas, ¡muévete lentamente! No comience a hablar con ellos sobre la bifurcación en el Día 1, simplemente los retrasará. Estoy estereotipando usuarios de VSS con ese comentario, pero eso es lo que veo por ahí.

Para los desarrolladores: venderlo como reemplazo de VSS que funciona mejor y más rápido. Use VisualSVN en el día 1 para que tengan una curva de aprendizaje súper superficial. Véndalos en él siendo lo mismo, excepto que es más rápido, más estable, y 2 personas pueden editar el mismo archivo y no tendrán problemas con que un tipo se enferme con bloqueos en un montón de archivos.

Para los administradores: venderlos es más estable y más fácil de administrar que VSS. Muéstrales el servidor VisualSVN .

¡Buena suerte!

Haz que lo usen y cambiarán a algo más :)

Ahora, hablando en serio, dígales que no es tan difícil usarlo, muchos desarrolladores que conozco se negaron a cambiar porque relacionaban la subversión con comandos unix y wierd, les mostraban interfaces como ToirtoiseSVN o VisualSVN, les decían que Subversion les permitía edite el mismo archivo sin un bloqueo forzado como lo hace VSS.

Y por último, pero no menos importante, es de código abierto. Tiene un costo menor que la compra de Team Foundation Server y si miras a tu alrededor verás que pequeños equipos de desarrolladores trabajan bastante bien con SVN.

Hubo dos características que utilizamos para vender la administración y el equipo en SVN sobre VSS.

1) La capacidad de ramificar. Cuando se utilizaba VSS, cuando se programó que saliera un lanzamiento, todo el repositorio se bloqueó hasta que el lanzamiento se cerró. Esto incluyó el ciclo de prueba y reparación. Por lo tanto, los desarrolladores no pudieron enviar nada más que soluciones para el lanzamiento al repositorio de VSS. Esto dio lugar a largas sesiones de integración inmediatamente después de cada lanzamiento. Con el uso de ramas de publicación en SVN, ya no es necesario bloquear el repositorio completo.

2) La capacidad de revertir un cambio completo a la vez. Debido a que SVN registra todos los archivos modificados en una sola confirmación atómica, es trivial revertir un cambio problemático. En VSS, un desarrollador tuvo que pasar por todo el repositorio y encontrar cada archivo cambiado aproximadamente al mismo tiempo y revertir cada cambio a cada archivo individualmente. Con SVN, esto es tan trivial como encontrar el compromiso relevante y presionar el botón "Revertir cambios de este compromiso" en TortoiseSVN.

Como nota al margen, usamos TortoiseSVN y todos adoran los iconos de superposición de archivos para ver qué ha cambiado y qué no.

La falta de fiabilidad de la fuente segura ("arregla el repositorio ...") fue suficiente para nosotros. Andecdotally (nunca lo he medido) SVN también siempre parece más rápido. Buena comprobación simultánea / fusión.

Siempre pensé que para un desarrollador era casi demasiado obvio. SourceSafe parece romperse y morir con demasiada frecuencia como para no querer reemplazarlo ...

Le recomendaría que siga adelante y comience a presentar las mejores prácticas para su uso de sourcesafe con vistas a cambiar a subversión más adelante. Esperamos que esto haga que su migración de subversión sea más fácil y le dé tiempo para ordenar sus ciclos de desarrollo, estrategias de ramificación, etc. correctamente.

La otra cosa a considerar es su proceso de desarrollo en general. Un sistema de administración de control de fuente solo forma parte de la solución, para aprovechar al máximo la subversión o cualquier otro producto, es probable que desee ver cómo su uso interactúa con la revisión del código, la qa y los procesos de compilación.

Mientras realiza estos argumentos, considere si necesita abordar cualquier política que su empresa pueda tener sobre el uso de herramientas de código abierto. Vea esta respuesta a una pregunta anterior: cambiar el control de la fuente

Nadie recomienda usar SourceSafe más, ni siquiera Microsoft. Ahora le ofrecerán una licencia (costosa) de TFS. SourceSafe simplemente no es confiable.

Escribí sobre esto aquí: Visual SourceSafe en E2 . Es un poco despotricar, pero eso se debe a que tuve que utilizar SourceSafe durante bastante tiempo, y el recuerdo me da un poco de espuma en la boca.

La confiabilidad es la más grande que te morderá. Pero también hay características que puedes apreciar en SVN o TFS:

Tanto TFS como SVN tienen confirmaciones atómicas de varios archivos, pero Sourceafe no lo hace: si ingresas dos archivos "a la vez", no es una operación, es lo mismo que registrar uno de los archivos y luego verificar el otro. Puede obtener el estado intermedio, donde se ha registrado un archivo, pero no el otro.

SourceSafe no mantiene el historial de archivos eliminados, archivos movidos o renombrados.

Contrariamente a las impresiones iniciales, SourceSafe sí admite pagos múltiples simultáneos del mismo archivo, si establece las opciones correctas. Pero TFS y especialmente SVN están mejor diseñados para esta forma de trabajar

A diferencia de SourceSafe, TFS y SVN funcionan bien contra servidores en Internet (TFS simplemente está bien, SVN es excelente) y SVN funciona bien fuera de línea - por ejemplo, si tiene una laptop en un avión o tren y no en red, puede trabajar y comparar a revisiones anteriores o incluso revertir, ya que los datos para hacer eso se llevan a cabo localmente.

Como alguien más señaló, SourceSafe, como CVS, es un producto "muerto". No se está desarrollando activamente. TFS y SVN tendrán próximas versiones en algún momento en el futuro.

No recuerdo que a ningún usuario de SourceSafe le haya gustado el producto. ¿A tus colegas realmente les gusta?

Tengo un problema similar con CVS en el uso de mis clientes actuales. Como "funciona" y están muy contentos con él, no puedo presionarlos para que cambien. Pero todos los días, ¡ojalá lo hicieran!

Pasamos de SourceSafe a Source Gear Vault. Este motor de control de fuente es muy cómodo para alguien acostumbrado a SourceSafe. Finalmente decidimos hacer el cambio después de un par de incidentes de corrupción de SourceSafe, que se produjeron en momentos críticos. Así que mi consejo sería enfocar su presentación de ventas en la falta de fiabilidad de SourceSafes.

Primero busque en google la gran cantidad de páginas que describen qué tan malo es VSS y compártalas con sus compañeros de trabajo.

En segundo lugar, omita la subversión e ir directamente a un SCM correctamente distribuido como git o mercurial . Debido a que la fusión es una parte tan inherente de los SCM distribuidos, tienen que manejar fusiones mucho mejor que los sistemas centralizados como svn. Subversion todavía está tratando de modernizarse para manejar mejor la bifurcación, donde los sistemas distribuidos se construyeron correctamente para empezar.

Primero, enséñeles a usar SourceSafe de una manera eficiente.

Si son lo suficientemente inteligentes, comenzarán a amar las ventajas de usar un sistema de control de versiones, y si es así, pronto alcanzarán los límites de SourceSafe. Ahí es donde estarán más capacitados para escuchar sus argumentos para cambiar a un VCS mejor, podría ser un CVCS o un DVCS, dependiendo de lo que el equipo esté listo para lograr.

Si intenta obligarlos a usar otro VCS cuando usan SourceSafe de una manera incorrecta, como guardar el archivo zip del código fuente (no se rían, así es como estaban actuando en mi compañía hace dos años), serán completamente reacios a cualquier argumentación, tan buena como podría ser.

Si usa VisualSVN, el equipo no echará mucho de menos a VSS. Dos personas que pueden trabajar en un archivo al mismo tiempo también son un gran punto de venta.

Sin duda, usar una fuente segura es motivo suficiente para querer migrar a otro sistema de control de origen.

Utilicé SVN y CVS en mi antiguo trabajo y me he mudado a una empresa que usa Source safe (vamos a migrar a SVN) y el solo uso de VSS ha sido suficiente para que me desagrade profundamente. Entré con una mente abierta, a pesar de que muchos de mis colegas de mi trabajo anterior me contaron historias de horror sobre VSS. Supuse que habría mejorado desde que lo usaron.

No poder editar un archivo porque alguien más está / estaba editando es ridículo. Intenté pasar a sistemas de control de versiones más distribuidos, como Bazzar, que está hecho por un método canónico, pero que no es lo suficientemente maduro en cuanto a las herramientas disponibles.

Source Safe se interpone en el desarrollo donde SVN te ayuda casi en cada paso del camino.

Además, el uso de Tortoise Svn hizo que las revisiones de códigos fueran mucho más sencillas.

Solíamos usar SourceSafe. Luego, cuando me uní al equipo, estaba en una ubicación diferente y aunque tenemos una LAN bastante buena cuando traté de ver la última versión, tardé 40 minutos. Los convencí de convertir a CVS (ahora usamos SVN) y el tiempo de salida se redujo a un par de minutos. SourceSafe era demasiado lento para ser utilizable en una ubicación remota.

Solo en la medida en que puedas agrupar a un grupo de gatos. Estuve allí dos veces y en ambos casos me costó algunos problemas serios en Source Safe antes de que la gente viera la luz. Como gerente, por otro lado, simplemente orienté al equipo a utilizar SVN y nuestra productividad aumentó en un 300% (esto fue trabajar con un grupo en India y en los EE. UU. Tuvimos intercambios de código que solían tardar mucho antes de svn)

También Trac se monta encima de Subversion. Es gratis y una excelente manera de ver el repositorio (línea de tiempo, wiki, etc.)

Usé SourceSafe en un pequeño equipo de desarrollo y fui responsable de mantenerlo en funcionamiento.

Descubrí que la base de datos se corrompe con bastante facilidad, y no hay mucho recurso cuando eso sucede. La característica de "reparación" (como con la mayoría de las características de reparación de Microsoft) simplemente no funciona el 98% del tiempo.

Naturalmente, cuando nuestra base de datos se corrompió, tratamos de restaurar desde nuestro archivo de copia de seguridad. Fue entonces cuando descubrimos otra cosa mala sobre SourceSafe: su límite de archivo de 2GB. Estuvimos haciendo copias de seguridad en nuestra oficina durante meses antes de darnos cuenta de que no podían restaurarse y que eran inútiles.

SourceSafe es solo un desastre esperando a suceder.

Usted dice "¿Qué argumentos le parecieron más útiles para convencer a su equipo de que busque una solución mejor, como SVN?"

Si no sabes que es una solución mejor, entonces ¿por qué estás argumentando? Si su mente está hecha lo suficiente como para buscar una solución, debe saber cuáles son esas razones.

¿Qué lo convenció de que debería mudarse a algo mejor? Esos son tus argumentos allí mismo. Cualquier cosa menos que esos argumentos sonará como si fuera solo una cuestión de preferencia personal.

TortoiseSvn (gratis) es realmente bueno para la integración del explorador, dándole todas las características de svn desde un menú contextual.

VisualSvn (comercial) facilita la integración de svn en Visual Studio, con la misma indicación de estado en el navegador de soluciones y menús contextuales para usar todas las funciones de subversión.

Ambas herramientas hacen un largo camino para hacer que el control de las versiones sea perfecto. Han pasado varios años desde que lidié con VSS, pero estas herramientas son una manera mucho más amigable de usar el control de fuente.

Lo mismo ocurre con lo que todos han dicho sobre VSS siendo caca

Subversion tiene un buen soporte para la creación de sucursales y fusiones ... No recuerdo que VSS tenga capacidades en este departamento. Recuerdo que los equipos pasan por el dolor de una semana de fusión cuando necesitan liberarse de VSS, dolor que ya no existe con Subversion.

just : solo apunta a las personas a esa URL

Cree una automatización que refleje el repositorio VSS en un repositorio SVN

Lleva tiempo construir un consenso. Si su espejo SVN del repositorio de VSS está disponible en todo momento, será más fácil acumular conversos. El espejo no tiene que ser perfecto, solo tiene que ser útil. Existen herramientas existentes para este propósito.