Hace unas semanas gracias a la ayuda de sarah y ryan he estado trabajando solucionando bugs en el sitio Getpersonas.com (El sitio esta hecho en PHP, y el repositorio usa SVN), esto me ha traído devuelta al mundo de los sistemas de control de versiones (Lo que es genial, por que me gustaba caleta hacer commits, y tener todo ordenado, como cuando trabajaba …)

Cuando ya tenia mis permisos de commit listos para el repo SVN, ryan me recomendó git-svn (Lo que también es genial, por que tenia mas experiencia con Git que con SVN). Así que para aprovechar los bytes de este post, pondre mi setup de Git+SVN, algo del workflow diario y lo ultimo con lo que estuve jugando esta semana: ZSH (Aun estoy amando la integracion con Git).

It’s time to start

Montar el repositorio con Git-SVN

La instalación es muy simple, en Ubuntu basta con un

sudo apt-get install git-svn git-core

Ahora comenzamos a clonar el repo, por ejemplo para el repo de getpersonas en mozilla:

mkdir getpersonas && cd getpersonas

git svn init https://svn.mozilla.org/projects/getpersonas.com/trunk/

git svn fetch -r $REVISION

# (Donde $REVISION es la ultima revision donde se toco la direccion del repo, si le hacen un svn info http://svn.mozilla.org/projects/getpersonas.com/trunk/ veran “Revision del último cambio”. Si quieren le pueden tirar un git svn fetch a secas, pero se bajara TODAS las revisiones del repo svn, osea que si tienen miles y miles de commits, se volveran locos en pocos minutos)

# Si por algun motivo les pasa que se baja la revision, pero los ficheros no aparecen y el git status les dice que hay cambios hechos, y que son ficherros eliminados, intenten dando un

git reset && git checkout .

Con esto ya estamos listos para comenzar a trabajar

Git branchs, patches, merge y commits al server svn

Para trabajar en los bugs, ryan me recomendo usar un branch local de git, para cada bug. Easy cake.

git checkout -b sumario_bug

Y veremos las magicas palabras “Switched to a new branch ’sumario_bug’”, pueden usar cualquier nombre para la branch local, ojala uno descriptivo para acordarse.

Aquí podemos ir realizando los cambios para arreglar el bug (O meter funcionalidades nuevas, el mundo es suyo). Pueden hacer commits al branch, por ejemplo con git commit -a. Con esto listo, podemos usar format-patch y enviar parches:

git format-patch master -o ~/parches/

Este ultimo comando nos generara un parche git, en el directorio ~/parches. Cuando tengamos aprobados los cambios, podemos hacerle un merge con master (la rama principal):

git checkout master

git merge sumario_bug

git svn rebase

Con esto, cambiamos al branch master, hicimos un merge del branch local sumario_bug (Nota aqui, si hicieron mas de un commit en el branch sumario_bug, y quieren que se refleje como solo un commit en SVN, deberan aplicar el switch –squash al git merge), y con el rebase, bajamos los posibles cambios que tenga el repositorio svn y aplicamos nuestros cambios sobre eso (Atentos si hay problemas con el merge que esto provocara). Si no tuvimos ningun problema al hacer el merge y el rebase, o los solucionamos, estamos listos para hacer commit hacia SVN:

git svn dcommit

Que nos pediria los datos del server svn (En este caso, puedo hacer commit por https con mis datos LDAP)

There, estariamos listos para continuar con otro bug.

Para actualizar el repo podemos usar git svn fetch o git svn rebase (El fetch solo baja los cambios, mientras que el rebase intentara un merge si tenemos cambios en la rama local)

Cosas cools, git stash

Otra herramienta genial en git, seria stash, ponganse en este caso, estan trabajando en un branch, tienen harto trabajo hecho y aun no le dan un commit, y llega un bug feo que hay que solucionar ASAP, tendrian que hacer un commit tipo “Dejo guardado el trabajo en esta rama para trabajar en el desgraciado bug feo”; con stash pueden solucionar esto fácilmente:

git stash save "Bug #1234: Cambiar identacion para que el codigo se vea mas lindo"

git checkout master

git checkout -b bug_desgraciado_asap

[...] Terminaron de trabajar en el bug, le dieron commit y todo el cuento, ahora a trabajar en el branch que teniamos antes

git checkout mi_viejo_branch_ya_no_es_lo_que_era

git stash pop stash@\{0\}

Y aplicara los cambios que teníamos antes de trabajar en el bug feo!

Un poco mas sobre stash seria que, no es necesario pasarle un nombre al git stash save, con git stash list listaran los stash que tienen guardados, con git stash show -p stash@\{0\} u otro numero, mostraran el contenido del stash (Noten que el -p viene de git diff, asi que pueden usar cualquier switch del git diff).

Un pager mas bonito

Cuando hacen un git diff, quizas no les guste mucho, si es así pueden usar otro comando para el pager, por ejemplo most:

# ~/.gitconfig

[...]

[core]

pager = most +s +’/—’

[...]

Necesitaran tener most instalado, la otra gracia que hará, será buscar la línea que comience con — (Que es como git define cada cambio, así que automáticamente llegaran al primer cambio en un git diff por ejemplo).

Finalmente, ZSH

El otro dia netkrash nos contaba en irc que estaba usando zsh con los scripts de Oh My ZSH, que tenía completación de nombres para el kill (Onda kill -9 Adi[tab] buscaba el proceso con ese nombre y extraia el pid), completación de hostnames para ssh|scp, y lo que mas me intereso, integración con git … cuando leí eso ultimo lo instale altiro!

Bueno, la instalacion de ZSH es bien simple:

sudo apt-get install zsh

Luego pueden instalar oh my zsh, el instalador automático bastara (Nota para algunos, NECESITAN tener instalado zsh antes de oh my zsh, aviso por si las moscas …):

wget http://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh


Y ya estan listos, si quieren meter mano en los configs de oh my zsh, pueden hacerlo en .oh-my-zsh. Al momento tengo algunos cambios en mi branch local:

• Desactivar el menu de zsh (Para la autocompletacion, me acostumbre al completado como en bash) (Thanks netkrash)
• Completacion de hosts ssh|scp segun ~/.ssh/config en vez del known_hosts (Netkrash again)
• Completacion de usuarios con uid superior a 1000 (Comunmente usuarios reales), mostrar a root y ocultar a nobody.
• El atajo de oh my zsh de git diff (gd), se le pasa mate por un pipe, quite eso por que ya tengo un pager configurado.
• Trackear los ficheros de custom/
• Tema ‘idk’ para zsh (Para cambiar los temas de zsh basta con cambiar la variable ZSH_THEME en su ~/.zshrc), basado en macovsky y wezm (Incluidos en oh my zsh). Preview.

En fin, si les interesan los cambios, en este tar vienen todos los patches que he aplicado (Pueden crear un branch en .oh-my-zsh con git checkout -b mismods y luego aplican los parches con git am nombreparche.patch)

Me faltaron un poco de fuentes, Viget entregaba un par de tips, muy buenos.

En la parte del año que fue como las wifas (Como lo pronostique a fines del 2008) le lleva:

• Me despidieron, el único consuelo es que no fue mi culpa (La empresa murio en mala).
• Aún me estan alargando el pago de unas lucas (CTMS, mueranse)
• Par de temas personales que no vale la pena mencionar.
• Ah, y no pude regalarme nada fancy para navidad (Vease el fail del pago de lucas de más arriba)

Ahora, lo que si me salvo el año :

• Trabaje en lo que me gusta por 8 meses.
• Aprendí cosas re-entretenidas en la pega.
• Me lleve genial con un par de clientes (Gabriela y Jordana, tambien Felipe). Lastima que con otros no tanto …
• Conocí gente genial (Team DM, la gabi, el milton, la veny, el vicho, hasta javier; Ex-DM: el cesar ; y el equipo de egipcios, que lo nombro más abajo).
• Me llevo mejor con gente que antes consideraba solo conocidos
• Trabajé con un dream team para las jornadas (Al hilo tenemos a Rod, Boris, Pancho, lecaros, camila, javier y la revelación del año … pottersys xD)
• Mención honrosa para el Mozcamp y la gente de Mozilla (Sarah, you rocks)

Disculpen lo latero, la pesima redacción (Queda en el TODO de 2010) y los daños que les haya provocado el post y antes de olvidarlo: Feliz año!

Primero que nada, gracias a Cesar por la idea de usar git para backups  de ahi me vino toda esa git mania

Cuando se trata de sistemas de control de versiones, los primeros que se me vienen a la mente son git y subversion, por motivos de laziness prefiero el primero, por que lo conozco mejor y por que puedo hacer este setup con los ojos vendados (Not really )

Bueno, me ahorrare unas lineas diciendo que este setup:

• Usa llaves ssh para la autenticacion de usuarios
• Usa un repositorio git para manejar los repositorios de git (Got it?)
• Solo usa una cuenta de usuario para el manejo de git

Usaremos el proyecto Gitosis, desarrollado por Tommi Virtanen, como se imaginan el proyecto esta hosteado en git

Nos fuimos:

Paso 1: Instalar Gitosis

Instalamos git y setuptools de python:

apt-get install git-core python-setuptools

Ahora clonamos el codigo fuente de gitosis y lo instalamos:

cd /usr/src/
git clone git://eagain.net/gitosis.git
cd gitosis
python setup.py install

Paso 2: Crear el usuario para git

Creamos el usuario git (puede llamarse como ustedes quieran):

adduser \
    --system \
    --shell /bin/bash \
    --gecos 'Control de Versiones Git' \
    --group \
    --disabled-password \
    --home /home/git \
    git

Notar que tiene la contraseña deshabilitada, ya que no es necesaria; y tambien que le dimos una shell valida (Que si es necesaria para que ande gitosis).

Ahora para iniciar la instancia de gitosis, necesitaremos una llave pública RSA, si no tienen una pueden crearla con este comando:

ssh-keygen -t rsa -C janitux

Con nuestra llave lista, la copiamos al server que tendra gitosis, e iniciamos finalmente la creacion de la instancia gitosis:

su -c "/usr/bin/gitosis-init < /tmp/id_rsa.pub" git

Y este comando por si tenemos un bug en python-setuptools:

chmod 755 /home/git/repositories/gitosis-admin.git/hooks/post-update

Y comienza la fiesta, clonamos el repositorio de administracion de gitosis:

git clone git@SERVER:gitosis-admin.git

Y ya estamos listos para administrar nuestros repositorios con gitosis!

Paso 3: Crear Repositorios con gitosis

La administración de gitosis es muy sencilla, basta modificar el fichero gitosis.conf del directorio que clonamos en el paso anterior.
La sintaxis de este fichero se basa en directivas de grupos, se define el grupo, en que repositorios tendrán permisos de escritura o lectura; para más información sobre gitosis.conf ver el fichero example.conf

En fin, en este ejemplo crearemos el grupo “equipo”, con “pato” y “pedro” como miembros del grupo y este grupo tendrá permisos de escritura en los repositorios “mirepo” y “repob”. (Nota: el nombre de usuario se determina mediante los ficheros en el directorio keydir, es el nombre del fichero, sin la extensión .pub)

[group equipo]
writable = mirepo repob
members = pato pedro

Tambien tenemos que agregar las llaves publicas de pato y pedro:

cp id_rsa_pato.pub gitosis-admin/keydir/pato.pub
cp id_rsa_pedro.pub gitosis-admin/keydir/pedro.pub

Con esto estariamos listos para dar un commit y que se apliquen los cambios:

git add gitosis.conf keydir/
git commit -a -m "Creado grupo equipo, con pato y pedro como miembros, y permiso de escritura en los proyectos mirepo y repob"
git push

Y finally creamos el repositorio con el commit inicial:

mkdir -p ~/Git/mirepo
cd ~/Git/mirepo
git init
git remote add origin git@SERVER:mirepo.git
## Hacer trabajos, agregas ficheros con git add, y haces un commit con git commit -a
git push origin master:refs/heads/master

FINALLY! estamos listos para seguir trabajando con nuestros repositorios git

Mi única recomendación, sean claros con los nombres de sus mensajes en el commit.

Y obviamente, los creditos van a Garry Dolley, por este howto

La historia comienza cuando me dicen que el cliente XX tiene un problema con el correo, entonces reviso los logs del server y no veo nada extraño, enviaba correos, recibia correos, todo bien! (Revise bien al pedo, por que estaba un poco ocupado en las jornadas)
Lo que siguio, es que al volver a la vida (Aproximadamente el martes o miercoles, despues de las jornadas), me llama el cliente XX a la oficina, diciendome que ha estado como dos semanas con el problema, que desde su “coso” movil movistar podia enviar correos bien, pero que desde el enlace de <no puedo decir donde estaba> no podia enviar correos. En fin, luego de 5 minutos de tratarme como idiota, me harte y pedi hablar con el encargado del enlace (Mucho más razonable, y realmente entendía lo que yo hablaba ). Despues de hacer un par de pruebas, me fije que los logs decian XXXX hostname, en las sesiones de envio SMTP, y claro, ahí saltaba avenger alegando que tenía que hacer primero un EHLO o sino era spam. Hasta ahí no entendia nada, por que diablos desde una conexión si se enviaban bien los comandos SMTP, y no desde otra; tras googlear un rato, encontre al culpable!

Según vi, los firewalls cisco tienen una función llamada “fixup protocol”, que solo permite que pasen ciertos comandos SMTP, despues de deshabilitarlo, todo volvio a la normalidad

Aquí es cuando llega dpkg-repack a salvarme, hace exactamente lo que necesitaba.
La instalación es muy simple, lo instalan vía apt y luego lo corren como root, el único argumento que necesitan es el nombre del paquete.

Ejemplo: sudo dpkg-repack amsn

PD: Les conte que ahora estoy usando KDE 4.2?

Now Playing: Pork & Beans – Weezer