Mostrando entradas con la etiqueta subversion. Mostrar todas las entradas
Mostrando entradas con la etiqueta subversion. Mostrar todas las entradas

viernes, 17 de junio de 2011

guia rapida para subversion


obtenido de  aqui


Guía Rápida para subversion

Este breve documento es una guía para manejar subversion tomando como base los conocimientos aprendidos usando cvs.
  1. Introducción
  2. Manejo básico de Subversion
  3. Conflictos, diferencias e historial

Introducción

Conceptos interesantes en subversion

A primera vista subversion parece una implementación mejor realizada que su antecesor cvs en ciertos detalles que dan mayor juego y son más comodos de realizar.
  • El Repositorio: un detalle importante es que el repositorio en el servidor no son archivos en formato rcs, es un Berkeley DB por lo que la administración del repositorio se ha de realizar mediante herramientas proporcionadas por subversion.
  • Sistemas de Acceso: el desarrollo de subversion tiene un marcado efecto de Apache 2, ya que incluye la posibilidad mediante un módulo DAV de trabajar con el repositorio mediante el protocolo HTTP y utilizando un sistema de autentificación similar al utilizado en Apache. También se puede acceder mediante el programa svnserve como ocurría con cvspserver. Resumiendo tenemos los siguientes métodos de acceso:
    • file:// acceso al sistema local.
    • http:// y https:// haciendo uso del módulo de DAV en Apache 2.
    • svn:// por svnserve y svn+ssh:// para utilizar ssh.
  • Mejor trabajar desconectado: los módulos sobre los que trabajan los desarrolladores están pensados para necesitar lo menos posible la conexión con el repositorio general. Podemos hacer diff de versiones anteriores, añadir archivos y directorios, comprobar logs... todo sin tener que estar conectados con el servidor.
  • Soporte para binarios: otra de las ventajas de subversion es la posibilidad de manejar binarios en nuestro repositorio opción poco recomendable concvs.
  • Facilidad para añadir/eliminar/mover ficheros y directorios: con cvs la creación de directorios y ficheros y sobretodo su eliminación son tremendamente cansinos. Con subversion podemos hacer uso de comandos tales como svn rm directorio.
  • Branches y Tags más sencillossubversion maneja el repositorio de forma absoluta sobre su estado, es decir, no mantiene versiones por cada fichero si no que toma "instantáneas" sobre todo el repositorio. Esta peculiaridad permite que la creación de braches y tags sea muy sencilla.

Más información

Página del proyecto subversionhttp://subversion.tigris.org/.
Version Control with Subversion: http://svnbook.red-bean.com/.

Manejo básico de Subversion

El comando svn tiene casi los mismos comandos que su homólogo cvs así que los ire exponiendo con un ejemplo.

Creando un nuevo repositorio

Lo primero para empezar a trabajar es crear el repositorio principal donde se almecenará todo el proyecto.
dalamar:~ $ mkdir /home/chernando/svn
dalamar:~ $ svnadmin create /home/chernando/svn
          
Con esto hemos creado los archivos de control para manejar el repositorio. Más adelante comentaré algunas opciones de configuración.

Importando contenidos al repositorio

Debido al sistema de branches y tags que utiliza subversion es recomendable seguir el siguiente patrón a la hora de crear proyectos:
/
        /trunk
        /branches
        /tags
          
En el caso de querer de manejar varios proyectos en el mismo repositorio la cosa quedaría así:
/
        /proyecto1
            /trunk
            /braches
            /tags
        /proyecto2
            /trunk
            /braches
            /tags
          
De esta manera el trabajo de desarrollo principal se basará en el directorio trunk de cada proyecto dejando braches para manejar las ramas y tags para marcar las etiquetas.
Una vez creado el esquema de directorios utilizaremos el comando svn import RUTA REPOSITORIO. Veamos el ejemplo:
crysania:~ $ mkdir -p project/trunk
crysania:~ $ mkdir project/braches
crysania:~ $ mkdir project/tags
# Ahora importaremos el proyecto
crysania:~ $ svn import . svn+ssh://dalamar.shoikan.net/home/chernando/svn \
--message "Esquema inicial de directorios"
          
Podríamos haber copiado todo nuestro código de trabajo al directorio project/trunk antes de realizar el import sin embargo lo he dejado para el siguiente apartado.

Obteniendo un módulo de repositorio

Para obtener un módulo de trabajo utilizaremos el comando svn checkout REPOSITORIO/MODULO DIRECTORIO. Vamos a bajar el trunk para poder luego incluir los ficheros.
crysania:~ $ svn checkout svn+ssh://dalamar.shoikan.net/home/chernando/svn/trunk web
Checked out revision 1.
crysania:~ $ ls -a web
. .. .svn
          

Añadiendo directorios y ficheros

El comando svn add es mucho más cómodo que en la versión cvs para verlo vamos a añadir todo el código del proyecto de la sección anterior de una pasada:
# Copiamos los ficheros que vamos a añadir al repositorio
crysania:~/web $ cp -r ~/trabajo/web/* .
# Utilizamos svn add para añadir todos los directorios y sus ficheros
crysania:~/web $ svn add *
A         art
A         art/apache
A         art/apache/index.html
A         art/xinerama
A  (bin)  art/xinerama/xinerama.jpg
...
# Como podemos ver, marca automáticamente los binarios y en ningún momento
# necesitamos conectarnos con el repositorio.
          
También podemos crear un directorio mediante svn mkdir DIRECTORIO y luego añadir los ficheros con svn add FICHERO:
crysania:~/web $ svn mkdir test
A         test
crysania:~/web $ cd test
crysania:~/web/test $ touch test1
crysania:~/web/test $ svn add test1
A         test1
          

Subiendo los cambios al repositorio

Para ello usamos svn commit {FICHERO}* al que podemos añadir un comentario mediante la opción "--message" o nos abrirá un editor para comentar nuestros cambios.
crysania:~/web $ svn commit --message "Version inicial" 
Adding         art
Adding         art/apache
Adding         art/apache/index.html
Adding         art/irc
Adding         art/irc/1459
# [...]
Transmitting file data ................................
Committed revision 2.
crysania:~/web $ 
          

Manteniendo nuestra copia al dia

Para ello simplemente haremos svn update (exactamente igual que en cvs):
# He borrado manualmente el index.html para forzar su actualizacion
crysania:~/web $ svn update
U         art/apache/index.html
Updated to revision 2.
          

Borrando y moviendo cosas de sitio

Con svn [delete|del|remove|rm] {FICHERO}* podemos eliminar fácilmente ficheros o directorios y sus ficheros. Con svn [move|mv|rename|ren] ORIG DEST podemos renombrar cómodamente y además mantendrá el historial antes de su renombramiento (cosa que no ocurría con cvs).
# Primero renombrar test a basura
crysania:~/web $ svn mv test/ basura
A         basura
D         test/test1
D         test
crysania:~/web $ svn commit -m "Movemos test a basura"
Adding         basura
Deleting       test

Committed revision 4.
crysania:~/web $ ls basura/
test1
crysania:~/web $

# Borremos ahora basura
crysania:~/web $ svn rm basura
D         basura/test1
D         basura
crysania:~/web $ svn commit -m "Fuera basura"
Deleting       basura

Committed revision 5.
          

Conflictos, diferencias e historial

Veamos ahora como manejar los cambios y los problemas que surgen.

Conflictos

Normalmente cuando actualizamos un fichero a nuestra copia local solemos obtener el siguente resultado:
crysania:~/web $ svn update
U         art/apache/index.html
Updated to revision 2.
          
Sin embargo si estamos trabajando sobre una version desactualizada del fichero, es decir se han realizado cambios en el repositorio, pueden ocurrir dos cosas.
Que las modificaciones sean diferentes por lo tanto no hay que hacer nada ya que svn se encarga de mezclar ambas versiones:
crysania:~/web $ svn update
G         art/apache/index.html
Updated to revision 3.
          
O bien que las modificaciones sean en la misma region con lo que no se podran mezclar ambas: conflicto. En este caso svn generara tres archivos para manejar el conflicto:
crysania:~/web/art/apache $ svn update
C         index.html
Updated to revision 4.
# Tenemos un conflicto en este fichero y svn genera:
crysania:~/web/art/apache $ ls -1 index.html.*
index.htm.mine
index.htm.r3
index.htm.r4
          
Siendo: .mine la version con la que estamos trabajando, .r3 la version que habia en el repositorio sobre la que estabamos trabajando y .r4 la version actual del repositorio. Ademas en index.html tendremos marcados los conflictos de la misma manera que los teniamos en cvs.
Se procede a corregir las regiones que esten en conflicto en el fichero base y se utiliza svn resolved FICHERO:
crysania:~/web/art/apache $ svn resolved index.html
Resolved conflicted state of 'acmfi.htm'
# Una vez resuelto el conflicto se eliminan los ficheros axuliares:
crysania:~/web/art/apache $ ls index.html.*
ls: index.html.*: No existe el fichero o el directorio
# No olvidarse de mandar los cambios
crysania:~/web/art/apache $ svn commit index.html \
 -m 'Cambios en la organizacion'
Sending        index.html
Transmitting file data .
Committed revision 5.
          

Diferencias e historiales

Otra de las comodidades de svn se aprecia en la realizacion de parches y en la revision del historial ya que para ambos casos no es necesario conectarse con el repositorio.
Para obtener los cambios realizados en nuestra copia local utilizaremos svn diff {FICHERO}* que nos da una salida valida para enviar parches (ademas de comprobar los cambios antes de enviarlos al repositorio).
crysania:~/web/art/apache $ svn diff index.html
Index: index.html
===================================================================
--- index.html   (revision 4)
+++ index.html   (working copy)
@@ -1,3 +1,4 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" lang="es" xml:lang="es">
   <head>
     <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
          
Para revisar el historial (todos esos sarcasmos que se suelen utilizar en los --message de los commit) simplemente utilizar el comando svn log {FICHERO}*.

Carlos Hernando
URL: http://chernando.eu/

jueves, 9 de junio de 2011

Lista de Servidores SVN CVS Gratuitos


obtenido de  aqui

Repositorio SVN Assembla 
Incluye WIKI , discussion, alerts, chat, ticketing, Trac y Git, Muy bueno , como contra tiene que la version free es publica, los archivos que se suben pueden ser vistos por otras personas
Repositorio SVN Google 
Repositorio de google , uno de los mas rápidos que he visto y sin limites pero los proyectos deben ser openSource
Repositorio SVN MyVersionControl 
Muy bueno , pero solo otorga 100 MB en cuentas FREE
Repositorio SVN ProjXpert 
cualquier cuenta gratis por un mes
Unfuddle
Proyectos que recien inician, en su version free otorga 200 MB en cuentas gratis y acceso para 2 desarrolladores
BeanStalk
100 MB de espacio libre, con 3 usuarios de limite. bastante rapido y seguro.
XP-Dev.com
500MB sin limites de usuarios y repositorios, excelente opcion de free svn server
ProjectLocker
200MB hasta 5 usuarios, "gratis de por vida" es su slogan , vale la pena probarlo


otros  mas



10 Free SVN & Project Hosting Services


UPDATED: As of Jul 10th 2009
Open Source seems to be exploding all over the place at the moment and with online services increasingly jumping on the free offerings its been fantastic for developers wanting to host, manage, flaunt and communicate their projects online. Here’s a rundown of 6 free SVN hosting and project management offerings I like the look of.

Unfuddle

Nice name and nice site. Very web 2.0 and slick with project tracking such as issue tickets, source control, time tracking, milestones, etc. The free package only comes with 200Mb and restrictive user allowances (1 per account) and only one project. This makes them the stingiest of the group. This is reflected in their price-resources on paid plans with $99 only getting you 10Gb and 50 projects. Compare this to $59.99 at Codespaces for the same space but unlimited projects.
Pros: best interface, great features, Git support.
Cons: high price, low resources, tiny free account.

CodeSpaces

They have a hefty 500Mb for 2 free users per account and they have a good range of prices starting from $9 per month for 4-man teams upto $59 for unlimited.
Pros: nice interface, good pricing, active and involved developers.
Cons: Not as many features as the ‘big-beast’ Assembla.

Assembla

Part of a large and feature-packed service full of project management features as well as basic 200Mb of SVN hosting. It even has a jobs board but the project hosting comes with wiki pages, blogs, etc. The free package has all of this but lacks phone supports and is only for open source projects.  They have VERY competitive prices starting from $3.
Pros: packed with features, reliable, supports Mercurial.
Cons: pricey in the higher plans.

OpenSVN

One of the first to release free SVN hosting and starting to show its age with very barebones features. They had a major failure in backup and restore last year which causes some worry about their reliability. So when I say “free SVN hosting” I really mean just that!
Pros: unlimited space, unlimited projects.
Cons: very unreliable, no features!

XP-Dev

This is a very no-frills setup but they have one killer feature: Private SVN repo hosting – FOR FREE!!  Made for agile and extreme programmers this doesn’t have a lot of the features inherent in other services but thats just fine.  Its also got an unlimited repo limit.
Pros: unlimited repos, free private hosting
Cons: Only one paid option, very few features.

Bounty Source

Still going strong after I first mentioned it back in June Bounty Source offer your basic SVN along with a wiki and CMS for managing your projects online presence as well as a task tracker. Bounty Source have a unique feature though that enables a developer to be paid for the work they carry out on user feature requests. Something I really like the look of – all I need now is an open source project people are going to pay me to finish!
Pros: bounty system helps devs get paid to work.
Cons: no paid option, looking old, falling behind in features.

SourceForge

Like an old grandfather clock this has been around years and although very reliable its showing its age. They tried to spruce it up with some Web2.0 gradients and curves but you can’t scrub out the moldy smell from that interface and features-set.
Pros: reliable, well established.
Cons: very intrusive ads, pain to use.

Google Project Hosting

They seem to have taken a lot of the old school methods of project hosting from SourceForge. Unfortunately as mentioned earlier they’re looking old and although Google looks much cleaner its features still lack the richness that the smaller providers have who’ve gone all out on innovation while Google remains formulaic. Google also don’t provide paid private hosting. Its all open source here.
Pros: reliable, clean interface, good features, supports mercurial
Cons: no private paid options, open source only

Comparison Table – Free Accounts

MetricUnfuddleCode SpacesOpenSVNBounty SourceXP-DevGoogleSourceForge
Project/Repo1/Unlimited[1]Unlimited/Unlimited1Unlimited5Unlimited[4]Unlimited
Space200Mb50MbUnlimitedN/A[3]300MbUnlimited[4]Unlimited
WikiYesYesNoYesNoYesYes
TrackingYesYesNoYesNoYesYes
BrowserYesYesNoYesNoYesYes
  • [1] Unfuddle allow one active project but unlimited numbers of repos within it.
  • [3] They state nowhere on their site about limits to project size.
  • [4] Google claim in their terms that there’s no upper limit but they reserve the right to impose one.