Escenario para evaluar las herramientas de control de fuente / versión

Actualmente estamos investigando diferentes herramientas de control de origen, y queremos probar cada una con un escenario ligero pero significativo para tener una idea de las capacidades de cada una.

La terminología y la lógica interna varían ampliamente entre algunas herramientas, sería bueno tener el escenario expresado en términos de casos de uso ( "Tenemos que corregir un error en la Versión 1.3" ), en lugar de en términos potencialmente específicos de la herramienta ( "Crear un sucursal llamada Release 1.3 " ).

Es cierto que diferentes cosas son importantes para diferentes equipos, pero sería interesante tener algún tipo de caso de testing canónica del que se puedan elegir diferentes escenarios. ¿O estoy siendo demasiado optimista?

¿Alguien sabe algo como esto? ¿Has usado un enfoque similar cuando investigas herramientas de control de fonts?

Estos son los requisitos que tenía Mozilla cuando establecieron evaluar los sistemas de control de versiones para uso interno en 2006. Puede encontrar un enfoque similar útil.

Si encuentra escenarios que son específicos de su empresa, quizás pueda traducirlos a requisitos como los de arriba.

Usted tiene algunos criterios generales con el análisis de Google DVCS que pueden dar algunas ideas.

Pero primero necesita ver si desea evaluar:

  • CVCS (Control de versión central): update-merge-commit
  • DVCS (Control de versión distribuida): commit-rebase / merge

Para get más información sobre el escenario diferente de testing (una respuesta para CVCS, una para DVCS), consulte la pregunta SO:

" Describa su flujo de trabajo de usar control de versiones (VCS o DVCS) "

Tiene que preguntar cosas como: ¿tiene solo una línea de lanzamiento / desarrollo o creamos varias versiones en paralelo? No solo es necesario el escenario mencionado, sino que también hay que pensar en uno como fusionar los cambios en línea de desarrollo o en otras múltiples líneas. Esto puede influenciar el enfoque. El enfoque que seleccionó suena muy bien porque intenta comprender el process y no utilizar los términos de la herramienta. Lo he hecho varias veces para clientes míos. En diferentes equipos / empresas, las cosas diferentes se manejan de forma diferente. Entonces, el problema es averiguar cuál es el process tuyo (algunas veces la gente no se da count de esto).