visual team studio sourcesafe instalar explorador descargar version-control project-management visual-sourcesafe

version-control - team - visual sourcesafe download



¿Por qué debería mi equipo adoptar el control de fuente? (25)

¿Por qué su equipo no debería adoptar el control de la fuente?

Incluso como desarrollador solo, utilizo control de fuente. En un entorno de desarrollo de software moderno, puedo pensar en pocas o ninguna de las razones por las que no usaría el control de código fuente. Es más sorprendente que aún no lo tengas. La pregunta me parece algo así como que los pintores de casas preguntan "¿Por qué deberíamos adoptar el uso de escaleras? Ya sabes, las escaleras no pintan la casa, los cepillos sí".

Tengo la oportunidad de dar una presentación formal a mi jefe sobre cualquier cosa que beneficie a la empresa. Mi idea es adoptar control de fuente en mi lugar de trabajo. He estado usando Mercurial para administrar mi propio proyecto en el trabajo, pero el resto del equipo no cuenta con un sistema de control de fuente formal. Lamentablemente, no soy muy bueno presentando ideas.

Entonces, ¿pueden decirme por qué los desarrolladores DEBEN usar el control de fuente? Además, ¿por qué elegiría cualquier herramienta excepto Visual SourceSafe? No tengo experiencia en el uso de VSS, pero es probable que pregunte por qué no usaríamos simplemente las herramientas de Microsoft.

¡Quiero escuchar opiniones de muchos programadores inteligentes aquí! Mis opciones preferidas son SVN o mercurial. Ambos parecen tener un buen soporte para sus versiones de Windows, y ambos son menos arcaicos que CVS. Además, como un discípulo de código abierto autoproclamado, preferiría sugerir una herramienta de código abierto. :)

¡Gracias!

Editar : para abreviar, en general, la práctica actual para otros desarrolladores es copiar carpeta, etiqueta con fecha y tal vez grabar por su cuenta. Te dan la imagen. ¿Qué pasa si mi jefe dice "si funciona, por qué arreglarlo?"

¿Por qué hacer una presentación formal?

Suponiendo que el tamaño del equipo es al menos dos, haga un ejemplo del mundo real: permita que dos (o más, entre más, mejor) las personas obtengan el código, haga sus cambios y muestre qué se necesita para integrar todos esos cambios utilizando el control que no sea fuente significa que usas

Luego haz el mismo escenario usando el control de fuente.

La cantidad de tiempo y dolor que ahorra al usar el control de fuente hablará por sí mismo.

Antes de decir algo, descubra por qué su empresa no utiliza el control de código fuente.

Una vez que sepa por qué, es fácil encontrar escenarios donde el control de fuente pueda ayudar.

Aquí hay un ejemplo simple de la vida real.

Hace algunos años, mi jefe dice: "La función XYZ solía funcionar, y ahora no funciona. Nadie sabe qué pasó. ¿Puedes arreglarlo?"

Ahora nunca he trabajado con la función XYZ antes. Así que arreglarlo implicaría un gran revuelo tratando de descubrir qué hace.

¡Pero tenemos control de fuente! Entonces hago esto:

  • Cree un script de prueba para probar la función XYZ: "Haga clic aquí, escriba esto, haga clic allí, etc."
  • Obtenga la versión actual. Construir. Prueba. La característica XYZ está rota.
  • Obtenga la versión de hace una semana. Construir. Prueba. La función XYZ funciona.
  • Obtenga la versión a medio camino entre esos dos. Construir. Prueba. La función XYZ funciona.
  • Obtenga la versión a medio camino entre la anterior y la actual. Construir. Prueba. La característica XYZ está rota.

Seguí haciendo esta búsqueda binaria hasta que finalmente llegué al punto de cambio: la versión 145 (diremos) tenía la característica funcionando, pero la versión 146 la tenía rota. Luego hice una comparación entre esas dos versiones para ver qué cambió. Resulta que nuestro plomo técnico ( suspiro ) había verificado el código que cambió la funcionalidad, pero también introdujo un efecto secundario que rompió característica XYZ.

Así que eliminé el efecto secundario, probé ... y he aquí, la función XYZ funcionó de nuevo.

Sin control de fuente, nunca puedes hacer esto. Tendrá que darse la vuelta, cambiando una cosa u otra, esperando golpear mágicamente lo que hace que la función XYZ vuelva a funcionar.

Con el control de fuente, simplemente prueba el camino a través de las versiones, identifica el código exacto que causó el problema y lo repara.

Asegúrate de haber comprado para el resto del equipo. Tal vez puedes probar tu presentación en ellos? Con suerte, también ven la necesidad.

Es bueno ver que las buenas prácticas se inician de abajo hacia arriba. Tal vez sea más probable que todos adopten la práctica si proviene de uno de los suyos en lugar de algún mandato de gestión.

Debe usar Source Control por estos motivos

1) Puede retroceder a cualquier versión

2) Diferentes desarrolladores pueden trabajar en los mismos archivos

3) Todos los desarrolladores tendrán acceso a la misma base de código

4) Puedes rastrear cambios

5) Puede deshacer cambios que no funcionan

6) El control de fuente es la base de la integración continua y ayuda masivamente con TDD

7) Si no usas el control de fuente, lentamente te volverás loco cuando los archivos se pierden / sobrescriben y nada funciona como debería.

VSS no es la peor aplicación de SCC, la utilicé durante años y llegué a odiarla, pero funciona, es simple y mucha gente lo sabe.

La razón principal por la que utilizamos el control de versión es la constancia.

Si los proyectos no son consistentes, entonces los problemas van a ocurrir y el código se perderá.

Manténgase en la línea de fondo, explique cómo se relaciona con el dinero y probablemente su jefe lo escuche.

Si solo eres un programador, diría que el argumento principal es la posibilidad reducida de perder tiempo (y, por lo tanto, dinero) corrigiendo errores simples, tratando de desmantelar el código que resultó ser la idea equivocada, etc.

Si usted es más de un programador, lo anterior va dos veces más, es la única forma sensata de poder trabajar en conjunto en la misma base de código sin perder aún más tiempo esperando el uno al otro,

Visual Source safe es mejor que nada, pero hay opciones gratuitas que son mejores en casi todos los aspectos. Si su jefe necesita una presentación para entender por qué el control de la fuente es esencial, puede que no le importe qué herramienta usará una vez que haya sido iluminado. Que tenga experiencia con otras herramientas y no vss nuevamente se relaciona con el resultado final, por lo que podría ser suficiente.

Me parece que la mayoría de las personas han cubierto la característica principal del control de fuente, pero uno de los aspectos positivos más importantes se omite. Estos son:

Sucursales

Sin un repositorio de código fuente es imposible crear ramas (o copias / secuencia / etc.) de su código para fines particulares. No poder crear y fusionar sucursales es una de las cosas más importantes que descalifica a VSS de ser un verdadero sistema de control de código fuente. Algunos de los propósitos de una sucursal incluyen:

Arreglo del fallo

A veces necesitas resolver un error y hacerlo en un lugar alejado de la versión principal o troncal de tu código. Esto puede ser para resolver un problema en el entorno de prueba o por varias razones. Si tiene una herramienta de control de versiones, debería poder crear fácilmente una nueva rama (algo que VSS apesta) para arreglar el error y poder fusionarlo de nuevo en el código de la línea principal si es necesario.

Versión de mantenimiento

Esto podría ser muy parecido a una solución de error, pero se puede hacer después de que el código se haya lanzado a producción. Los ejemplos serían para fixpacks, releases de servicio, etc. Nuevamente, desea poder fusionar los cambios nuevamente en el trunk si es necesario

Nueva caracteristica

Algunas veces necesita comenzar el desarrollo de una nueva versión mientras mantiene su código actual. Por ejemplo, libera y mantiene v1.0 pero necesita comenzar a trabajar en v2.0 mientras mantiene v1.0. Las sucursales ayudan a resolver esta situación

Etiquetado / etiquetado

Otra cosa que hacen los sistemas de control de código es hacer instantáneas del código fuente en un punto particular en el tiempo. Estas se llaman etiquetas en VSS, etiquetas en subversión, etc. Al crearlas de forma regular y vincularlas a un hito importante en su proyecto, es posible determinar qué ha cambiado exactamente en su código entre lanzamientos. Esto puede ser importante para los auditores, pero también para rastrear el origen / alcance de un problema. VSS también obtiene un error aquí porque VSS solo versiona los archivos, no los directorios. Esto significa que es imposible volver a crear una versión anterior del sistema si renombra / mueve / elimina archivos o directorios en el repositorio (algo que sucede mucho si se refactoriza). Los buenos sistemas de control de código fuente como Subversion hacen justamente esto.

Realmente lo siento, pero si realmente tiene que defender [la formalización] del control de la fuente en un entorno de desarrollo, se encuentra en una situación desesperada. Si su jefe realmente necesita estar convencido de que el control de la fuente es una tarea que vale la pena, su jefe simplemente no es apto para ser un gerente de un grupo de desarrolladores de software. Para que alguien administre eficazmente, realmente necesitan al menos una comprensión básica del paisaje. Ni siquiera puedo imaginar lo que sucederá cuando necesites argumentar a favor de algo que valga la pena discutir y hacer una presentación.

Desarrollar sin control de fuente es como conducir un automóvil sin descansos. Pierdes la capacidad de realizar un desarrollo simultáneo sin problemas, pierdes tu código copiado en copias de trabajo, pierdes la capacidad de realizar búsquedas históricas mediante anotaciones de código, pierdes el beneficio de ver el contexto y los comentarios que acompañan a los cambios discretos, solo perder, punto Usar el control de fuente es tan obvio y tiene tantos beneficios, es sorprendente que tengas que justificarlo.

En el trabajo, utilizamos la subversión, pero algunos desarrolladores (incluido yo mismo) usan Git localmente a través del puente git-svn. Para el trabajo personal, uso Git.

Si el proceso actual está copiando una carpeta y dándole una fecha, ¿no es así para obtener algún tipo de historial de desarrollo, entonces, ¿no es básicamente una forma simple de control de fuente?

Entonces, para responder a cualquier crítica sobre el control de la fuente, ya lo estás haciendo. Ahora solo necesita señalar las debilidades en el sistema actual y sugerir una mejor. ¿Por qué necesita reinventar la rueda cuando las personas realmente han pensado en muchos de los escenarios complejos que pueden ocurrir durante el desarrollo y han desarrollado las herramientas que les permiten manejarlos?

Lo que estás haciendo actualmente es muy frágil y se caerá si surge algún tipo de escenario complejo, en cuyo punto tendrás que gastar mucha energía resolviendo cómo hacer algo que las herramientas ya hacen. VSS es mejor que lo que está haciendo, pero no tiene las convenciones muy útiles que SVN, git o mercurial tienen, lo que permite que múltiples proyectos vivan juntos de una manera bien organizada. Estoy hablando de ramas, etiquetas y fusión, ambos de los cuales son frágiles y básicamente una pesadilla bajo vss.

SVN tiene complementos para Visual Studio. Algunos son gratis. Pero me parece que tortuga-svn simplemente eclipsa cualquier otra cosa. El único beneficio que encuentro con un complemento es que los nuevos archivos se agregan a svn automáticamente.

Entonces, debilidades de su sistema actual:

  • Si tiene que hacer un cambio en un archivo, es probable que sobrescriba o sobrescriba los cambios del otro desarrollador. Puede que ni siquiera te des cuenta de esto.
  • Si tiene que recordar qué archivos ha modificado para copiarlos en una copia maestra, es probable que se pierda uno en algún momento.
  • Buena suerte alguna vez encontrando documentación sobre cuándo hizo un cambio y por qué.
  • ¿Cómo podría construir un sistema de construcción automatizado estable en su sistema actual? El control de crucero y Hudson funcionan muy bien, te estás cogiendo
  • VSS no agrupa muy bien los cambios en varios archivos. Todo lo moderno lo hace extremadamente bien y con consistencia atómica.
  • La rama de VSS y el soporte de combinación son terribles. Cuando lo usamos terminamos entre corchetes cada cambio con comentarios en el código fuente y copiando el código manualmente en lugar de confiar en la fusión de VSS.
  • Va a ser muy difícil, casi imposible en su sistema actual, tener alguna versión del código en mantenimiento en vivo y alguna otra versión posterior en desarrollo pesado. Piensa en lo que se necesita para mantener sincronizados dos proyectos como este, necesitarás una buena herramienta. SVN puede hacerlo, git puede hacerlo realmente bien.

Eso podría ser suficiente para continuar, puede hacer más.

Simple: si el código no está en la fuente segura, no existe

Subversion es gratis y mejor que VSS pero VSS definitivamente es mejor que nada.

Simplemente, para que tenga un historial verdadero del código, para investigar los cambios (motivos de los errores), volver a las versiones, auditar, etc. La copia de seguridad no es suficiente; simplemente tiene una copia de la imagen actual . ¿Alguna vez cambiaste un archivo y deseas recordar lo que hiciste?

Sugiero usar SVN, porque:

  1. El control de fuente te brinda una excelente historia. Puede ver dónde se han realizado los cambios, proporcionando así una excelente manera de ver qué ha cambiado con el tiempo (incluso mejor si completa el resumen de envío cada vez)
  2. Para el desarrollador, proporciona una excelente alternativa si algo sale mal. Puede revertir los cambios de un archivo a cualquier punto de su historial, de modo que puede probar el mod que deseaba y, si no funciona, desenrollarlo fácilmente.
  3. Proporciona un repositorio central que es mucho más fácil de realizar una copia de seguridad que ejecutar en las computadoras de diferentes desarrolladores.
  4. Le permite ramificar un proyecto en una dirección diferente, útil para especializaciones y personalizaciones.
  5. Permite que más de un desarrollador trabajen juntos en el mismo proyecto, y la misma fuente, permitiéndole fusionar y manipular los cambios en una copia central.

Sugiero NO usar VSS: consulte esta página por razones: http://www.highprogrammer.com/alan/windev/sourcesafe.html por más razones.

Tómalo de mí, VSS sopla . Es almacenamiento de archivos básico con historial. Cualquier cosa es mejor que VSS y VSS es mejor que nada :)

Utilice el control de fuente porque ni usted ni su equipo son perfectos. La función principal del control de origen es garantizar que tenga un registro histórico completo de su proceso de desarrollo. Al tener este registro, tiene la posibilidad de expandirse con confianza con versiones "experimentales", sabiendo que si el experimento falla, puede hacer una copia de seguridad de una versión anterior.

Además, un buen sistema de control de fuente como svn permitirá que múltiples desarrolladores trabajen en el mismo archivo y proporcionen herramientas poderosas para reconciliar las diferencias que cada uno introduce.

Entonces, ¿pueden decirme por qué los desarrolladores DEBEN usar el control de fuente?

  • Proporciona un método para que todo un equipo lo use; todos operan bajo las mismas ''reglas básicas''.
  • Los cambios son ordenados vs. caóticos, ahorrando tiempo de desarrollo.
  • La capacidad de realizar un seguimiento de los cambios promueve la responsabilidad y facilita la búsqueda de la información adecuada para resolver los problemas en los materiales que se mantienen.
  • Se puede generar una lista de cambios exactos de manera rápida y fácil, lo que facilita informar a los usuarios de la información sobre cómo ha cambiado de una versión a otra.
  • Es fácil "retroceder" a una versión anterior de la información, si se cometió un error grave durante un cambio.

¡El control de fuente es como un seguro! ¡Espero que nunca lo necesites, pero te alegra que lo tengas cuando lo necesites!

Comparemos dos ejemplos, un entorno de desarrollo que usa control de origen y otro que no.

  • A: ¿Utiliza
  • B: No usa

Escenario 1: un proyecto es solicitado, completado y desplegado

A + B) Los programadores desarrollan el proyecto internamente, cuando se completa, lo extienden a prueba y luego lo entregan al cliente (quienquiera que sea)

No hay mucha diferencia, en el panorama general

Escenario 2: después de que se lanza un proyecto, el cliente decide que no quiere la función X

A + B) Los desarrolladores eliminan el código que el cliente no quiere, prueba y entrega.

Nuevamente, no mucha diferencia.

Escenario 3: dos semanas después, el cliente decide que realmente QUIEREN presentar la característica X

A) Los desarrolladores reinsertan el código que sacaron en 2 de nuevo en el árbol de desarrollo normal, lo prueban y lo entregan.

B) Los desarrolladores buscan el código anterior en sus máquinas personales, el servidor de archivos y las copias de seguridad. Si encuentran el código, deben reinsertar manualmente cada archivo. Si no lo hacen, probablemente tengan que recodificar esa característica completa.

Es fácil obtener el código antiguo que sacó por una razón u otra

Escenario 4: Hay un error extraño en el sistema donde se supone que una función devuelve un resultado booleano, pero siempre devuelve falso. No fue así hace dos semanas.

A) Los desarrolladores examinan todas las versiones anteriores del software y descubren que una directiva falsa de devolución no está en el alcance apropiado: se está ejecutando dentro de un bucle en lugar de afuera.

B) Los desarrolladores pasan semanas tratando de descubrir cuál es el problema. Finalmente, notan el retorno en la línea incorrecta y lo arreglan. No tener control de fuente significa que tuvieron que examinar todos y cada uno de los archivos que se ejecutaron, en lugar de encontrar las diferencias entre cuando estaba funcionando y ahora.

Escenario 5: Alguien rompe la construcción. Pasa las pruebas y solo se nota semanas después.

A) El equipo examina el historial de compromisos, descubre quién rompió la construcción, hace que esa persona lo arregle y compre la cena del equipo.

B) El equipo tiene que volver a recorrer todo el proyecto para encontrar el error, pero no puede descubrir quién introdujo ese código. Los desarrolladores se culpan entre sí y la dinámica del equipo falla.

Es fácil ver quién cometió qué, cuándo y por qué.

La forma más fácil de convencer a la gerencia de invertir El tiempo en un SCCS se centra en la copia de seguridad y el archivo. Al utilizar algo como Subversion (SVN), puede restaurar cualquier proyecto en cualquier momento al instante. No es necesario que alguien revise las cintas de respaldo o se preocupe por el seguimiento de varias versiones en una estructura obtusa de directorios.

Obviamente hay muchas otras ventajas (es decir, 2 personas que trabajan en el mismo archivo al mismo tiempo), pero las copias de seguridad son lo que rápidamente vendió mi empresa hace muchos años.

Otros han mencionado los beneficios específicos del control de código fuente en otra parte, pero quería abordar explícitamente la parte de la pregunta "VSS".

Si su jefe quiere usar una herramienta de Microsoft, Team Foundation Server con Team Suite es una combinación muy agradable. También tiene otras herramientas incluidas, como el seguimiento de errores, documentos y capacidades de generación de informes, lo que la convierte en una plataforma agradable para mejorar más adelante su proceso. Estamos muy contentos con él donde trabajo, y mis compañeros de trabajo me han contado historias de terror sobre VSS.

Tenga en cuenta TFS como respuesta a la pregunta ''Herramientas de Microsoft''.

Para evitar cosas como

"Hey! What happens ? It worked yesterday."

Tener un sistema de control de versiones ayuda en muchos casos:

Desarrollador único, una sola sucursal

  • La tarea más básica que tiene que realizar cada sistema de control de versiones para llamarse control de versiones es poder volver a la versión especificada de un proyecto. Si cometiste problemas, puedes ir a la versión anterior. Puede examinar alguna versión anterior para verificar cómo se hizo en ese momento (por ejemplo, cómo era antes de refactorizar o antes de eliminar algún código / archivo).

    Los sistemas de control de versiones ocupan mucho menos espacio en disco en comparación con el simple hecho de guardar copias de seguridad con la fecha especificada, porque usan la delificación (que almacena solo las diferencias de la versión anterior) y la compresión. Por lo general, los sistemas de respaldo son medios para almacenar las últimas versiones N de un proyecto, a veces con N = 1 (solo versión anterior), mientras que los sistemas de control de versiones (VCS) almacenan todo el historial de un proyecto. Conociendo a Murphy un rato después de borrar la última versión Nth, se daría cuenta de que era la versión que desea examinar.

    Además, volver a una última versión es fácil y automatizado. También puede examinar cómo se veía el archivo único en alguna versión pasada, y puede obtener diferencias (en formato de diferencia) entre el estado actual y alguna versión anterior. También puede etiquetar (o ''etiquetar'') versiones para que pueda referirse a la versión anterior no solo por fecha, o por ser una versión n. ° de la actual, sino también por nombre simbólico, por ejemplo v1.2 o v1.2-rc0 .

  • Con el sistema de control de versiones puede examinar el historial para recordarle por qué (y cómo) alguna parte del código (alguna parte de un archivo determinado) llegó al estado actual. La mayoría de los VCS permiten examinar el historial de un archivo en línea, es decir anotar cada línea de un archivo cuando se modificó, en qué commit, y por quién (el comando se llama annotate , blame o praise dependiendo de VCS). En algunos VCS puede buscar el historial de una versión (revisión) que introdujo un fragmento dado de código (por ejemplo, llamado ''búsqueda de pico'' en Git, uno de VCS).

    Para que esta característica sea realmente útil, debe mantener cierta disciplina: debe describir cada nueva versión (cada nueva revisión / cada nueva confirmación) anotando por qué se realizó el cambio. Dicha descripción (mensaje de confirmación) es muy útil, pero no tiene un lugar natural en el sistema de copia de seguridad.

    Esta característica, por supuesto, es aún más útil si no eres el único desarrollador ...

  • El uso del sistema de control de versiones permite buscar errores de forma alternativa en el código, es decir, al buscar en el historial la versión que introdujo el error: historial de bisección . Cuando encuentre la revisión que introdujo el error, tendría un área limitada (en el mejor de los casos: muy limitada) para buscar el error, porque el error debe estar en la diferencia entre la última versión de trabajo y la primera versión con un error. También tendría una descripción de un cambio (un mensaje de confirmación) para recordarle lo que quería hacer. Esta característica también se llama a veces depuración de diferencias . Los sistemas modernos de control de versiones (VCS) tienen soporte para búsquedas automatizadas (o semiautomatizadas) de la historia biseccionando (dividiendo el historial a la mitad, encontrando qué parte contiene errores, repite hasta que se encuentre una sola versión responsable), en forma de bisect ( o similar) comando.

    Para que esta característica sea realmente útil, debe mantener cierta disciplina: debe comprometer (guardar cambios / poner estado dado en el sistema de control de versiones para recordar) un cambio único, tratando con una sola característica, con solo una pequeña diferencia de la versión anterior; es decir, cometer a menudo.

  • La mayoría de los sistemas de control de versiones ofrecen varios ganchos que permiten, por ejemplo, realizar pruebas automáticas o crear automáticamente un producto ... o simplemente recordarle que no sigue los estándares de codificación (pautas de codificación).

Desarrollador único, ramas múltiples

  • Los sistemas de control de versiones permiten crear múltiples líneas paralelas paralelas de desarrollo, llamadas ramas (o secuencias o vistas). El caso común es tener ramas de desarrollo , es decir, tener una rama separada para desarrollo inestable (para probar nuevas características), una rama separada para la versión estable (principal, troncal) que es (o debería ser) la versión de trabajo actual y otra para un mantenimiento más independiente (corrección ) ramas.

    Tener ramas de mantenimiento le permiten hacer correcciones de errores y generar paquetes de servicio / versión menor con correcciones a alguna versión lanzada, sin necesidad de preocuparse por la interferencia del nuevo desarrollo. Más tarde puede fusionar la rama de mantenimiento en estable, o elegir bigfix de la rama de mantenimiento en ramas estables y de desarrollo (si el desarrollo adicional / otro no solucionó el error de forma independiente).

  • El VCS moderno (aquí moderno significa que tanto las ramas de bifurcación como de fusión son fáciles) permiten ir un poco más allá, es decir, generar una bifurcación separada para trabajar en una función separada (las denominadas ramas de tema ). Esto le permite alternar entre trabajar una característica para trabajar en otra característica (y no solo cambiar de desarrollar una nueva característica a trabajar en la corrección de errores solicitada con urgencia).

  • Si está desarrollando su producto según el origen de algún otro producto (generalmente de terceros), debería utilizar las sucursales de los proveedores para poder integrar fácilmente la nueva versión de un producto del proveedor con los cambios que realizó. Es cierto que esto ya no es un caso de "desarrollador único".

Múltiples desarrolladores

  • El uso de sistemas de control de versiones brinda aún más ventajas si hay más de un desarrollador trabajando en el mismo proyecto. VCS permite el desarrollo concurent (paralelo) sin preocuparse de que alguien sobrescriba los cambios, o no tenga en cuenta sus cambios. Por supuesto, el uso de un sistema de control de versiones no es un sustituto de la comunicación.

  • Todas las características anteriores son aún más importantes en el caso de desarrolladores múltiples: examinar quién generó el cambio determinado, quién cambió el código por última vez (también conocido como quién rompió la compilación), encontrar un error en el código no escrito solo por usted.

Porque:

  1. Reducirá los costos: los desarrolladores tendrán que pasar menos tiempo revisando un elemento dentro / fuera de un VCS real que con su enfoque ad-hoc actual.

  2. Protegerá la propiedad intelectual de la organización; esta debería ser la consideración más importante para cualquier compañía de software (que no sea información ...). Le pagan para crear el software, ¿no debería ser accesible en su totalidad?

  3. Proporcionará mecanismos de respaldo más rápidos, más confiables y directos: todos los VCS han incorporado capacidades de descarga. Estos tienden a ser más maduros que una simple copia de archivo.

  4. Actuará como un mecanismo de comunicación entre desarrolladores: dependiendo del sistema de control de versiones, puede usar comentarios / etiquetas / estado de pago para determinar si alguien más ha trabajado en un archivo, si se ha promocionado a producción, si tiene un soporte correspondiente número de boleto, etc.

  5. Agiliza el desarrollo: la capacidad de comparar versiones de archivos y otros mecanismos será beneficioso para el período de su empresa.

Larga discusión sobre por qué debería tener absolutamente el control de fuente:

¿Es necesario el control de versiones para un pequeño grupo de desarrollo (1-2 programadores)?

Mis comentarios de ese hilo:

Siempre, siempre quiere tener algún tipo de control de fuente, incluso si está trabajando en un proyecto por su cuenta.

Tener un historial de cambios es vital para poder ver el estado de una base de código en cualquier momento dado. Hay una variedad de razones para mirar hacia atrás en el historial de un proyecto, que van desde deshacer un mal cambio hasta proporcionar soporte para una versión anterior cuando el cliente simplemente quiere que un parche corrija un error en lugar de actualizar a una versión más nueva de El software.

No tener algún tipo de control de fuente es pura locura.

En lo que respecta a VSS, ciertamente es mejor que nada. Definitivamente no es el mejor control de fuente y está muy anticuado, pero el hecho es que sigue haciendo el trabajo para una gran cantidad de compañías.

Si su jefe está decidido a seguir con las herramientas de Microsoft, vaya a Team Foundation Server en lugar de VSS. Es un sistema mucho mejor que VSS y tiene buenas características como el seguimiento integrado de errores.