Pregunta

Mi lugar de trabajo actual se encuentra en transición, han asumido nuevos propietarios, las cosas finalmente se están estandarizando y se están aplicando las pautas adecuadas.

Pero todavía estamos usando VSS, realmente no hay ninguna razón para usarlo aparte de lo que está configurado inicialmente.No utilizamos Visual Studio ni ninguna herramienta que lo requiera específicamente.

¿Cuál sería el mejor argumento que puedo plantear para ayudarlos a convencerlos de que optar por algo como Subversion sería una solución mucho mejor a largo plazo?

¿Fue útil?

Solución

VSS depende totalmente de los clientes para gestionar la base de datos.Si un cliente interrumpe la conexión en medio de una escritura a través de la red en el momento equivocado, su archivo se desecha en el servidor.No sólo la punta, sino toda la historia.Espero que tengas una buena copia de seguridad.He pasado por eso.Son malas noticias.

El uso de VSS a través de VPN u otras conexiones remotas es abismal.Está utilizando SMB para transferir los datos y usted debe recuperar el archivo y todos sus deltas solo para obtener la información.Asqueroso.

He visto que VSS comienza a funcionar mal con 1 GB de datos.Errores de base de datos, etc.MS (en algún lugar de las preguntas frecuentes o KB) dice que 2 GB es realmente el límite máximo seguro.No existen buenas herramientas de gestión (los clientes dirigen el asilo), por lo que realmente no recibes ninguna advertencia al respecto.

Cualquier cosa con un proceso de servidor para proporcionar cierto nivel de transacciones y control de integridad es una solución superior.

Otros consejos

El mejor argumento tendría que ser la razón por la que quieres que pasen a la subversión.:)

No sé absolutamente nada sobre VSS, pero me viene a la mente la frase "si no está roto, no lo arregles".Debe mostrarles a sus gerentes que VSS no funciona y necesita reparación.Aún mejor si puede mostrarle a la gerencia cómo les ahorraría dinero.

@Adam Davis:Uhhh, en realidad Adam, VSS es un sistema de control de fuente horrible.Tiene un largo historial de corrupción de historial y pérdida de datos.Es terrible fusionando, no maneja bien a varios desarrolladores y es muy lento.Además la historia es pobre.Microsoft realmente ya no lo admite, notará que nunca lo usaron para su propio desarrollo interno y ahora ni siquiera lo venden a favor de una solución más moderna (VSTS).En resumen, si tienes que elegir entre VSS y cualquier otro tipo de control de fuente, opta por la alternativa.

Con solo repasar las características que ofrece un buen control de fuente:

  • capacidad de ver fácilmente registros de quién hizo qué, cuándo y en qué orden, en qué archivos
  • mantener un historial de versiones pasadas de todo
  • regrese fácilmente y reproduzca una versión específica de sus archivos desde cualquier versión anterior, para reproducir más fácilmente los errores informados en versiones anteriores
  • Posibilidad de recuperar el código eliminado o eliminar cambios no deseados, sin tener que preocuparse por perder datos en el proceso.

Cualquier documento que acredite el cambio reducirá los costes.En su defecto, gráficos y tablas multicolores.Quizás una presentación en power point.

Internet está plagado de artículos bien escritos sobre los defectos de VSS.Recopilaría esto como un conjunto de pruebas para alejarnos de VSS.Encuentre un requisito clave que VSS no pueda soportar (trabajo remoto, soporte en otros sistemas operativos, integración de herramientas) y utilícelo para solucionar su problema.Luego necesita encontrar un sistema de control de fuente que se adapte bien a los requisitos de su organización. ¿Está seguro de que Subversion es ese sistema?Organice una demostración del sistema elegido y utilícela para demostrar su valía.

Implementé este cambio en un empleador anterior (primero en CVS y luego en SVN), y si bien fue exitoso, tuvimos que construir muchos bits en el borde y depender de muchos proyectos de código abierto (a veces poco confiables) para lograrlo. todas las herramientas que necesitábamos.En retrospectiva, debería haber considerado intentar evaluar herramientas profesionales como Perforce, Vault o incluso Team System.Después de evaluarlos, podría haber hecho un juicio de valor adecuado sobre si CVS/SVN valía su precio "gratuito".

ser capaz de manejar ramificaciones y bifurcaciones es un comienzo.

Intente usar subversion por un tiempo en paralelo a vss, lo más probable es que encuentre muchos argumentos para convencer a su jefe.Si no lo hace, su jefe tiene razón, no hay razón para cambiar.

Pídales que busquen en Google 'problema vss', 'corrupción segura en la fuente' o simplemente busquen en la página Wiki.Eso debería convencerlos de que probablemente no sea algo viable a largo plazo para usted apostar en una parte tan vital de su negocio.

¿Qué tan grande es tu equipo?(es decir, me refiero a cuántos miembros, no a si eres un evasor de ensaladas o no). Una vez que empieces a tener más de media docena de usuarios bastante activos, VSS te dará dolores de cabeza.

Dudo seriamente que Microsoft lo utilice (de hecho, ¿no utilizan una variante personalizada de Subversion o CVS?) y hay que preguntarse: si la empresa no se come su propia comida para perros, ¿por qué se la comería usted?

La respuesta básica es que hay que defender que el cambio satisface las necesidades del negocio.Por ejemplo:

  1. menor costo de desarrollo
  2. horario más corto (otro tono del n.° 1)
  3. más apto para cumplir con los requisitos del proceso (como la trazabilidad de los requisitos del software o la reproducibilidad de la compilación, etc.).

Argumentar estas cosas también requiere algo cuantitativo, no sólo "bajaremos los costos porque este es el bien manera de hacerlo!".

Una cosa a tener en cuenta es que es demasiado fácil para un desarrollador convencerse de que sería beneficioso realizar el cambio sin pasar primero por los filtros comerciales básicos.Una vez que eso sucede, terminas con desarrolladores que no están satisfechos con sus herramientas y están doblemente frustrados porque creen que la gerencia no los escuchará.Si no puede marcar una de las cosas anteriores, no tendrá ninguna posibilidad de persuadir a la gerencia de nada (a menos que la gerencia sea incompetente, pero eso es para otra pregunta).

¿Por qué Subversion en lugar de VSS?

  • Software libre
  • Más fácil de gestionar
  • Los "check-ins" son atómico!
  • Fácil de ramificar y fusionar
  • Desarrollo continuo (es decir,VSS es un callejón sin salida)
  • Mejores herramientas para rastrear cambios y ver registros
  • Independiente del conjunto de herramientas y de la plataforma, pero también se integra con muchas herramientas

Le hice la propuesta a mi gerente y fue bastante fácil de vender.Descubrí que es mucho más fácil de usar, especialmente para la ramificación (nuestro proyecto tomó 5 horas para "compartir y anclar" en VSS, y luego cada operación tomó más tiempo para completarse).

He previamente escrito sobre por qué VSS no es una buena idea.Es posible que pueda obtener algo de información a partir de eso.También Este artículo y Éste contener más información.

VSS 2005 ha tapado algunas de las grietas en 6.0, pero no de una manera particularmente convincente.La misma base de muerte cerebral permanece.

Incluso si no está roto, existe un beneficio potencial al migrar desde VSS.En primer lugar y lo más trivial, no tendrá que comprar nuevas licencias VSS.En segundo lugar, hay muchos ejemplos de deficiencias en el producto VSS (algunas también reconocidas por los Estados miembros).La curva de aprendizaje para SVN es al menos tan baja como para VSS, y si tiene desarrolladores más satisfechos con su sistema de control de fuente, es más probable que lo use temprano y con frecuencia.Eso se traducirá en muchos menos riesgos para su empresa, y eso es un buen beneficio.

@Jason:VSS está roto.

Creo que el método más poderoso para motivar un cambio fuera de VSS es señalar cuán crítico es el activo de su código fuente.Asumir riesgos con su integridad no es una buena elección empresarial.

Agregue que sus programadores son los creadores de este recurso y que facilitarles la productividad significa más valor en su recurso de código fuente.Joel en Software habla a menudo de cómo invertir en sus programadores es una gran victoria para su empresa.

Todas las otras respuestas aquí describen razones específicas que puede señalar al presentar su caso.

Además de los puntos técnicos dados en otras respuestas, es posible que haya razones no técnicas al acecho a las que debería estar preparado para responder:

Debería investigar si su empresa tiene algún tipo de política contra (o miedo equivocado) al software de código abierto.Si la empresa o sus abogados no comprenden los entresijos de qué licencias “infectan” el código propietario y cuáles no, así como qué se puede hacer con el código fuente abierto que no afecta su código propietario, lo hará. Les resulta difícil lograr que cambien de una herramienta propietaria a una de código abierto.(Y es posible que tenga un trabajo educativo más importante entre manos).

Al defender el cambio de propiedad (p. ej.VSS) a código abierto (p. ej.subversión) también deberá estar preparado para defender la calidad del código y la falta de necesidad de garantía u otros derechos contractuales con respecto al código.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top