Tipo de conflicto TFS: Archivo de escritura-Un archivo de escritura con el mismo nombre existe localmente

La respuesta de Grant es excelente para resolver múltiples conflictos.

En cuanto a por qué tiene esos conflictos, en términos generales, su cliente TFS ha detectado que existe un archivo localmente que no está administrado por TFS, pero está tratando de realizar una operación get que sobrescribiría ese archivo.

Si está siguiendo un flujo de trabajo de desarrollo normal (y no va y edita archivos fuera de su editor), la fuente más común de conflictos de escritura es de shelvesets. Si usted tenía que colocar un complemento en un archivo, luego tenía que deshacer ese complemento (ya sea explícitamente o porque dejó de lado el cambio y deseleccionó el botón conservar cambios pendientes), el archivo es no eliminado. (Esto es para evitar la pérdida de datos - no es raro que desee crear un archivo, pero no lo han registrado en el control de código fuente.)

Ahora si usted (o alguien más) fuera a comprobar en ese conjunto de estanterías (ya sea a través de la creación de una compilación de ese conjunto de estanterías, o de gated check-in, o porque su revisor de código se registró en su shelveset directamente), entonces cuando haga un get latest, su cliente TFS detectará que el archivo todavía existe localmente y, por lo tanto, tendrá un conflicto de escritura.

Esto puede no ser particularmente obvio en el caso de check-in cerrado. Cómo funciona realmente el check-in cerrado es cuando intentas registrar tus cambios, tu check-in se convierte en un shelveset. El agente de compilación de TFS intentará construir su conjunto de estanterías, y si la compilación tiene éxito, luego registrará ese conjunto de estanterías en su nombre. Si la compilación falla, el conjunto de estanterías permanece y puede desentrañar para corregir los errores de compilación.

Por esta razón, es importante ejecutar la aplicación de notificación de compilación cuando esté utilizando el registro cerrado, lo que le permitirá "conciliar" sus cambios una vez que se envíen. Reconciliar su check - in simplemente hará un get del check-in que fue enviado por el servidor de compilación, pero evitará conflictos ya que entiende el contexto de los cambios que están en su disco local. (Comparará el contenido de su disco local con el contenido del servidor.) Si no elige reconciliarse, desafortunadamente, tendrá conflictos de escritura en los archivos que se agregaron.

(Tenga en cuenta que este escenario no producirá un conflicto en la próxima versión de TFS - si no hay diferencias de contenido, TFS no producirá un conflicto.)