Team Foundation Server - Cambios combinado previamente vuelven a aparecer en el asistente de fusión

Nuestra estructura SMC es el siguiente:Team Foundation Server - Cambios combinado previamente vuelven a aparecer en el asistente de fusión

Main 
|--Release

Desarrolladores registro hasta la principal. Cuando queremos lanzar, seleccionamos los conjuntos de cambios de Main a Release, probamos y ejecutamos nuestra build de despliegue que construye e implementa la aplicación y etiqueta la rama de lanzamiento como tal.

Para fusionar, utilizaría el Source Control Explorer, haga clic derecho en 'Main'> Branching and Merging> Merge. Elija 'Selected Changesets' Hay solo una rama Target (Release). Seleccione los conjuntos de cambios, realice pruebas localmente, regístrese en Liberar. Esto funcionó bien por meses.

Sin embargo, hoy algunos conjuntos de cambios muy tempranos acaban de aparecer en el asistente de combinación de control de fuente, en la parte superior de la lista. Pero extrañamente, no todos.

El comando CLI equivalente es

tf merge /candidate /recursive [source] [destination]

este comando devuelve la siguiente lista:

3* Person.One  27/11/2009 
    43* Person.Two  21/12/2009 
    50* Person.Two  22/12/2009 
    54* Person.Two  22/12/2009 
    57* Person.Two  22/12/2009 
114* Person.One  12/01/2010 
116* Person.One  13/01/2010 
128* Person.One  15/01/2010 
138* Person.One  19/01/2010 
139* Person.One  19/01/2010 
7846 Person.Three 19/01/2012 
7847 Person.Three 19/01/2012 
7848 Person.Three 19/01/2012 
7849 Person.Three 19/01/2012 
8030 Person.Four  31/01/2012 
8031 Person.Four  31/01/2012 
8032 Person.Four  31/01/2012 
8045 Person.Five  01/02/2012 
8050 Person.Four  01/02/2012 
8052 Person.Six  01/02/2012 
8053 Person.Six  01/02/2012 
8054 Person.Three 01/02/2012 
8055 Person.One  01/02/2012 
8056 Person.Seven 01/02/2012 
8057 Person.Five  01/02/2012 
8058 Person.Six  01/02/2012 
8059 Person.Five  01/02/2012 
8060 Person.Five  01/02/2012 
8063 Person.Five  02/02/2012 
8068 Person.Five  02/02/2012 
8069 Person.Eight 02/02/2012 
8070 Person.Five  02/02/2012 
8071 Person.Five  02/02/2012 
8072 Person.Five  02/02/2012 
8073 Person.Three 02/02/2012 
8074 Person.Three 02/02/2012 
8077 Person.Seven 02/02/2012

La única 'pista' es el asterisco que creo que significa que una fusión parcial ya se ha completado .

Estoy totalmente perplejo por cómo podría pasar esto. No se ha realizado ninguna administración en el servidor. Ha sucedido en las últimas 6 horas más o menos.

Si intento fusionarme en mi área de trabajo, no tengo conflictos, y, bueno, no estoy seguro de qué pasaría si me registrara. Obviamente, los archivos y la estructura han cambiado mucho en dos años.

Puedo usar el comando tf merge/discard para 'hacer que se vayan' pero me gustaría llegar al final de por qué sucedió, por mi propia curiosidad, nada más.

TIA

Actualización:

que haya sido elegido para 'desprenderse' los conjuntos de cambios que habían aparecido con el siguiente comando:

tf merge /discard /recursive [source] [destination] /version:C3~C139

Esto dio lugar a una selección de los cambios pendientes en mi espacio de trabajo, que debidamente ingresé.

Desafortunadamente, si ejecuto

tf merge /candidate /recursive [source] [destination]

ahora tienen cambios aún más históricos 'en espera' fusionarse, incluyendo los que he tratado de desprenderse en el primer intento:

3* Person.One  27/11/2009 
    43* Person.Two  21/12/2009 
    50* Person.Two  22/12/2009 
    54* Person.Two  22/12/2009 
    57* Person.Two  22/12/2009 
114* Person.One  12/01/2010 
116* Person.One  13/01/2010 
128* Person.One  15/01/2010 
138* Person.One  19/01/2010 
139* Person.One  19/01/2010 
140 Person.One  19/01/2010 
141* Person.One  19/01/2010 
142* Person.Two  19/01/2010 
149* Person.Two  20/01/2010 
152* Person.Two  20/01/2010 
160* Person.Two  21/01/2010 
161* Person.Two  21/01/2010 
165* Person.One  21/01/2010 
167* Person.Two  22/01/2010 
173* Person.Two  22/01/2010 
199* Person.Two  27/01/2010 
200* Person.One  27/01/2010 
203* Person.Two  28/01/2010 
204* Person.Two  28/01/2010 
205* Person.Two  28/01/2010 
206* Person.Two  28/01/2010 
208* Person.Two  28/01/2010 
213 Person.Two  28/01/2010 
215* Person.Two  28/01/2010 
235* Person.Two  01/02/2010 
238* Person.Two  02/02/2010 
241* Person.Two  02/02/2010 
259* Person.Two  04/02/2010 
262* Person.Two  04/02/2010 
264 Person.Two  05/02/2010 
296* Person.Two  10/02/2010 
309* Person.Two  11/02/2010 
316* Person.Two  12/02/2010 
317* Person.Two  12/02/2010 
320* Person.Two  12/02/2010 
338* Person.Two  15/02/2010 
353* Person.Two  16/02/2010 
365* Person.Two  18/02/2010 
394* Person.Two  22/02/2010 
399* Person.One  22/02/2010 
400* Person.One  22/02/2010 
401* Person.Two  23/02/2010 
403* Person.Two  23/02/2010 
404* Person.Two  23/02/2010 
405* Person.Two  23/02/2010 
424* Person.One  25/02/2010 
426* Person.Two  26/02/2010 
444* Person.Two  02/03/2010 
445* Person.One  03/03/2010 
461* Person.Two  08/03/2010 
476* Person.One  10/03/2010 
477* Person.One  10/03/2010 
478* Person.One  10/03/2010 
501 Person.One  12/03/2010 
502 Person.One  12/03/2010 
503 Person.One  12/03/2010 
504 Person.One  12/03/2010 
506 Person.One  12/03/2010 
511* Person.One  12/03/2010 
515* Person.One  15/03/2010 
517* Person.Two  15/03/2010 
518* Person.One  15/03/2010 
522 Person.One  16/03/2010 
523 Person.One  16/03/2010 
538 Person.Two  17/03/2010 
539 Person.Two  17/03/2010 
540 Person.Two  17/03/2010 
543 Person.One  17/03/2010 
581* Person.Two  18/03/2010 
582* Person.Two  18/03/2010 
644* Person.Two  26/03/2010 
706* Person.One  30/03/2010 
918* Person.One  13/05/2010 
1594* Person.One  15/07/2010 
1601* Person.One  16/07/2010 
1626* Person.Three  20/07/2010 
1627* Person.Three  20/07/2010 
6153* Person.One  17/08/2011 
7691* Person.Four  11/01/2012 
7846 Person.Four  19/01/2012 
7847 Person.Four  19/01/2012 
7848 Person.Four  19/01/2012 
7849 Person.Four  19/01/2012 
8030 Person.Five  31/01/2012 
8031 Person.Five  31/01/2012 
8032 Person.Five  31/01/2012 
8050 Person.Five  01/02/2012 
8054 Person.Four  01/02/2012 
8073 Person.Four  02/02/2012 
8074 Person.Four  02/02/2012 
8104 Person.Six  03/02/2012 
8110 Person.Six  03/02/2012 
8112 Person.Seven  03/02/2012 
8113* Person.Five  03/02/2012 
8114* Person.Five  03/02/2012 
8127 Person.Seven  06/02/2012 
8128 Person.Seven  06/02/2012 
8130 Person.Eight  06/02/2012 
8135 Person.One  06/02/2012 
8138* Person.Five  06/02/2012 
8140 Person.Five  06/02/2012 
8142 Person.Five  06/02/2012 
8143 Person.Nine  06/02/2012 
8144 Person.Nine  06/02/2012 
8145 Person.Ten  06/02/2012 
8146 Person.Eleven  06/02/2012

Realmente no tengo idea de lo que ha causado que esto suceda. Cualquier consejo apreciado.

Fuente

2012-02-02 Jamie

Tiene razón, el "*" significa que algunos archivos en el changset 3 se han combinado en "liberar" y otros no. Esto generalmente se soluciona al desmarcar los archivos en la ventana de cambios pendientes al fusionarse.

¿Se ha actualizado recientemente de TFS 2008?Tuvimos la misma situación después de nuestra actualización. En TFS 2008, si desactivó un archivo de un registro de fusión, TFS asumió que nunca quiso fusionar ese archivo para siempre. La única forma de recoger los archivos no revisados era soltar a la línea de comando y usar tf merge /force

En TFS 2010, el comportamiento ha cambiado y ahora si realiza una fusión parcial, TFS siempre le recordará que hay candidatos de fusión pendientes en un conjunto de cambios parcialmente fusionado

Puedes hacer 2 cosas.

fusionar las changsesets (que es poco probable que usted quiere hacer esto teniendo en cuenta la longitud de tiempo que ha pasado)
utilice el comando tf merge /recursive /discard /version:C3~C139 [source] [destination] Esto le dirá TFS que usted quiere que creo que ha hecho la fusión incluso aunque no se ha

Fuente

2012-02-02 19:59:50

Hola James, muchas gracias por tu ayuda. Actualizamos de TFS 2008 hace aproximadamente 6 meses y tuvimos un problema en el que nuestras compilaciones solían asociar cada conjunto de cambios desde el principio de los tiempos con ellos. Eventualmente encontramos un parche para solucionar ese problema, pero no estoy seguro de si está relacionado. Estoy de acuerdo en que descartar los cambios parece ser la mejor opción, pero mire arriba para mi actualización. – Jamie

Hola Jamie, para ser sincero, me he quedado sin sugerencias. El descarte hizo el trabajo por nosotros. Supongo que puedes intentar descartar todo hasta el 7691 (no uses un rango, solo usa un número de conjunto de cambios) que parece que podría llevarte a un lugar donde puedes reanudar la fusión normalmente. Si hay conjuntos de cambios más antiguos que necesiten fusionarse, entonces necesitarás quitar el código manualmente, lo cual no sería genial, pero con suerte sería uno para sacarte de un agujero –

Si, descartar no me ha funcionado. Acabamos de cortar una rama de publicación de nuestro tronco, ahora hay muchos conjuntos de cambios "antiguos" que aparecen en la lista de candidatos de combinación al fusionar Troncal-> Versión. Descartar candidatos solo trae más candidatos, ¡es como una Hidra! Este es el caso de uso de control de fuente básico ... ¡¡vamos TFS !!! (estamos usando TFS 2012 por cierto) – Arnaud

Determinamos que el motivo de este comportamiento era que un archivo previamente eliminado se había 'resucitado' en la rama Principal, en el sentido de que se había creado un archivo nuevo con el mismo nombre.

Cuando esto sucedió, todos los conjuntos de cambios anteriores que tenían este archivo en ellos reaparecieron en el cuadro de diálogo de fusión como conjuntos de cambios parciales.

Una combinación completa pareció resolver el problema.

Fuente

2012-05-02 10:39:46 Jamie

Estoy bastante seguro de que estoy viendo exactamente el mismo problema. Gracias por resolver esto. – George

Me encontré con un comportamiento extraño similar. Usamos una metodología similar a la OP, pero también hacemos cambios a nuestras sucursales de lanzamiento según sea necesario.

Fui a fusionar algunos cambios de una versión anterior (llamada "2.30") a una nueva versión (llamada "2.31") a través de la principal y cuando fui a fusionar los cambios de la versión principal a la versión 2.31, vi una pocos conjuntos de cambios en el asistente de fusión de hace años, ¡uno de ellos fue desde 2011!

Nunca antes había visto este comportamiento y pensé que tal vez esta rama de lanzamiento estaba de alguna manera contaminada mágicamente y que iba a deshacerse de ella y crear una nueva versión en su lugar.

Así que fusioné todos los cambios realizados en la rama de publicación 2.31 con la copia de seguridad y la revisé. Antes de crear una nueva rama para reemplazar 2.31, pensé en probar el asistente de fusión nuevamente (fusionándome desde principal a 2.31) para ver si eso lo despejó mágicamente y así fue. Ninguno de esos viejos conjuntos de cambios apareció de nuevo.

Muy extraño.

Fuente

2016-03-03 05:12:06

Team Foundation Server - Cambios combinado previamente vuelven a aparecer en el asistente de fusión

Respuesta

Cuestiones relacionadas