Sig: svn export Sup: Use Subversion: Creación de Ant: Autopropiedades
Conforme evolucionan los proyectos descubrimos que existen áreas comunes entre ellos que pueden factorizarse y ser reutilizadas en varios proyectos.
Una forma de gestionar la compartición de subproyectos entre proyectos es mediante
la propiedad svn:externals, la cual nos permite incluir contenidos en
otro repositorio en nuestra copia de trabajo.
Por ejemplo, en la mayoría de los artículos y apuntes que escribo en LATEX
comparto la bibliografía. En vez de tener múltiples ficheros .bib de
bibliografía por artículo prefiero tener uno garantizando así la consistencia.
Del mismo modo comparto los ficheros de estilo LATEX y las definiciones de comandos
LATEX. Así en el proyecto svn de estos apuntes que lee tenemos:
pp2@nereida:~/Lbook$ svn proplist . Propiedades en '.': svn:externals pp2@nereida:~/Lbook$ svn propget svn:externals perlbib svn+ssh://casiano@arlom.pcg.ull.es/var/svn/casiano/BIBTEX/PERLBIB/trunk booktt svn+ssh://casiano@arlom.pcg.ull.es/var/svn/casiano/booktt/trunk lhplabels svn+ssh://casiano@arlom.pcg.ull.es/var/svn/casiano/LHP/perlexamples/labels.plSubversion no hace automáticamente
commit de los cambios
en las copias de los subproyectos externos. Es necesario cambiar al directorio
en cuestión y ejecutar svn commit.
pp2@nereida:~/Lbook$ svn status -qu Estado respecto a la revisión: 5463 Averiguando el estado del recurso externo en 'perlbib' Estado respecto a la revisión: 5463 Averiguando el estado del recurso externo en 'booktt' Estado respecto a la revisión: 5463
He aquí un ejemplo de como establecer svn:externals:
MacBookdeCasiano:LPLDI2011 casiano$ svn propset svn:externals \ 'code svn+ssh://casiano@orion.pcg.ull.es/var/svn/casiano/PL/PLconferences/softwarepracticeandexperience/code' . property 'svn:externals' set on '.'Obsérvese el uso de las comillas simples protegiendo al segundo argumento de
svn propset.
Ahora un update cargará el subproyecto externo:
MacBookdeCasiano:LPLDI2011 casiano$ svn update Fetching external item into 'code' A code/MyopicPPCR.eyp A code/pascalnestedeyapp2.eyp A code/noPackratSolvedExpRG2.eyp A code/pascalnestedeyapp3.eyp A code/pascalenumeratedvsrangePPCR.eyp A code/reducereduceconflictnamefirst.eyp A code/Cplusplus.eyp A code/pascalenumeratedvsrangesolvedviadyn.eyp A code/dynamicgrammar.eyp A code/Range.eyp A code/nopackratSolved.eyp A code/reducereduceconflictPPCRwithAction.eyp A code/Myopic.eyp A code/noLRk_exp.eyp A code/Calc.eyp A code/input_for_dynamicgrammar.txt A code/pascalenumeratedvsrange.eyp A code/noPackratSolvedExpRG.eyp A code/pascalenumeratedvsrangenested.eyp A code/reducereduceconflictPPCR.eyp A code/nopackratPPCR.eyp A code/noPackratSolvedExp.eyp A code/Cplusplus2.eyp A code/MyopicSolved.eyp A code/pascalenumeratedvsrangesolvedviadyn2.eyp A code/noLRk_expSolved.eyp A code/noPackratSolvedExpRGconcept.eyp A code/reducereduceconflict.eyp A code/nopackrat.eyp Updated external to revision 6318. Updated to revision 6318. MacBookdeCasiano:LPLDI2011 casiano$
Consejo tomado del libro de subversión:
You should seriously consider using explicit revision numbers in all of your externals definitions. Doing so means that you get to decide when to pull down a different snapshot of external information, and exactly which snapshot to pull. Besides avoiding the surprise of getting changes to third-party repositories that you might not have any control over, using explicit revision numbers also means that as you backdate your working copy to a previous revision, your externals definitions will also revert to the way they looked in that previous revision, which in turn means that the external working copies will be updated to match they way they looked back when your repository was at that previous revision. For software projects, this could be the difference between a successful and a failed build of an older snapshot of your complex codebase.
Casiano Rodríguez León
