Mis notas favoritas sobre informática, siempre a mano..

Mostrando entradas con la etiqueta Subversion. Mostrar todas las entradas

2012-11-27

Team Foundation Service "GRATIS", sale a competir de manera dura, contra GitHub, BitBucket entre otros servicios del mismo tipo.

Ya está disponible. Se trata de Team Foundation Service, una nueva forma destinada a equipos que se destacan por la entrega rápida de software para planificar y administrar proyectos. Y es gratis para equipos de hasta 5 desarrolladores.

Desarrollar código es divertido, pero administrar un desarrollo puede resultar complicado. ¿Mantiene el control de versiones de su código? ¿Dónde realiza el seguimiento de problemas y nuevas prestaciones? ¿Cómo mantiene a su equipo en la misma página? Ahora puede utilizar Team Foundation Service para realizar todo esto con cero infraestructura adicional.

Basta de soportar servidores. Basta de instalar y configurar múltiples paquetes de software para tener soporte del proceso de desarrollo. Con Team Foundation Service obtiene una solución fácil de usar y administrar basada en la nube que maneja los elementos críticos de la administración del ciclo de vida de aplicaciones, tales como control de versiones, planificación ágil y builds automatizados. Ya se encuentra disponible para equipos de desarrollo en todo el mundo. Los beneficios de Team Foundation Service incluyen:

Comience con su cuenta de Team Foundation Service GRATUITA aquí

Accesible desde cualquier lugar, usando herramientas existentes y conocidas.

Comience rápido, sin infraestructura que administrar.

Todos los idiomas y plataformas son bienvenidos.

Planifique proyectos, colabore con su equipo y administre su código en línea desde cualquier lugar usando cualquier navegador web moderno. Funciona con todas las ediciones de Visual Studio 2012 (¡incluso Express!), así como también Eclipse y otras herramientas (usando nuestro cliente de línea de comando).

Pase de “inscribirse” a su primer proyecto en minutos y configure un build de Integración Continua (CI) en unos pocos pasos sencillos. Su código fuente y los elementos de trabajo se almacenan en la nube, por lo cual la configuración de servidores ya es parte del pasado.

Desde C# a Python, desde Windows a Android, puede usar una variedad de idiomas y dirigirlo a una variedad de plataformas. Nuestros servicios están diseñados para ayudarlo a focalizarse en lo que hace mejor: desarrollar excelentes aplicaciones.

2012-11-24

Guia Rapida para iniciarce con Git y trabajar con GitHub

Notas:

Cambios locales se refiere a los ficheros del directorio de trabajo (working dir) que hayan sido modificados desde el último commit.
COMMIT es un indicador cualquiera en el repositorio: SHA1 de un commit, tag, HEAD (ultimo commit de la rama actual), HEAD~1 (antecesor de HEAD)… La mayoría de las veces, si no se indica se asume HEAD (último commit de la rama actual).

Enlaces:

Inicializar repositorio

$ git init
$ git add .
$ git commit -m "Estado inicial"

Crear ramas

# Crear la rama en el punto actual. Es necesario hacer checkout a la misma.

$ git branch <nombre>

# Crea la rama a partir del commit dado. Es necesario hacer checkout.               
$ git branch <nombre> <COMMIT>

# Crear rama en el punto actual y hacerle checkout.

$ git checkout -b <nombre>

# Crear la rama a partir del commit dado y hacerle checkout.  
$ git checkout -b <nombre> <COMMIT>

# Renombrar la rama.

$ git branch -m <actual> <nuevo>

Al crear una rama nueva y hacerle checkout los cambios locales se trasladan a esa rama, con lo que el siguiente commit será sobre la rama nueva.

Moverse a una rama o a un commit específico

$ git checkout <COMMIT>      # No toca los cambios locales
$ git checkout -f <COMMIT>   # Sobreescribe los cambios locales

Se puede hacer una rama desde el commit actual para continuar el desarrollo (git branch). Si se hacen cambios en un commit intermedio (no es un HEAD) y se commitean sin hacer una rama, se crea un commit separado que sale del actual (rama sin nombre).

Fusionar ramas (merge)

$ git merge <nombre>               # Fusiona la rama indicada en la rama actual

Las diferencias se resuelven automáticamente si es posible. En caso de conflictos (código o ficheros binarios modificados en ambas ramas) el proceso se detiene (merging) a la espera de una resolución manual.
Resolver conflictos de fusionado:
Dentro de cada fichero en conflicto se añaden marcas alrededor del código conflictivo, mostrando al mismo tiempo la versión de una y otra rama (excepto en ficheros binarios).

$ git status      # Muestra la situación actual del merge (Unmerged paths)
$ git diff        # Muestra los ficheros conflictivos y las diferencias
$ git add <file>  # Marca el fichero como corregido una vez resuelto el conflicto
$ git rm <file>   # Marca el fichero como eliminado en la revisión resuelta

La sección “Unmerged paths” de git status muestra los ficheros que requieren atención. Debe resolverse cada conflicto manualmente dentro del fichero (eliminando las marcas agregadas por git) y marcarlo como resuelto con git add.
En vez de editar los ficheros es posible escoger una de las dos versiones disponibles (rama actual o rama que se está fusionando):

# Obtener la versión del fichero en la rama actual

$ git checkout --ours -- <file>

# Obtener la versión del fichero en la rama que se está fusionando con la actual

$ git checkout --theirs -- <file>

Para abortar la acción o anularla una vez realizada:

# Abortar el proceso y volver a la situación anterior al intento de merge

$ git reset --hard HEAD

# Deshacer si ya se había confirmado con git commit$ git reset --hard ORIG_HEAD

Una vez resueltos todos los conflictos se confirma el proceso:

# Confirmar la fusión (merge) una vez resueltos todos los conflictos

$ git commit

Resolución gráfica de conflictos:

# Inicia la herramienta gráfica de resolución de conflictos

$ git mergetool

La herramienta crea ficheros adicionales por cada fichero en conflicto (backup, base, local, remote) para que la herramienta de resolución pueda mostrarlos al usuario al mismo tiempo y éste establecer la versión final. Estos ficheros deberían borrarse automáticamente tras la edición (en caso de que persistan es necesario borrarlos manualmente).
La resolución básica sólo sirve para ficheros de texto. En ficheros binarios usar git checkout –ours o git checkout –theirs para escoger una de las dos versiones disponibles.
Configurar una herramienta gráfica para resolver conflictos: http://www.davesquared.net/2010/03/easier-way-to-set-up-diff-and-merge.html (Windows) http://gitguru.com/2009/02/22/integrating-git-with-a-visual-merge-tool (Mac)

Deshacer cambios

# La recuperación hace un nuevo commit en la rama actual sin ir "hacia atrás" en la historia

$ git revert <COMMIT>              
$ git reset --hard                 # Deshace los cambios locales
$ git reset --hard HEAD~1          # Elimina el último commit

Recuperar una versión determinada de un fichero o path:

$ git reset <COMMIT> -- <path>     # git reset NO sobreescribe cambios locales
$ git reset -p <COMMIT> -- <path>  # Seleccionar interactivamente las partes a restaurar
$ git checkout <COMMIT> -- <path>  # Sobreescribe cambios locales sin preguntar

En Windows se puede abrir git-bash directamente en cualquier subcarpeta carpeta del proyecto (boton derecho – git bash here). Entonces para recuperar un fichero o path local:

$ git checkout <COMMIT> -- ./<path>

Conocer el historial de un fichero

# Mostrar todos los commits para un fichero especifico con info detallada

$ git log <path>

# Mostrar sólo los dos últimos commits para ese fichero

$ git log -n 2 -- <path>

# Formato abreviado con id de commit y comentario

$ git log -oneline -- <path>

# Mostrar los commits para ese fichero entre dos commits indicados

$ git log <SINCE>..<UNTIL> -- <path>

Abrir GITK mostrando gráficamente el historial para un fichero o ruta dado:

$ gitk <path>

Guardar cambios actuales para recuperarlos después

Guarda los cambios desde el último commit. Al recuperarlos, si hay colisiones se hace un merge.

$ git stash        # Guarda cambios hechos desde el ultimo commit
$ git stash pop    # Recupera los cambios guardados
$ git stash list   # Lista los estados guardados
$ git stash apply  # Aplica cambios guardados sin borrarlos de la lista

Marcar el commit actual (Tag)

$ git tag -s <nombre> -m <mensaje>

El tag queda firmado usando la firma GPG asociada al autor (ver Creating SSH keys).
El nombre identifica al tag y se usa en los demás comandos (ej. git checkout). Por ejemplo, v2.32.45r1

$ git tag                              # Mostrar lista de tags
$ git tag -n                           # Mostrar lista y descripción

$ git tag -d <nombre>                  # Eliminar Tag
$ git tag -a <nombre>                  # Crear Tag no firmado
$ git push --tags                      # Subir Tags al repositorio remoto
$ git push origin :refs/tags/<nombre>  # Eliminar Tag borrado localmente

Localizar ficheros con una cadena de texto

$ git grep <texto>            # Mira en todos los ficheros del repositorio
$ git grep <texto> -- <ruta>  # Mira sólo en la ruta o rutas especificadas
                              # Admite patrones (ej. *.cpp)

Trabajo con repositorios remotos

Obtener el repositorio desde otra localización (fork):

# Clonar y hacer checkout del HEAD de la rama actual

$ git clone <ruta al repositorio>

# Clonar pero no hacer checkout

$ git clone -n <ruta al repositorio

No hay que hacer git init ni crear directorio (se crea automáticamente a partir de la carpeta actual). La ruta puede ser una carpeta local, carpeta en red, URL, o cualquier otra referencia a un repositorio remoto. Si es privado será necesario tener la clave SSH configurada adecuadamente (ejemplo).

Recibir los cambios desde el repositorio original:

$ git pull

Es equivalente a:

$ git fetch                 # Trae los cambios
$ git merge origin          # Fusionarlos con la versión actual

Subir cambios al repositorio:

$ git push origin <branch>  # Subir sólo la rama indicada
$ git push --all            # Subir y actualizar todas las referencias remotas

Gestionar Tags en el repositorio:

$ git push --tags                      # Subir Tags (no suben de otra forma)
$ git push origin :refs/tags/<nombre>  # Eliminar Tag borrado localmente

Borrar una rama remota:

$ git push origin :<branch>
$ git push origin --delete <branch>    # GIT versión 1.7.0+

Listar los repositorios remotos y sus URLs:

$ git remote -v show

Cambiar la URL de un repositorio remoto (cambia ambos fetch y push)

$ git remote set-url origin <nueva URL>

Revertir un commit en local y también en el repositorio remoto:

(lo lógico es que no hubiera sido subido)

$ git reset --hard HEAD~1
$ git push origin +master:master

“The +master:master thing is necessary to tell git that you really do want to rewind the history here, (it’s definitely not part of the normal flow).”
Tutorial
Push and delete branches

Tareas especiales

Añadir un nuevo fichero o patrón a .gitignore

Añadirlo a .gitignore sigue controlando aquellos ficheros que ya están en el repositorio, y

git rm <file>

eliminaría el fichero del directorio de trabajo.
Para dejar de controlar el fichero o patrón manteniendo las copias actuales añadirlo a .gitignore y entonces:

$ git rm --cached <file>
$ git rm --cached -r <pattern>        # Eliminar ocurrencias en todo el arbol

Borrar el fichero completamente del repositorio implica reescribir toda la historia. Nada recomendable.

Localizar el cambio que originó un problema:

$ git bisect start
$ git bisect bad                      # La versión actual va mal
$ git bisect good v2.6.13-rc2         # Esta versión es buena

Autor Link

2010-03-13

VisualSVN Server es la manera simple de instalar Subversion

“Sencillo servidor SVN para Windows”

Subversion es un sistema de control de versiones muy utilizado para el mantenimiento de código fuente, documentación técnica y páginas web.

VisualSVN Server es paquete de instalación que incluye Subversion y el servidor web Apache ya configurados y listos para funcionar desde el primer momento. La instalación es muy rápida, sin complicaciones.

VisualSVN Server se carga como un servicio más. Su panel de control utiliza el aspecto familiar de las consolas de Windows, con un resumen de los repositorios activos y la dirección del servidor.

Los repositorios se pueden crear o importar desde el mismo panel de VisualSVN Server. En las propiedades de cada elemento hay una pestaña para cambiar los permisos de seguridad. Si quieres más control, un botón da acceso al intérprete de comandos SVN.

Nota sobre VisualSVN Server:

Incluye Subversion 1.6.2 y Apache 2.2.9
El puerto del servidor SVN es el 8443

Para utilizar VisualSVN Server necesitas:

Sistema operativo: Win2000/XP/2003/Vista

Link: Sitio de VisualSVN Server

bitnami.org - Los proyectos web mas populares enpaquetados para instalar

BitNami.org es un sitio donde encontrar los proyecto mas populares para alojar en un servidor web, empaquetado y listos para instalar de manera muy simple.

Utiliza tu aplicación web, favorita como... Alfresco, Joomla!, Drupal, Redmine, Mediawiki, Trac, Wordpress, Roller, DokuWiki, Subversion, SugarCRM... sobre tu sistema operativo favorito como Windows, Linux, Mac, Solaris.. Y lo mejor de todo, que es gratis....!!!

Todo de manera muy simple, muy recomendado para los desarrolladores que quieren crear un entorno de desarrollo de manera rápida.

Link: BitNami.org

2010-01-27

Configurar Apache con Subversion

Servidor basado en Apache
	Capítulo 3. El repositorio

Servidor basado en Apache

Introducción

La configuración más flexible de todas las instalaciones de servidor posibles para Subversion es la que se basa en Apache. Aunque es un poco más complicada de preparar, ofrece beneficios que otros servidores no pueden dar:

WebDAV: El servidor de Subversion basado en Apache utiliza el protocolo WebDAV que se utiliza por muchos otros programas. Por ejemplo, podría montar dicho repositorio como una “Carpeta web” en el explorador de Windows y luego acceder a ella como cualquier otra carpeta en su sistema de ficheros.
Navegando por el repositorio: Puede apuntar su navegador a la URL del repositorio y navegar por sus contenidos sin tener un cliente de Subversion. Esto da acceso a sus datos a un mayor círculo de usuarios.
Autentificación: Puede utilizar cualquier mecanismo de autentificación que Apache soporte, incluyendo SSPI y LDAP.
Seguridad: Dado que Apache es muy estable y seguro, automáticamente obtendrá la misma seguridad para su repositorio. Esto incluye la encriptación SSL.

Instalando Apache

La primera cosa que necesita antes de instalar Apache es un ordenador con Windows 2000, Windows XP con SP1, Windows 2003, Vista o Server 2008.

Aviso

Por favor tenga en cuenta que utilizar Windows XP sin el Service Pack 1 corrompe datos de la red y por tanto ¡podría corromper su repositorio!

Descargue la última versión del servidor web Apache desde http://httpd.apache.org/download.cgi. Asegúrese de que descarga la versión 2.2.x - ¡las versiones 1.3.xx no servirán!
El instalador MSI de Apache se puede encontrar haciendo click en other files (otros ficheros), y luego navegando a binaries/win32. Puede que quiera seleccionar el fichero MSI apache-2.2.x-win32-x86-openssl-0.9.x.msi (el que incluye OpenSSL).
Una vez que tenga el instalador de Apache2 puede hacer doble click en él y le guiará a través del proceso de instalación. Asegúrese de que ha introducido la URL del servidor correctamente (si no tiene un nombre DNS para su servidor introduzca la dirección IP). Es recomendable que instale Apache para Todos los usuarios, en el Puerto 80, como un Servicio. Nota: si ya tiene IIS u otro programa ejecutándose que escuche en el puerto 80 la instalación puede fallar. Si esto ocurre, vaya al directorio de Archivos de programa, \Apache Group\Apache2\conf y localice el fichero httpd.conf. Edite dicho fichero para cambiar Listen 80 por un puerto libre, por ejemplo, Listen 81. Luego reinicie la instalación - esta vez debería terminar sin problemas.
Ahora compruebe si el servidor web Apache funciona correctamente apuntando desde su navegador web a la dirección http://localhost/ - debería aparecer un sitio web preconfigurado.

Atención

Si decide instalar Apache como un servicio, queda avisado de que por defecto se ejecutará con la cuenta de sistema local. Sería una práctica más segura que creara una cuenta separada para que Apache se ejecutara bajo ella.

Asegúrese de que la cuenta en el servidor bajo la que se ejecuta Apache tenga una entrada explícita en la lista de control de acceso del directorio del repositorio (click con el botón derecho en el directorio | propiedades | seguridad), con control total. Si no lo hace así, los usuarios no podrán confirmar sus cambios.

Incluso si Apache se ejecuta como sistema local, aún así necesitará dicha entrada (que en este caso debería ser la cuenta SYSTEM).

Si Apache no tiene este permiso configurado, sus usuarios tendrán mensajes de error “Acceso denegado”, que se mostrarán en el registro de errores de Apache como error 500.

Instalando Subversion

Descarge la última versión de los binarios de Subversion para Apache y Windows 32. Asegúrese de obtener la versión correcta para integrarla en su versión de Apache, porque si no obtendrá un oscuro mensaje de error cuando intente reiniciar. Si tiene Apache 2.2.x acuda a http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100.
Ejecute el instalador de Subversion y siga las instrucciones. Si el instalador de Subversion reconoce que ha instalado Apache, habrá casi terminado. Si no puede encontrar un servidor de Apache entonces tendrá que realizar algunos pasos adicionales.
Utilizando el explorador de Windows, vaya al directorio de instalación de Subversion (normalmente C:\Archivos de programa\Subversion) y busque los ficheros /httpd/mod_dav_svn.so y mod_authz_svn.so. Copie estos ficheros al directorio de módulos de Apache (normalmente C:\Archivos de programa\Apache Group\Apache2\modules).
Copie el fichero /bin/libdb*.dll y /bin/intl3_svn.dll desde el directorio de instalación de Subversion al directorio bin de Apache.
Edite el fichero de configuración de Apache (normalmente C:\Archivos de Programa\Apache Group\Apache2\conf\httpd.conf) con un editor de texto como el Bloc de Notas y haga los siguientes cambios:
Descomente (quitando la marca '#') las siguientes líneas:
```
#LoadModule dav_fs_module modules/mod_dav_fs.so
#LoadModule dav_module modules/mod_dav.so
```
Añada las dos líneas siguientes al final de la sección LoadModule.
```
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
```

Configuración

Ahora ya ha preparado Apache y Subversion, pero Apache aún no sabe cómo manejar los clientes de Subversion como TortoiseSVN. Para que Apache sepa qué URL debe utilizarse para los repositorios de Subversion debe editar el fichero de configuración de Apache (normalmente está en C:\Archivos de programa\Apache Group\Apache2\conf\httpd.conf) con cualquier editor de texto que desee (por ejemplo, el Bloc de notas):

Al final del fichero de configuración, añada las siguientes líneas:
```
 DAV svn
 SVNListParentPath on
 SVNParentPath D:\SVN
 #SVNIndexXSLT "/svnindex.xsl"
 AuthType Basic
 AuthName "Repositorios de Subversion"
 AuthUserFile passwd
 #AuthzSVNAccessFile svnaccessfile
 Require valid-user
```
Esto configura el Apache de forma que todos sus repositorios de Subversion están físicamente localizados bajo D:\SVN. Los respositorios se sirven al mundo exterior desde la URL: http://MiServidor/svn/ . El acceso está restringido a los usuarios/contraseñas listados en el fichero passwd
Para crear el fichero passwd, abra el Símbolo del sistema o la línea de comandos (ventana DOS) de nuevo, cambie a la carpeta Apache2 (normalmente C:\Archivos de programa\Apache Group\Apache2) y cree el fichero mediante
```
bin\htpasswd -c passwd 
```
Esto creará un nuevo fichero con el nombre passwd que se utilizará para la autentificación. Se pueden crear usuarios adicionales con
```
bin\htpasswd passwd 
```
Reinice el servicio de Apache de nuevo.
Apunte su navegador a http://MiServidor/svn/MiNuevoRepositorio (donde MiNuevoRepositorio es el nombre del repositorio de Subversion que creó antes). Si todo ha ido bien debería ver una ventana preguntando por un usuario y una contraseña, y luego podrá ver los contenidos de su repositorio.

Una explicación breve sobre lo que acaba de introducir:

Tabla 3.1. Configuración de httpd.conf de Apache

Configuración	Explicación
	significa que los repositorios de Subversion están disponibles en la URL `http://MiServidor/svn/`
DAV svn	le dice a Apache qué módulo será responsable de servir esa URL - en este caso, el módulo de Subversion.
SVNListParentPath on	Para Subversion 1.3 y superiores, esta directiva habilita el listado de todos los repositorios disponibles bajo `SVNParentPath`.
SVNParentPath D:\SVN	le dice a Subversion que busque repositorios bajo `D:\SVN`
SVNIndexXSLT "/svnindex.xsl"	Utilizado para mejorar la visualización desde un navegador de web.
AuthType Basic	se utiliza para activar la autentificación básica, es decir, Usuario/contraseña
AuthName "Subversion repositories"	se utiliza cuando le aparezca un diálogo de autentificación al usuario como información para decirle para qué se necesita su autentificación
AuthUserFile passwd	especifica qué fichero de contraseñas se utiliza para la autentificación
AuthzSVNAccessFile	lugar del fichero de Acceso para las rutas dentro del repositorio de Subversion
Require valid-user	especifica que sólo los usuarios que hayan introducido un par usuario/contraseña válido podrán acceder a la URL

Pero eso es sólo un ejemplo. Hay muchas, muchas más posibilidades de lo que puede hacer con el servidor web Apache.

Si desea que su repositorio tenga acceso de lectura para todo el mundo pero el acceso de escritura sólo para usuarios específicos, puede cambiar la línea
```
Require valid-user
```
por
```
Require valid-user
```
Utilizando un fichero passwd se limita y se otorga acceso a todos sus repositorios como si fueran uno solo. Si desea más control sobre qué usuarios tienen acceso a cada carpeta dentro de un repositorio, puede descomentar la línea
```
#AuthzSVNAccessFile svnaccessfile
```
y crear un fichero de acceso de Subversion. Apache se asegurará que sólo los usuarios válidos pueden acceder su ruta /svn, y luego pasará el nombre de usuario al módulo de Subversion AuthzSVNAccessFile para que pueda forzar un acceso más controlado basado en las reglas que se especifican en el fichero de acceso de Subversion. Tenga en cuenta que las rutas se especifican o bien como repos:ruta o simplemente ruta. Si no especifica un repositorio en concreto, la regla de acceso se aplicará a todos los repositorios bajo SVNParentPath. El formato del fichero de política de autorización utilizado por mod_authz_svn se describe en “Autorización basada en rutas”
Para hacer que la visualización del repositorio con un navegador web sea 'más bonita', descomente la línea
```
#SVNIndexXSLT "/svnindex.xsl"
```
y ponga los ficheros svnindex.xsl, svnindex.css y menucheckout.ico en su directorio raíz de documentos (normalmente C:/Archivos de programa/Apache Group/Apache2/htdocs). El directorio está establecido con la directiva DocumentRoot en su fichero de configuración de Apache.
Puede obtener estos tres ficheros directamente desde nuestro repositorio de código fuente en http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/contrib/other/svnindex. (“¡TortoiseSVN es gratis!” le explica cómo acceder al repositorio de código de TortoiseSVN).
El fichero XSL del repositorio de TortoiseSVN tiene una característica destacada: si navega el repositorio con su navegador web, todas las carpetas de su repositorio mostrarán un icono a la derecha. Si pulsa sobre dicho icono, se iniciará el diálogo de obtener de TortoiseSVN para esa URL.

Múltiples repositorios

Si ha utilizado la directiva SVNParentPath no necesita cambiar el fichero de configuración de Apache cada vez que añada un nuevo repositorio de Subversion. Simplemente cree el nuevo repositorio bajo la misma ruta que el primer repositorio, ¡y ya está! En mi compañía, tengo acceso directo a esa carpeta en concreto utilizando SMB (el acceso normal de ficheros de Windows). Por lo que simplemente creo una nueva carpeta allí, ejecuto el comando de TortoiseSVN TortoiseSVN → Crear repositorio aquí... y ya hay un nuevo proyecto que tiene su hogar...

Si está utilizando Subversion 1.3 o posterior, puede utilizar la directiva SVNListParentPath on para permitir que Apache produzca un listado de todos los proyectos disponibles si apunta su navegador a la ruta raíz en vez de a un repositorio en concreto.

Autorización basada en rutas

El módulo mod_authz_svn le permite un control detallado de los permisos de acceso basado en nombres de usuarios y rutas de repositorio. Esto está disponible si utiliza el servidor de Apache, y desde Subversion 1.3 también está disponible si utiliza svnserve.

Esto sería un fichero de ejemplo:

[groups]
admin = john, kate
devteam1 = john, rachel, sally
devteam2 = kate, peter, mark
docs = bob, jane, miguel
training = zak
# Regla de acceso por defecto para TODOS los repositorios
# Todo el mundo puede leer, los administradores pueden escribir,
# Donpe Ligro está exluído.
[/]
* = r
@admin = rw
donpeligro =
# Permitir a los desarrolladores acceso completo
# al repositorio de su proyecto
[proj1:/]
@devteam1 = rw
[proj2:/]
@devteam2 = rw
[bigproj:/]
@devteam1 = rw
@devteam2 = rw
trevor = rw
# Dar a los documentadores acceso de escritura
# a todas las carpetas de documentación
[/trunk/doc]
@docs = rw
# Dar a los becarios acceso de escritura
# sólo al repositorio de pruebas
[TrainingRepos:/]
@training = rw

Tenga en cuenta que comprobar cada ruta puede ser una operación costosa, particularmente en el caso del registro de revisiones. El servidor toma cada ruta cambiada en cada revisión y comprueba si se puede leer, lo que puede ser lento en revisiones que afecten a un gran número de ficheros.

La autentificación y la autorización son procesos separados. Si un usuario desea tener acceso a una ruta de un repositorio, tiene que cumplir ambos requisitos, los requerimientos usuales de autentificación y los requerimientos de autorización del fichero de acceso.

Autentificación con un dominio de Windows

Como habrá notado necesita introducir una entrada usuario/contraseña en el fichero passwd para cada usuario de forma separada. Y si (por razones de seguridad) quiere que sus usuarios cambien periódicamente sus contraseñas tendrá que hacer el cambio de forma manual.

Pero hay una solución a este problema - al menos si accede al repositorio desde dentro de una LAN con un controlador de dominio de Windows: mod_auth_sspi!

El módulo original de SSPI fue ofrecido por Syneapps incluyendo el código fuente. Pero su desarrollo se detuvo. No se desespere, la comunidad lo ha retomado y mejorado. Tiene un nuevo hogar en SourceForge.

Descargue el módulo que concuerde con su versión de Apache, y copie el fichero mod_auth_sspi.so en la carpeta de módulos de Apache.
Edite el fichero de configuración de Apache: añada la línea
```
LoadModule sspi_auth_module modules/mod_auth_sspi.so
```
a la sección LoadModule. Asegúrese de insertar esta línea antes de la línea
```
LoadModule auth_module modules/mod_auth.so
```
Para que el localizador de Subversion utilice este tipo de autentificación tiene que cambiar la línea
```
AuthType Basic
```
por
```
AuthType SSPI
```
y también deberá añadir
```
SSPIAuth On
SSPIAuthoritative On
SSPIDomain 
SSPIOmitDomain on
SSPIUsernameCase lower
SSPIPerRequestAuth on
SSPIOfferBasic On
```
dentro del bloque Si no tiene un controlador de dominio, deje el nombre del controlador de cominio como

Tenga en cuenta que si se autentifica utilizando SSPI, ya no necesitará la línea AuthUserFile para definir un fichero de contraseñas. En su lugar, Apache autentifica su usuario y contraseña contra su dominio de Windows. También necesitará actualizar la lista de usuarios en su svnaccessfile para referirse a DOMINIO\usuario.

Importante

La autenticación SSPI sólo está habilitada para conexiones seguras por SSL (https). Si únicamente está utilizando conexiones http normales a su servidor, no funcionará.

Para habilitar SSL en su servidor, vea el capítulo: “Asegurando el servidor con SSL”

Sugerencia

Los ficheros AuthzSVNAccessFile de Subversion distinguen mayúsculas y minúsculas respecto a los nombres de usuario (JuanPerez no es lo mismo que juanperez).

En el mundo de Microsoft, los dominios y nombres de usuarios de Windows no distinguen mayúsculas y minúsculas. Incluso así, a algunos administradores de redes les gusta crear las cuentas de usuario en CamelCase (por ejemplo, JuanPerez).

La diferencia puede morderle cuando utilice la autentificación SSPI ya que el dominio de Windows y los nombres de usuario se pasan a Subversion exactamente como los haya tecleado el usuario en la ventana. Internet Explorer a menudo pasa el nombre de usuario a Apache automáticamente utilizando el formato con el que se creó la cuenta.

El resultado final es que puede necesitar al menos dos entradas en su fichero AuthzSVNAccessFile para cada usuario -- una entrada en minúsculas y una entrada con el formato que Internet Explorer pasa a Apache. También tendrá que convencer a sus usuarios para que escriban sus credenciales en minúsculas cuando accedan a los repositorios utilizando TortoiseSVN.

Los registros de error y de acceso de Apache son su mejor aliado para descifrar problemas como estos, ya que le ayudarán a determinar la cadena de nombre de usuario pasada al módulo AuthzSVNAccessFile de Subversion. Puede que necesite experimentar con el formato exacto de la cadena del usuario en el svnaccessfile (por ejemplo, DOMINIO\usuario en vez de DOMINIO//usuario) para conseguir que todo funcione.

Múltiples orígenes de autentificación

También es posible tener más de un origen de autentificación para su repositorio de Subversion. Para conseguirlo, debe hacer que cada tipo de autentificación sea no-autoritario, para que Apache compruebe múltiples orígenes buscando un par usuario/contraseña que concuerden.

Un escenario común es utilizar tanto la autentificación de dominio de Windows como un fichero passwd, para que pueda dar acceso a SVN a usuarios que no tienen usuario en el dominio de Windows.

Para habilitar tanto la autentificación de dominio de Windows como el fichero passwd, añada las siguientes entradas en el bloque de su fichero de configuración de Apache:
```
AuthBasicAthoritative Off
SSPIAuthoritative Off
```

Aquí tiene un ejemplo de la configuración completa de Apache para combinar la autentificación de dominio de Windows y el fichero passwd:


 DAV svn
 SVNListParentPath on
 SVNParentPath D:\SVN

 AuthName "Repositorios de Subversion"
 AuthzSVNAccessFile svnaccessfile.txt

# Usuarios de Dominio NT.
 AuthType SSPI
 SSPIAuth On
 SSPIAuthoritative Off
 SSPIDomain 
 SSPIOfferBasic On

# Usuarios htpasswd.
 AuthType Basic
 AuthBasicAuthoritative Off
 AuthUserFile passwd

 Require valid-user

Asegurando el servidor con SSL

Incluso aunque Apache 2.2.x tiene soporte para OpenSSL, no está activado por defecto. Necesitará activarlo manualmente.

En el fichero de configuración de Apache, descomente las líneas:

#LoadModule ssl_module modules/mod_ssl.so

y al final

#Include conf/extra/httpd-ssl.conf

y luego cambie la línea (en una única línea)

SSLMutex "file:C:/Archivos de programa/Apache Software Foundation/\
Apache2.2/logs/ssl_mutex"

SSLMutex default

Lo siguiente que necesita es crear un certificado SSL. Para hacer esto, abra un símbolo del sistema (ventana DOS) y vaya a la carpeta de Apache (por ejemplo, C:\Archivos de programa\Apache Group\Apache2) y escriba el siguiente comando:
```
bin\openssl req -config conf\openssl.cnf -new -out my-server.csr
```
Se le preguntará una contraseña. Por favor no utilice palabras sencillas, sino frases completas, por ejemplo, unos versos de un poema. Cuanto más larga sea la frase, mejor. También tendrá que introducir la URL de su servidor. Todas las demás preguntas son opcionales pero le recomendamos que las rellene también.
Normalmente el fichero privkey.pem se crea automáticamente, pero si no es así, necesitará teclear este comando para generarlo:
```
bin\openssl genrsa -out privkey.pem 2048
```
Ahora escriba los comandos
```
bin\openssl rsa -in conf\privkey.pem -out conf\server.key
```
y (en una única línea)
```
bin\openssl req -new -key conf\server.key -out conf\server.csr \
-config conf\openssl.cnf
```
y luego (en una única línea)
```
bin\openssl x509 -in conf\server.csr -out conf\server.crt
                -req -signkey conf\server.key -days 4000
```
Esto creará un certificado que expirará en 4000 días. Y finalmente, introduzca (también en una única línea):
```
bin\openssl x509 -in conf\server.cert -out conf\server.der.crt
                -outform DER
```
Estos comandos crearán algunos ficheros en la carpeta conf de Apache (server.der.crt, server.csr, server.key, .rnd, privkey.pem, server.cert).
Reinicie el servicio de Apache.
Apunte su navegador a https://nombredelservidor/svn/project ...

SSL e Internet Explorer

Si está asegurando su servidor con SSL y utiliza la autentificación contra un dominio de Windows se encontrará que la navegación de repositorios con el Internet Explorer ya no funcionará. No se preocupe - es sólo que Internet Explorer no se puede autentificar. Los demás navegadores no tienen ese problema y tanto TortoiseSVN como cualquier otro cliente de Subversion todavía podrán autentificarse.

Si todavía quiere utilizar IE para navegar en el repositorio, puede:

Defina una directiva separada en el fichero de configuración de Apache, y añada SSPIBasicPreferred On. Esto permitirá que IE se autentifique de nuevo, pero los demás navegadores y Subversion no se podrán autentificar contra esa ruta.
Ofrezca también la navegación sin autentificación encriptada (sin SSL). Extrañamente, IE no tiene ningún problema para autentificarse si la conexión no está asegurada con SSL.
En la configuración "estándar" a menudo aparecen la siguiente sentencia en el host virtual SSL de Apache:
```
SetEnvIf User-Agent ".*MSIE.*" \
            nokeepalive ssl-unclean-shutdown \
            downgrade-1.0 force-response-1.0
```
Hay (¿había?) buenas razones para esta configuración, lea http://www.modssl.org/docs/2.8/ssl_faq.html#ToC49 Pero si desea usar autentificación NTLM deberá utilizar keepalive. Si descomenta toda la sentencia "SetEnvIf" debería ser capaz de autentificar IE con la autentificación de Windows sobre SSL contra un Apache sobre Win32 con el módulo incluído mod_auth_sspi.

Forzando el acceso SSL

Cuando haya preparado SSL para hacer su repositorio más seguro, puede que desee deshabilitar el acceso normal via no-SSL (http) y sólo permitir el acceso https. Para hacer esto, debería añadir otra directiva al bloque de Subversion: SSLRequireSSL.

Un bloque de ejemplo se parecería a éste:


 DAV svn
 SVNParentPath D:\SVN
 SSLRequireSSL
 AuthType Basic
 AuthName "Repositorios de Subversion"
 AuthUserFile passwd
 #AuthzSVNAccessFile svnaccessfile
 Require valid-user

Utilizando certificados de cliente con hosts SSL virtuales

Enviado a la lista de correo de TortoiseSVN por Nigel Green. ¡Gracias!

En algunas configuraciones de servidor puede que necesite configurar un único servidor que contenga 2 hosts SSL virtuales: el primero para acceso web público, sin requerimientos de un certificado de cliente; el segundo, seguro requiriendo un certificado de cliente, y ejecutando un servidor Subversion.

Al añadir una directiva SSLVerifyClient Optional en la sección por-servidor de la configuración de Apache (es decir, fuera de cualquier bloque VirtualHost y Directory), se fuerza a Apache a pedir un certificado de cliente en el saludo inicial SSL. Debido a un bug en mod_ssl, es esencial que el certificado se pida en este punto, ya que no funciona si la conexión SSL se re-negocia.

La solución es añadir la siguiente directiva en el directorio del host virtual que quiere bloquear para Subversion:

SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"

Esta directiva da acceso al directorio sólo si se recibió y verificó correctamente un certificado de cliente.

Para resumir, las líneas relevantes de la configuración de Apache son:

SSLVerifyClient Optional

### Configuración del virtual host para el host PÚBLICO
### (sin necesidad de un certificado de cliente)


 
 


### Configuración del virtual host para SUBVERSION
### (necesita un certificado de cliente)

 
   SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"
 

 
   DAV svn
   SVNParentPath /rutaalrepositorio