Ficheros problemáticos en el repositorio
En el trabajo utilizo PHPStorm. Este IDE, al igual que todos los de JetBrains, utiliza la carpeta de proyecto .idea. Hay que tener cuidado de no trackear ciertos ficheros «temporales» contenidos en ella, porque son específicos del usuario y cambian constantemente. Un ejemplo es .idea/workspace.xml. Un compañero lo había agregado y me causaba conflictos al hacer merge. Podemos añadirlo a .hgignore y hacer hg forget, pero esto sólo afecta a commits posteriores. Permanecerá en los anteriores, y provocará conflictos si queremos volver a revisiones previas. Para eliminarlo definitivamente, hay que reescribir todo el repositorio. Esto requerirá que los demás desarrolladores vuelvan a clonar, así que debemos contar con su colaboración. El procedimiento usa la extensión convert. Para activarla, añadir al fichero hgrc lo siguiente:
[extensions]
hgext.convert=
Adjunto aquí la explicación:
- Make sure all your teammates have pushed their local changes to the central repo (if any)
- Backup your repository
- Create a «map.txt» file with the following content:
# this filemap is used to exclude specific files
exclude "subdir/filename1.ext"
exclude "subdir/filename2.ext"
exclude "subdir2"
- Run this command:
hg convert --filemap map.txt c:/oldrepo c:/newrepo
NOTE: You have to use «forward-slash» in paths, even on windows.
- Wait and be patient
- Now you have a new repo at
c:\newrepo but without the files
PS. In the «upper» repo you have to remove all changesets and re-push your new repo.
PPS. I actually wrote a blog post about this that has more details (including stripping the changesest in Bitbucket etc.
En el último paso menciona que no tendremos los ficheros. Efectivamente, sólo encontraremos la carpeta .hg en c:\newrepo, y TortoiseHg nos mostrará la advertencia «No es una revisión de cabecera!». Basta con hacer hg update en la última revisión, y reaparecerá todo.
Otros ficheros incómodos que he borrado con este procedimiento son los binarios y objecto. Son subproductos de la compilación y no debemos incluirlos. Aumentan muchísmimo el tamaño del repositorio. Para eso ya existen los repositorios para binarios.
Actualización 26-10-2016
Hoy he tenido que utilizar nuevamente este método para un nombre de fichero con acentos que se creó en Windows. Parece que Mercurial los guarda internamente con codificación cp1252 en este sistema operativo. Esto da problemas en Linux, donde se interpreta como utf-8. El resultado es un hg status limpio en Windows, pero una advertencia de fichero sin tracking (?) junto con fichero no encontrado (!) en Linux:
[j@localhost Server_fix_2]$ hg status
[...]
! jasperserver/doc/Actualizaci�n de Jasperserver.odt
? jasperserver/doc/Actualización de Jasperserver.odt
[...]
[j@localhost Server_fix_2]$ hg status –all > hg_status_all.txt
Si vemos hg_status_all.txt interpretado como cp1252:
! jasperserver/doc/Actualización de Jasperserver.odt
? jasperserver/doc/Actualización de Jasperserver.odt
Si lo interpretamos como UTF-8:
! jasperserver/doc/Actualizaci�n de Jasperserver.odt
? jasperserver/doc/Actualización de Jasperserver.odt
Ejecutamos convert desde Windows con este map.txt. Cuidado porque tenemos que verificar que este fichero esté codificado en CP1252, o «ANSI», como lo llama Notepad++. También es la codificación por defecto del Notepad nativo de Windows:
exclude "jasperserver/doc/Actualización de Jasperserver.odt"
Después del hg convert + hg update, el fichero desapareció, al estar excluído. Lo copié del repositorio antiguo, pero esta vez cambiando el nombre a «actualizacion_de_jasperserver.odt» (nótese la ausencia de acentos). Ahora hg status mostraba:
D:\codigo\Server_fix_3>hg status
? jasperserver\doc\actualizacion_de_jasperserver.odt
… y funcionó bien en Linux.
Así que ya sabemos… si queremos compartir repositorios entre Windows y Linux… cuidado con los acentos. He encontrado este enlace donde se deja claro:
- non-ASCII filenames are not reliably portable between systems in general
- ASCII is the only perfectly cross-platform strategy
- Only using Windows, only using Unix, or configure all clients with the same character set also works