version-control - studio - superponer graficas en r

Manejo de conjuntos de cambios múltiples en sistemas de control de fuente (8)

Tengo un problema bastante infrecuente que ocurre con el control de fuente. En el ejemplo aquí, el problema estaba ocurriendo con Perforce, pero sospecho que ocurrirá el mismo problema con muchos SCM, especialmente los SCM distribuidos.

Perforce admite listas de cambios (o conjuntos de cambios si lo prefiere). Las listas de cambios admiten dos usos comunes:

Cuando confirma una lista de cambios, la confirmación es atómica, por lo que todos los archivos están confirmados o ninguno. Esta es la característica principal de la que habla la mayoría de la gente cuando se refiere a las listas de cambios.
Perforce admite múltiples listas de cambios. Básicamente, cuando revisa un archivo, le dice a qué lista de cambios pertenece. Por lo tanto, si está trabajando en la nueva y lujosa característica de correo electrónico que va a llevar meses de trabajo y gana millones de dólares y alguien del soporte técnico le responde con un error que debe solucionarse ayer, no tiene que comenzar por una nueva rama de todo el proyecto. Puede ver el archivo con errores en una nueva lista de cambios, solucionar el problema, verificar la nueva lista de cambios y volver al trabajo real de la nueva función de correo electrónico, como si nada hubiera sucedido.

En su mayor parte, todo funciona bien. Sin embargo, cuando estás implementando la función de correo electrónico estás haciendo un montón de cambios por todos lados, especialmente en main.h, y sucede que cuando trabajas en la solución de errores descubres que el pequeño cambio que tienes que hacer también está en main.h. La lista de cambios para la nueva característica ya ha sido revisada por main.h, por lo que no puedes ponerla fácilmente en la lista de cambios para corregir el error.

¿Ahora que haces? Usted tiene varias opciones:

Crea una nueva clientepec. Un clientspec en Perforce es una lista de archivos / directorios en el almacén y un destino local donde todo se copiará. Entonces puede crear una segunda copia del proyecto sin ningún cambio para la función de correo electrónico.
Hacer un dulce de azúcar. Haga una copia de seguridad de su copia modificada de main.h y revertir este archivo. A continuación, puede descargar main.h en la lista de cambios de corrección de errores. Arreglas el error, verifica la lista de cambios de corrección de errores, luego finalizas la descarga main.h en la lista de cambios de la función de correo electrónico. Finalmente fusiona todos los cambios de la copia de seguridad que hizo al inicio.
Usted determina que todos los cambios que ha realizado en main.h no tienen efectos secundarios o dependencias, por lo que solo debe mover main.h a la lista de cambios de corrección de errores, hacer el cambio y registrarlo. Luego, vuelva a verificarlo en la función de correo electrónico. lista de cambios. Obviamente, hay dos problemas con este enfoque: en primer lugar, puede haber efectos secundarios que no haya tenido en cuenta y, en segundo lugar, haya dañado la versión de su historial.

La opción 1 es probablemente la más limpia, pero no siempre práctica. Un proyecto en el que estaba trabajando tenía millones de líneas de código y un proceso de compilación realmente complicado. Llevaría un día configurar un nuevo entorno, por lo que no era realmente práctico para una corrección de errores de 5 minutos.

La opción 3 es una mala opción, pero es la más rápida, por lo que puede ser muy seductora.

Eso deja la Opción 2, que es la que generalmente usaría.

¿Alguien tiene una mejor solución?

Mis disculpas por la larga pregunta, pero he descubierto en StackOverflow que las preguntas completamente pensadas provocan mejores respuestas.

Este problema exacto se ha denominado "Problema de copia de trabajo enredado". Ryan Tomayko tiene una entrada de blog titulada The Thing About Git que habla sobre este problema en detalle y sobre cómo Git lo aborda.

Esta es una de las mejores cosas de Git. Yo uso git add -p al menos diariamente, para ayudar a cometer trozos individuales de código que tienen sentido independientemente el uno del otro. El hecho de que dos cambios lógicamente diferentes se encuentren en el mismo archivo fuente se ha vuelto irrelevante.

Usamos trabajos para que una sola ''tarea'' pueda abarcar múltiples conjuntos de cambios comprometidos.

Por lo tanto:

Compruebe que los cambios main.h sean independientes de otros cambios
Estado actual de check-in de main.h - en el trabajo de correo electrónico a largo plazo
Corrección de errores en main.h
Cambios en el arreglo de errores de check-in
Edite main.h en Correo electrónico si es necesario

Administro esto con Perforce manteniendo múltiples espacios de trabajo desde el principio. Mi desarrollo primario está en la línea principal (donde ocurre el desarrollo nuevo), mientras que otro está apuntando a una rama del código liberado. Si necesito corregir un error, voy a la rama de publicación.

No estoy seguro de si esto funcionaría para usted, pero al menos no necesitaría crear un nuevo espacio de trabajo cada vez que corrige un error (ya que ya estaría allí).

Para Perforce, puede usar una herramienta como p4 tar:

http://public.perforce.com/wiki/P4tar

Te permite guardar y revertir tu lista de cambios actual, hacer la corrección y luego restaurar tu trabajo. Aún necesitaría integrar sus cambios a main.h, pero hace la tarea mucho más fácil.

No mencionaste la opción 4, que es crear ramas.

Puede tener la línea de código principal a la que no se realizan cambios individuales, solo integraciones de otras ramas.

Luego tiene la línea de desarrollo principal, que es donde está creando su nueva y elegante característica de correo electrónico. Aquí es donde estás haciendo la mayor parte de tu trabajo.

Finalmente tienes tu rama de corrección de errores. Aquí es donde haces todas tus ediciones menores y correcciones de errores urgentes. Una vez que se han probado, se integran en la línea de código principal para control de calidad y liberación (que debe estar en una rama separada). Estas ediciones se pueden integrar desde la línea principal en su línea de desarrollo para que siempre esté trabajando en el último código. Esta integración puede ocurrir en el momento que elija, para que pueda estar seguro de que no causará ningún problema en su nuevo código.

Esta es (IMO) la mejor solución.

Creo que la solución al problema de ''Copia de trabajo enredada'' en Perforce es dejar de lado

Puede usar la línea de comando de la siguiente manera:

p4 shelve -c 123

Normalmente lo uso dentro del complemento IDE (Visual Studio o Eclipse) o P4V. Cuando esté archivando, puede elegir si desea revertir sus archivos, básicamente borrándose para su trabajo de emergencia. Y luego puede desmantelar los archivos cuando haya terminado para volver a su trabajo interrumpido.

Si está utilizando la línea de comandos, puede crear usted mismo una secuencia de comandos simple que se actualizará y, si tiene éxito, revertirá los cambios en su lista de cambios elegida, brindándole un borrón y cuenta nueva:

p4 shelve -c $ 1 && p4 revert -c $ 1 // depot / your / branch / ...

Simplemente invoca con un número de lista de cambios como parámetro. Y a la inversa, cuando haya terminado con su otro trabajo, puede obtener sus archivos de su estante y quitar el estante de la siguiente manera, que lo lleva básicamente a su punto de partida:

p4 unshelve -c $ 1 -f -s $ 1 && p4 shelve -c $ 1 -d

ClearCase también admite la lista de cambios (llamada "actividad" en su sabor de UCM) y presenta un desafío similar.

La opción 1 ("tipo de bifurcación") tiene sentido solo cuando determina que el "esfuerzo de depuración" no es compatible con el esfuerzo de desarrollo actual (función de correo electrónico) y se conserva mejor en una sucursal separada. Luego puede actualizar cualquier corrección realizada en la rama "parche" a la rama principal (ya que no todos los errores corregidos deben estar presentes en ambos: el desarrollo actual puede haber dejado obsoletas algunas correcciones).
Consulte también " Qué es una sucursal " y cuál es su flujo de trabajo de fusión .

La opción 3 es una ilustración del límite de la noción de conjunto de cambios: una única revisión (o "versión") de un archivo solo puede ser parte de un conjunto de cambios a la vez.

El git add -p (agregar parche) mencionado por Greg es una alternancia a la Opción 1 y 3, ya que aprovecha la función de estadificación del "Índice" (Área de preparación), zona en la que se decide qué se va a comprometer realmente. y lo que quedará en tu espacio privado.
Eso es bueno, pero también en mi experiencia, bastante difícil de mantener durante un largo período de tiempo, especialmente en un conjunto común de archivos en el que se aplican dos evoluciones diferentes. Una rama es más limpia, más simple que la prueba de la unidad. Sin embargo, para una pequeña solución como usted menciona, podría ser una buena salida.

La opción 2 es la solución práctica cuando te das cuenta de que tienes dos cambios para dos esfuerzos diferentes (que aún son compatibles, que no se "rompen" entre sí).
Pero puede ser una solución aún más simple sería simplemente:

comprobando el estado actual de main.h en el correo electrónico,
pago en error, arreglarlo, registrar error
y luego pagar en el correo electrónico para reanudar el desarrollo de la función de correo electrónico.

De nuevo, si los dos esfuerzos de desarrollo (correo electrónico y error) son compatibles, puede tener un historial de revisiones con actividades mixtas.

Estoy de acuerdo con ChrisF : la ramificación sería la solución más natural para esto.

He usado Perforce por un tiempo, y es cierto que no es tan fuerte como otras SCM, pero se puede hacer.

El truco es realmente simple: crea una rama para cada tarea en la que estés trabajando (la rama divina por patrón de tarea ), cambia a ella. ¿Qué pasa si necesitas arreglar algo más? Fácil, simplemente cambie a una sucursal diferente después de registrar todo (con algunos scms ni siquiera necesita registrarse), corríjalo y vuelva a su sucursal original de "correo electrónico".