svn:externals re-utiliza tus repositorios.
Los programadores con algo de experiencia tendemos a dar todas las vueltas del mundo necesarias antes de repetir código, por lo que también es normal que tengamos tendencia a separar un proyecto grande en varios más pequeños por aquello de reutilizar código.
Por ejemplo, en un repositorio tengo una librería que utilizo para muchos de mis proyectos, llamada SLB, y en otro repositorio tengo mi proyecto killer-ap1. El proyecto de killer-ap1 utiliza activamente SLB, hasta el punto de que voy haciendo mejoras en SLB según veo que hacen falta en killer-ap1… por lo que suelo copiar SLB enterito dentro de killer-ap1 y compilarlo todo a la vez.
$ls proyectos/killer-ap1
src
include
SLB (mi copia particular)
El problema es que esta copia esta versionada una vez en el repositorio oficial y otras tantas en cada uno de los proyectos donde la uso, concretamente en killer-ap1. Además hay que acordarse de mantener actualizadas todas esas copias… por ello los de subversion idearon una solución mejor, los svn:externals.
La propiedad svn:externals nos permite enlazar en un repositorio con otros externos a este, de forma que cuando se haga un checkout del nuestro automáticamente también se bajará los otros. Ejemplo (de la página del svnbook):
$ svn propget svn:externals calc
third-party/sounds http://sounds.red-bean.com/repos
third-party/skins http://skins.red-bean.com/repositories/skinproj
third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker
Con esto estamos diciendo que el directorio calc tiene dentro tres directorios ‘thir-party/sounds’ ‘third-party/skins’ y ‘third-party/skins/toolkit’ que hacen referencia a repositorios externos(y en el último caso una revisión concreta la 21). También le estamos diciendo a subversion que cuando pase por calc se baje automáticamente los repositorios externos, y que los mantenga sincronizados.
Para mi caso de killer-ap1 y SLB la cosa ha sido así:
svn propset svn:externals «SLB http://svn.pplux.com/SLB/trunk» path/de/killer_ap1
Esta línea dice: «en el raiz de killer-ap1 vas a poner un directorio «SLB» que está sincronizado con el repositorio http://…»
Si en vez de uno tienes varios, los separamos con «\n», el ejemplo del svnbook hubiera sido algo como:
svn propset svn:externals «third-party/sounds http://sounds.red-bean.com/repos\n third-party/skins http://skins.red-bean.com/repositories/skinproj\n third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker» calc
Un poco largo pero ilustra lo que se pretende, tener más de un external en un mismo directorio.
Y lo mejor de todo, que todas las copias siempre están sincronizadas, ya sean externals o no 😀
Muy guay nen. La única putada que tiene es que tienes que hacer los commits de los repositorios externos por separado, aunque si usas TortoiseSVN te lo pilla todo. También funciona con Eclipse y con el Bundle de subversion de Textmate.
Por cierto, podrías poner el marcador del cursor en otro color, que está en negro y no veo dónde estoy escribiendo. (Ya sabes que lo mío es ser betatester X) )
Posi pepe-manuel, pero por lo menos el svn «status» te dice los repositorios externos que has modificado… algo es algo 🙂
(de todas formas el artículo era para los que *no* lo habían usado XD)
y lo del cursor negro… debe ser cosa del safari, o de mac, o de Steve Jobs XDDD
Es que yo no lo había usado, joer. Lo ponía para que la gente lo sepa, que si no se piensan que hacen commit de todo y luego faltan cosas.
Pos es verdad, aquí en windows sale blanco. Si es que estas páginas web cutres, que según donde estés salen de una manera o de otra…. 😀