SVN¶
Diferencia entre dos revisiones distintas (N y M) del mismo fichero (con ruta Path)¶
1 | |
Limpiar meta-información SVN en una copia de trabajo¶
1 | |
En algunos sistemas lo anterior no funciona bien si los directorios tienen espacios en el nombre. Usar en este caso:
1 | |
Información sobre la copia de trabajo¶
1 | |
Redireccionar una copia de trabajo tras movimiento de repositorio¶
1 | |
Por ejemplo:
1 | |
Creación de un proyecto nuevo en un repositorio¶
Vamos a mostrarlo con el ejemplo del proyecto CCM dentro de la ruta svn.servidor.com/var/lib/subversion/ims, siendo la ruta de la copia de trabajo /home/edumoreno/NetBeansProjects/CCM.
1 | |
Antes de hacer el import sería interesante eliminar o mover los directorios o ficheros que no se desea que se sincronicen con el repositorio. Por ejemplo, en el caso de un proyecto NetBeans, éstos son:
CCM/buildCCM/distCCM/nbproject/private
Una vez eliminados o movidos hacemos el import:
1 2 | |
Ahora habría que hacer un checkout de lo que se ha subido para obtener la meta-información del repositorio:
1 2 3 | |
Finalmente hay que hacer ajustes para que se ignoren los siguientes directorios del nuevo repositorio:
- build
- dist
- nbproject/private
Esto en teoría se puede hacer con los siguientes comandos, pero aun no se ha probado:
1 2 3 4 5 | |
(Nota: El retorno de carro que hay al final del primer comando svn propset es intencionado)
Si por algún motivo los directorios hubieran entrado por descuido en el repositorio, habría que borrarlos tanto en el servidor como en local, ya que aunque se haya establecido la propiedad svn:ignore, se seguirían sincronizando:
1 2 3 4 5 6 7 | |
Creación de un branch¶
Para crear el branch simplemente hay que hacer una copia del trunk sin salir del repositorio. Para ello utilizar el siguiente comando:
1 | |
Luego si se desea trabajar en el branch recién creado habrá que bajar una copia de trabajo con el comando siguiente:
1 2 | |
Merge con el trunk¶
Cuando llegue el momento de hacer el merge, habrá que proceder de la siguiente forma. Como punto de partida necesitaremos una copia de trabajo del trunk:
Averiguamos la revisión en que construimos el branch. Esto se puede conseguir haciendo un log con la opción --stop-on-copy (que detiene la salida del comando en cuanto se detecta que la rama fue copiada o renombrada). Así, la entrada más antigua muestra lo que buscamos:
1 | |
Averiguamos la última revisión que contiene cambios en el branch:
1 | |
Nos situamos en el directorio de la copia de trabajo correspondiente al trunk y hacemos update:
1 2 | |
Antes de hacer el merge se puede simular, es decir, lanzarlo sin que aplique los cambios y que sólo muestre lo que va a hacer, incorporando la opción --dry-run. El comando sería:
1 | |
Una vez que estemos seguros hacemos el merge indicando la release inicial del branch como origen del intervalo de releases:
1 | |
Resolvemos manualmente los conflictos que inevitablemente existirán.
Hacemos el commit en el trunk de los cambios del branch recién incorporados:
1 | |
Análisis de diferencias ante un conflicto¶
Para listar los ficheros que tienen conflictos:
1 | |
Para listar los ficheros diferenciales de un conflicto:
1 | |
La interpretación de los sufijos que se añaden a los ficheros es (siendo MMMM la release de creación del branch y NNNN la del momento del merge):
<fichero_base>: Fichero de merge<fichero_base>.copia-de-trabajo: Última versión de la copia destino del merge (normalmente el trunk)<fichero_base>.derecha-fusion.rNNNN: Última versión de la copia origen del merge (normalmente el branch)<fichero_base>.izquierda-fusion.rMMMM: Versión común a ambas ramas, es decir, el punto del tiempo en que empezaron a diferenciarse
Para obtener una descripción de las diferencias habidas sobre la rama destino (normalmente el trunk):
1 | |
Para obtener una descripción de las diferencias habidas sobre la rama origen (normalmente el branch):
1 | |
Borrado de la rama¶
Si una vez hecho el merge no se va a continuar trabajando en el branch, se puede considerar su borrado. Esto se hace con la simple orden siguiente:
1 | |