visual-studio-2010 - para - visual studio code path intellisense
TF203015 El archivo Item $/path/tiene un cambio pendiente incompatible. Al intentar unshelve (8)
Este enlace resolvió mi problema:
El motivo estaba pendiente de cambio en el mismo espacio de trabajo crear un cambio incompatible. Deshaz los cambios pendientes y prueba unshelve. Esto debería resolver el problema.
Estoy usando Visual Studio 2010 Pro contra Team Server 2010 y mi proyecto se abrió (aparentemente) como una solución del repositorio, pero debería haberlo abierto como "sitio web". Descubrí esto durante la compilación, así que fui a dejar de lado mis nuevos cambios y borré el proyecto de mi disco local, luego volví a abrir el proyecto desde la fuente (esta vez como sitio web) y ahora no puedo retirar mis archivos.
¿Hay alguna forma de evitar esto? ¿Exploté algo? ¿Tengo que hacer mantenimiento en el servidor?
Encontré esta pregunta en SO # 2332685 pero no sé de qué archivos de caché está hablando (estoy en XP: /) EDIT: encontré este enlace después de publicar la pregunta, lo siento por el retraso en la investigación, todavía no lo hice arreglar mi problema
Por supuesto, no puedo encontrar un código de error para TF203015 en ninguna parte, por lo que tampoco hay resolución (de ahí mi inclusión del número en el título, ¿sí?)
EDIT: probablemente debería mencionar que estos archivos nunca se registraron en primer lugar. ¿Eso importa? ¿Puedes dejar de lado un artículo sin marcar? ¿Es eso lo que hice mal?
EDIT: WHAP - ¡LO ENCONTRÉ! Use "Deshacer" en los elementos que no existen porque aparecen en cambios pendientes como registros.
Esto podría ser lo mismo que la respuesta de jcolebrand, pero me temo que encontré el fraseo un poco abstruso. Sinceras disculpas si solo estoy repitiendo.
En mi escenario, el mensaje de incompatible pending change se presentó porque estaba intentando deshacer múltiples conjuntos de cambios, y el mismo archivo se vio afectado por más de uno de esos conjuntos de cambios.
En mi caso, no quería comprometerme hasta que todos los cambios se hubieran revertido. Creo que si hubiera podido comprometerme después de deshacer cada cambio, el error no habría ocurrido.
El método que funcionó para mí fue el siguiente:
- Opté por deshacer un conjunto de cambios a la vez. Descubrí que el uso de la línea de comando era en realidad una forma más informativa de hacerlo porque enumera todos los conflictos, mientras que creo que la reversión de la interfaz de usuario VS solo muestra la primera.
- Mientras retrotrae un conjunto de cambios, si había un
incompatible pending change, tuve que deshacer los cambios pendientes de mi espacio de trabajo para los archivos afectados. - Cuando todos los conjuntos de cambios se habían retrotraído, tuve que revertir manualmente los archivos que habían experimentado
incompatible pending change. En general, esto podría lograrse simplemente obteniendo una versión específica del archivo (la versión "último conocido" antes de que comenzaran todas las comprobaciones erróneas). Pero en el caso de algunos archivos en los que se habían producido los cambios deseados y los cambios no deseados, obtuve el "último bien conocido" y aplica manualmente los buenos cambios.
Había borrado los archivos al tratar de volver a cargar el espacio de trabajo, a pesar de que había archivado los cambios. Entonces VS2010 pensó que esos archivos aún estaban pendientes de guardarse. No lo necesitaba, así que tuve que resolver "deshacer" los cambios en los cambios pendientes.
Entonces podría desafiliarme.
Pensé que tenía dos operaciones (unshelve, commit-for-add) que iban simultáneamente, y pensé que solo tenía una opción (unshelve).
Si tiene dos ramas PRINCIPAL (objetivo) y DEV (origen), ahora quiere fusionar DEV en PRINCIPAL, entonces todos los archivos que desee fusionar de su fuente, no deben ser más antiguos que los archivos similares en su rama de destino.
Por ejemplo: tiene un archivo cambiado test.cs en su rama DEV, cambiado a 14.03.2016. En su rama MAIN, ha cambiado test.cs el 15.03.2016. Entonces el objetivo es más nuevo que el archivo fuente y tienes TF203015.
Solución: navegue en TFS Explorer hasta el archivo conflictivo y agréguelo explícitamente. TFS abrirá el administrador de conflictos y puede fusionar los conflictos a mano. A continuación puede fusionar el conjunto de cambios seleccionado.
Observaciones: Si tiene más conflictos, debe navegar a cada archivo de conflicto y fusionarlo de forma explícita, de modo que TFS abra el Administrador de conflictos y podrá fusionarlo a mano.
También podría ser que después de crear una carpeta en, por ejemplo, una "Prueba" y que desee fusionar de dev a prueba, no tenga la estructura de carpetas recién creada registrada en TFS. También obtendrá este mensaje de error.
Por lo tanto, este mensaje de error PUEDE ocurrir sin tener nada que ver con SHELVESETS, así como con otros que provienen de google y encuentran esta página.
Tenía lo que parecía ser el mismo problema, pero había creado una sucursal después de archivar mis cambios y quería retirar esos cambios a la nueva sucursal.
TFS no puede reubicarse en una ruta diferente a la ruta sobre la que se creó el estante.
Solución: No volví a albergar la rama original y luego la utilicé más allá de comparar para fusionar los cambios desde mi rama original a la nueva rama y registré.
Esto es un pequeño aparte de la pregunta del OP
Puede obtener un TF203015 cuando intente combinar por lotes múltiples conjuntos de cambios de una rama a la otra sin el debido cuidado.
Considere una situación en la que tenga un tronco principal y una rama DEV. Usted ha desviado DEV de MAIN y ha trabajado diligentemente en una función en DEV; revisando el trabajo de nuevo en DEV a medida que avanzaste. Ahora avance rápidamente una semana o dos. Ahora está completa y quiere volver a fusionarse en PRINCIPAL.
Aquí es donde uno de nuestros desarrolladores da con este error.
Había estado trabajando en una solución durante semanas, y comprobando los conjuntos de cambios de nuevo en DEV periódicamente, por lo que quería fusionar una serie no contigua de conjuntos de cambios en MAIN. Entonces escoge la opción de combinación, selecciona el primer conjunto de cambios; se fusiona sin problema, luego se fusionó inmediatamente con el siguiente conjunto de cambios; y bang TF203015, y su prueba muy poco útil en la ventana de salida; cambios pendientes incompatibles.
Después de jugar un poco, ahora nos damos cuenta de lo que está sucediendo aquí; la primera fusión creó un cambio pendiente en MAIN para la solución de desarrolladores. El siguiente intento de fusión también incluyó cambios en la misma solución, lo que requeriría que TFS "pusiera en cola" un segundo conjunto de cambios pendientes en los mismos archivos. No puede hacer esto.
Entonces, en este escenario, TF203015 significa; "La sucursal de destino ya tiene cambios pendientes en algunos archivos que se modifican en este conjunto de cambios. Resuelva y confirme los cambios de la sucursal de destino antes de realizar esta operación de fusión"
La solución; después de cada operación de fusión, nuestro desarrollador prueba el espacio de trabajo para MAIN y confirma el cambio pendiente causado por la combinación, luego vuelve a DEV y se repite.
Realmente sensato y simple, pero enmascarado por un mensaje de error muy obtuso.
Puede usar Team Foundation Server Power Tools marzo de 2011 ( http://msdn.microsoft.com/en-us/vstudio/bb980963.aspx ) que incluye el comando tfpt unshelve .
Una vez que se instalan las Herramientas de Poder, abra un símbolo del sistema de Visual Studio, cambie al directorio que contiene el proyecto de interés y ejecute el comando tfpt unshelve . Desenredará y mostrará el cuadro de diálogo de fusión para que pueda resolver los conflictos.
Le doy crédito a esta publicación de blog por ayudarme a encontrar esta solución: http://fluentbytes.com/the-how-and-why-behind-tf203015-file-has-an-incompatible-change-while-unshelving-a-shelve-set