# sudo apt-get install subversion

Crear la ruta /var/svn:

# mkdir /var/svn

Instalar apache2 y libapache2-svn:

# sudo apt-get install apache2 libapache2-svn

Crear el fichero /etc/subversion/passwd y añadir el primer usuario:

# htpasswd -c /etc/subversion/passwd user_name

Para añadir el resto de usuarios:

# htpasswd -c /etc/subversion/passwd user_name

Editar /etc/apache2/mods-enabled:

<Location /svn>
  DAV svn
  SVNParentPath /var/svn
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/subversion/passwd
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
  </LimitExcept>
</Location>

Crear los repositorios de subversion:

# svnadmin create /var/svn/repo
# chown -R www-data /var/svn/repo

Reiniciar apache2:

# /etc/init.d/apache2 restart

Crear la estructura de directorios TTB (Trunk, Tags, Branches):

# svn mkdir http://localhost/svn/repo/trunk  -m "Creating trunk"
# svn mkdir http://localhost/svn/repo/tags  -m "Creating tags"
# svn mkdir http://localhost/svn/repo/branches  -m "Creating branches"

En primer lugar indicar que Git es un sistema distribuido, a diferencia de por ejemplo Subversion o CVS que son centralizados. Esto para nosotros qué quiere decir? Básicamente que no trabajamos con una copia local del código fuente sino con una copia local o clon del repositorio original, más conocido como “master”.
Las ventajas más importante de trabajar de esta forma, siempre bajo mi punto de vista, son que disponemos de todas las utilidades propias del VCS sin ni siquiera tener que estar conectado a una red. Muy útil para acceder al historico de modificaciones de un fichero, comparar versiones, hacer un commit o cualquier cosa que hagas normalmente con tu VCS desde un sitio donde no dispongas de conexión.

Git define también 5 tipos de objetos alguno de los cuales nos serán familiares si hemos trabajado con un VCS antes:

• Blob: El contenido de un fichero gestionado por Git e identificable por el Hash SHA1 que se obtiene del dicho contenido.
• Tree: La estructura del repositorio en un momento determinado (normalmente un commit). Un objeto de tipo Tree tiene N objetos de tipo Blob asociados.
• Commit: Una “foto” del repositorio una vez se han introducido una serie de cambios. Un objeto de tipo commit tiene 1 objeto de tipo Tree asociado.
• Tag: Una etiqueta, normalmente sirve para marcar objetos de tipo commit.
• Índice: Imagen de los cambios que se aplicarán al repositorio en el siguiente commit. En Git, por defecto sólo aplican aquellos cambios que se encuentran reflejados en este índice (están STAGED).

Git a diferencia que otros VCS como Subversion no almacena únicamente los cambios de un fichero sino que almacena el contenido completo de cada revisión. Esto sumado a la forma de trabajar que tiene con los objetos que indiqué antes hacen que en general el funcionamiento de Git sea muy ágil y, bajo mi punto de vista, mucho menos susceptible a error (piensa que cada vez que le pides una revisión en concreto, Git no debe “montarla” sólo “localizarla”).

Sólo por estas cosillas, ya comienzo a estar tentado de cambiar. ¿Habeis trabajado con Git o similar? ¿Qué os parece? ¿Cambiaríais vuestro Subversion/CVS?

Por cierto el libro que estoy leyendo es “Version Control with Git” de la editorial O’Reilly Media por si alguien quiere echarle una leída.