subversion - tortoise svn subir cambios

Resolviendo un conflicto de fusión cuando hago svn update (3)

Cuando hay varias personas que cambian el mismo archivo a la vez, es muy posible que ambos cambien las mismas líneas. Esto es lo que te pasó. Sally cambia las mismas líneas que Harry estaba cambiando. Cuando Harry hizo svn update , Subversion detectó esto y te pregunta qué hacer.

Una advertencia: a veces Subversion solo busca diferencias en una línea entre su versión y su versión, y no diferencias significativas . Por ejemplo, si se cambió la sangría de una línea, el espaciado fue diferente, o si cambió los finales de línea, Subversion declarará esto como un conflicto, aunque probablemente no lo sea. Esto tal vez por qué el libro no encontró este problema, pero lo hizo. No significa que hiciste algo malo.

¿Qué hacer? La subversión te está dando algunas opciones.

posponer p : Esto es lo que normalmente hago con este tipo de situación. Subversion incrustará en los marcadores de diferencias de archivo que se ven así en el archivo:

<<<<<<< .mine foobar ======= fubar >>>>>>> .rxxx

Esto le muestra cómo se ven los cambios en la revisión rxxx (lo que hizo Sally) en comparación con los cambios que tiene (los cambios de Harry). Por lo general, los cambios son tan pequeños que es bastante fácil averiguar qué hacer.

show diff df : Esto le mostrará las diferencias entre sus cambios (Harry) y lo que está en la otra revisión (Sally). Básicamente te muestra los marcadores de diferencias.
Editar e : puede editar el conflicto de fusión al hacer la fusión en lugar de esperar hasta más tarde.
fusionar m : No estoy muy seguro de lo que hace esto. Estás haciendo la fusión ahora mismo, así que esto no tiene mucho sentido.
su lado del conflicto tc : Acepta lo que Sally hizo para resolver el conflicto. Probablemente tenga que rehacer sus cambios, pero al menos está considerando los cambios de Sally.
mi lado del conflicto mc : el escenario más peligroso porque estás ignorando completamente los cambios de Sally. Sally hizo un arreglo, y posiblemente lo estés arreglando. Cuando se publique el lanzamiento, y la solución de Sally no esté en él, se lo culpará por eliminar el cambio. Entonces, ¿por qué haces esto? Porque ya miraste los cambios y te diste cuenta de que el conflicto realmente no era mucho conflicto. Fue un cambio de sangrado o algo similar. O llamaste un increment variable y Sally lo llamó counter .

Como dije, por lo general hago un aplazamiento , dejo que termine mi actualización y luego manejo los problemas.

Una vez que solucione el problema, haga un svn resolved en ese archivo para que Subversion sepa que ha solucionado el conflicto.

Existen otras opciones: por ejemplo, puede iniciar una herramienta de combinación / diferencia de terceros para manejar el conflicto.

Para obtener más información, consulte el manual en línea de Subversion sobre cómo resolver conflictos de combinación .

Estoy tratando de aprender lo básico sobre el control de versiones por Eric Sink - http://ericsink.com/vcbe/vcbe_usletter_lo.pdf

Estoy en la página 22 ahora. Voy a describir el escenario para ti. Dos usuarios en la misma computadora, harry y sally están trabajando en un archivo llamado lottery.c que se almacena en un repositorio llamado lotería.

1 - Harry comete el primer código / inicial. 2 - Sally lo cambia y se compromete. 3 - Mientras 2 está sucediendo, Harry ha hecho cambios, pero no se ha comprometido. 4 - Harry comete y obtiene un error.

Transmitting file data .svn: Commit failed (details follow): svn: File ''/lottery.c'' is out of date

5 - Para arreglar esto, harry actualizará su copia local usando svn update .

¡Aquí es donde tengo un problema! El autor dice que la salida es:

lottery harry$ svn update G lottery.c Updated to revision 2.

Pero, mi salida es:

lottery harry$ svn update Updating ''.'': C lottery.c Updated to revision 2. Conflict discovered in file ''lottery.c''. Select: (p) postpone, (df) show diff, (e) edit file, (m) merge, (mc) my side of conflict, (tc) their side of conflict, (s) show all options:

Soy nuevo y no sé cómo responder a este mensaje. ¿Está mal mi libro? Por favor, ayúdame. Gracias.

La "G" indica que el archivo fue modificado por otra persona, pero las modificaciones que hizo esa persona se encontraban en una parte diferente del archivo, por lo que SVN podría fusionarlo sin pedir ayuda.

La "C" indica que no solo el archivo fue modificado por otra persona, sino que sus cambios fueron en las mismas líneas que usted también cambió, por lo que SVN no sabe qué hacer. Ahora es SU trabajo hacer la fusión.

Probablemente no hiciste nada malo, y el libro no está mal, simplemente dejaron de lado los detalles sobre los cambios específicos, al parecer.

Si seleccionas la opción s te mostrará:

(e) edit - change merged file in an editor (df) diff-full - show all changes made to merged file (r) resolved - accept merged version of file (dc) display-conflict - show all conflicts (ignoring merged version) (mc) mine-conflict - accept my version for all conflicts (same) (tc) theirs-conflict - accept their version for all conflicts (same) (mf) mine-full - accept my version of entire file (even non-conflicts) (tf) theirs-full - accept their version of entire file (same) (p) postpone - mark the conflict to be resolved later (l) launch - launch external tool to resolve conflict (s) show all - show this list

Use dc para ver los confiliadores, luego puede decidir cuál es la mejor opción para usar