La Explicación
Cuando inicié con la conceptualización de estos proyectos decidí que el código fuente estaría cerrado para ayudar a mejorar un poco la seguridad con oscuridad, pero eso era antes de decidir que Drupal sería el motor, (originalmente el que se iba a encargar para esa tarea es un framework PHP que desarrollé por mas de dos años, que a pesar de no ser una obra de arte, tiene todo lo necesario para hacerse cargo de la tarea, sin embargo, el tiempo ha pasado, y la tecnología ha avanzado, así como los planes que tengo para el proyecto, pero sobre todo la cantidad que tiempo que tengo para invertirle al proyecto ha disminuído horrores! ya que finalmente decidí ser un ser humano normal y reintegrarme a la sociedad).por lo tanto la informaciónn realmente importante estará en una base de datos y no en el código.
y seguramente se preguntarán - ¿y esto que tiene que ver? y pues es que en esta segunda parte de las Crónicas de Narnia hablaré de como optimicé el espacio de mi repositorio. ¿y porqué me habría de preocupar por eso? y les podría decir que por buena-práctica, pero la realidad es porque a raíz de la decisión de cerrar parte de mi código inicié a usar un repositorio privado en CodeBase, que además de tener las mismas (si no es que mas) características que GitHub, tiene soporte para diversos sistemas de control como Mercurial, SVN, Bazaar, etc.
Como Github, CodeBase tiene una cuenta gratuita, la diferencia: el repositorio puede ser privado, el defecto: hay límite de usuarios y de espacio, para naturalmente, “invitar” a sus usuarios a contratar los servicios premium.
Ok, ya están en contexto, ahora hablemos de Drupal, en específico de su repositorio Git, en el momento que escribo estas lineas están en la versión 8.x del proyecto y el repositorio contiene tags y branches que datan hasta la versión 3.x, lo que nos da un total de aproximadamente 40Mb de datos que cualquier colaborador tiene que descargar cada vez que clona el repo; digo, probablemente 40Mb no suenan a mucho, pero si tomamos en cuenta que 1) tengo un límite en mi repositorio privado y 2) Agregaré aún mas contenido. esto empieza a ser un problema.
La solución
Resolver esto es sencillo, simplemente no tomes en cuenta la repo de Drupal y crea la propia con el contenido de la versión actual y creo mi propia repo de cero, pero … ¿y cuando quiera actualizar? a pesar de que Drush ofrece una interfaz intermediaria para actualizar Drupal, no hay porqué usar una herramienta extra cuando perfectamente puedo usar la herramienta original para mis necesidades.
La alternativa que se me ocurrió y que implementaré es igual sencilla, pero requiere de un par de pasos extra, la teoría dice así:
Crear una repo local, añadir un remote que solo haga tracking a una branch en específico, no descargar tags, y además crear una branch aislada que me permita desarrollar paralelamente mis implementaciones permitiéndome actualizar la branch de drupal por un lado, y hacer pushes a mi servidor privado por el otro, sin tener que estar pasando información del repo de Drupal.
Sencillo, ¿no? … pero, ¿cómo lo implementamos?
La implementación
Primero, bajar la última versión de Drupal en las series 7.x e ignorar lo demás.
-
Crear un repositorio vacío:
~/www/$ mkdir drupal && cd drupal && git init -
Añadir un remote apuntando a drupal especificándo que solo nos interesa un branch
~/www/drupal$ git remote add \ -f -t 7.x -m 7.x --no-tags drupal \ et0r@git.drupal.org:/project/drupal.git-f: Hacer fetch justo después de añadir el remote.-t <branch>: Especificar la branch que será nuestro target.-m <master>: Especificar la referencia simbólica que estará apuntando a la branch remota.--no-tags: No descargar y establecer etiquetas remotas.<nombre>Nombre con el que referiré al repositorio.<url>La ruta remota del repositorio.
-
Especificar la branch que obtendrá los merges remotos:
~/www/drupal$ git co -b 7.x -t drupal/7.x<name>Nombre del branch local-b <branch>El nombre de la branch local-t <remote>/<branch>Nombre de la branch remota con la que la branch local sincronizalá.
Ahora la interesante, crear una branch completamente aislada de la branch 7.x que usaremos como sandbox.
-
Añadir el remote privado:
~/www/drupal$ git remote add --tags codebase \ et0r@git.codebasehq.com:/project/drupal.git` -
Crear una branch completamente aislada de la branch actual
~/www/drupal$ git symbolic-ref HEAD refs/heads/nuevabranch ~/www/drupal$ rm .git/index -
Añadir los archivos existentes al índice:
~/www/drupal$ git add . -
¡y listo! ya podemos hacer commit:
~/www/drupal$ git commit -m "First Commit" -
y podemos hacer push al repo privado:
~/www/drupal$ git push codebase -u --force
Y de esa manera, en lugar de desperdiciar espacio en la repo privada haciendo tracking de 40Mb+, mi branch inicial usa 2Mb, y no pierdo la funcionalidad de hacer merges desde el servidor Drupal.
Seguramente existen mejores maneras de lograr esto, o inclusive mi approach es incorrecto, pero hasta el momento estoy logrando el objetivo inicial.
En la siguiente parte, hablaré de la nomenclatura y estrategia general de control.