Proyecto

General

Perfil

Subversion » Histórico » Versión 1

Anónimo, 2010-05-18 11:31

1 1 Anónimo
h1. Subversion
2
3
h2. Introducción
4
5
Subversión es un sistema de gestión de código fuente, lo que supone que:
6
* Un usuario que trabaja en diferente ordenadores en un mismo proyecto puede estar seguro de que sus archivos están actualizados siempre
7
* Varios usuarios trabajando juntos en un proyecto pueden estar seguros de que los cambios que hacen otros no son machacados por accidente
8
* Varios usuarios trabajando juntos pueden asegurarse de que todos sus archivos están actualizados
9
* Se puede _ir atrás en el tiempo_ y recuperar una versión antigua de uno o múltiples ficheros
10
11
h2. Los primeros pasos
12
13
Asumiendo que se ha instalado subversion _(apt-get install subversion)_ y solicitado la cuenta de subversion para trabajar en el código de un proyecto, para empezar necesitas estos tres datos (usaremos aquí datos de ejemplo):
14
* login de usuario= pepe
15
* contraseña= estomegusta
16
* url= http://desarrollo.educarex.es/svn/colegios/zeroconf-services
17
18
Lo primero que necesitas es hacer un _checkout_ de la copia de trabajo del proyecto. Esto se hace mediante el comando:
19
<pre>
20
 svn checkout http://desarrollo.educarex.es/svn/colegios/zeroconf-services --username pepe --password estomegusta
21
</pre>
22
23
Tu ordenador recuperará una copia del proyecto desde el servidor y la almacenará en tu ordenador en el directorio desde el que hayas ejecutado ese comando (esta copia se llama _copia de trabajo_ y la operación de descargarla se llama _checkout_).
24
Si miras en los archivos descargados verás que hay un directorio llamado "trunk". En este directorio encontrarás todos los archivos que forman parte del proyecto y ya puedes empezar a trabajar con ellos. IMPORTANTE: Lo habitual es hacer el _checkout_ una sóla vez por cada proyecto/persona/ordenador.
25
26
h3. Subversion desde Eclipse
27
28
Si se usa "Eclipse":www.eclipse.org para programar, no es necesario usar la consola, se puede manejar subversion desde el entorno integrado. "Aquí hay un tutorial para instalar el plugin necesario":http://daredled.blogspot.com/2009/08/howto-eclipse-y-subversion-en-ubuntu.html
29
30
Una vez instalado el plugin, se puede ir al menú File -> New ->Other -> SVN ->Project from SVN
31
Luego hay que usar la opción "Create a new repository location", y ahí rellenar los campos correspondientes a la url, usuario y contraseña.
32
33
34
35
h2. Forma habitual de trabajar con svn
36
37
Una vez que tienes la copia de trabajo, se entra en un ciclo habitual trabajando con los archivos:
38
* _Update_: para obtener los cambios que otros  hayan hecho (o los que hayas hecho tu trabajando en otro ordenador)
39
* Editar: haces cambios en los archivos para escribir código, documentación, etc.
40
* _Commit_: Envias tus cambios al servidor.
41
42
Veamos más en profundidad estos tres pasos
43
44
h3. Update
45
46
47
Cuando otros hacen cambios y los suben al servidor, no se envían automáticamente a tu ordenador. Tu tienes que obtener los cambios desde el servidor y actualizar los archivos de tu copia de trabajo. Esto significa que pueden añadirse, modificarse o borrarse archivos durante el proceso de _update_, según lo que otros hayan hecho. Mi consejo es que actualices tu copia de trabajo siempre antes de empezar a editar los archivos, para trabajar siempre sobre los últimos cambios. Para actualizar tu copia de trabajo ejecutas el comando <pre>svn update</pre>dentro del directorio que quieras actualizar.
48
Mientras subversion hace la actualización irá mostrando información de que archivos modifica/borra/añade y normalmente no hay nada más que hacer. Sin embargo, a veces hay un conflicto que tendrás que manejar. Más abajo explico como hacerlo.
49
50
h3. Editar
51
52
Puedes editar los archivos de tu código fuente con cualquier programa o editor de textos (Mi recomendación es usar _geany_ para pequeños archivos y _eclipse_ para proyectos más grandes, con los plugin de php, python, etc., según sea necesario).
53
54
h4. Commit
55
56
Después de editar los archivos es hora de enviar los cambios al servidor, para que otros puedan ver lo que has hecho. Te vas al directorio donde están los archivos y haces así:
57
<pre>svn commit -m "Aquí pongo algún mensaje explicativo"</pre> El texto puede ser cualquier cosa pero lo mejor es que sea algún comentario útil para que tus colegas sepan qué has hecho. Normalmente subversion devolverá algún mensaje sobre lo que ha hecho y dirá que ya está (vale, puedes tener conflictos aquí también... te lo explico después)
58
59
h2. Otros comandos
60
61
h3. Añadir archivos
62
63
Como es lógico, puedes añadir archivos al proyecto. Tan sólo crea el archivo y ponlo en donde quieras dentro de tu copia de trabajo, después ejecutas <pre> svn add ruta_al_archivo_nuevo</pre> Por ejemplo, si estás en el proyecto _usbhome_ y añades el fichero Instrucciones.txt al directorio de documentación, tienes que ejecutar este comando para añadirlo al proyecto de subversion: <pre>svn add doc/Instrucciones.txt</pre>
64
65
Es importante que sepas que esto no envia los archivos al servidor, para eso debes hacer un _commit_ como se explicó arriba.
66
67
h4. Borrar archivos
68
69
Si quieres borrar un archivo de un proyecto deberías dejar que subversion lo haga. Siempre debes tener en cuenta que el archivo se borrará de la _versión actual_ del proyecto, pero que estará en el repositorio del servidor. Así si te das cuenta de que has borrado el archivo por error, puedes recuperarlo _checking out_ una versión más antigua del proyecto. En fin, para borrar un archivo ejecutas el comando <pre>svn delete ruta_al_archivo</pre> Así, si quieres borrar el archivo que añadiste arriba, tendrías que ejecutar <pre>svn delete doc/Instrucciones.txt</pre>
70
Igual que antes, esto no le dice al servidor que borre el archivo de la versión actual del código. Para eso debes hacer un _commit_ como antes.
71
72
h4. Mover o Renombrar archivos
73
74
Si queremos renombrar un fichero tan solo deberemos ejecutar la siguiente acción <pre>svn move nombre_inicial nombre_final</pre>. Como en las anteriores ocasiones, habrá que hacer un _commit_ para que la acción se lleve a acabo.
75
76
77
h3. ¿Qué archivos has modificado tu?
78
79
Antes de hacer un _commit_ con todos los archivos que has cambiado, añadido o borrado, es bueno estar seguro de que quieres mandar todo eso al servidor. A veces puede ser difícil recordar que has creado archivos y se te ha olvidado añadirlos al proyecto subversion,o simplemente no recuerdas cosas que has podido cambiar desde tu último _commit_. Para saber todo eso has de usar el comando _status_. Veamos con un ejemplo lo que ocurre al usarlo:
80
<pre>
81
#ls
82
ph_intro.aux ph_intro.log ph_intro.pdf ph_intro.tex sigproc.bib
83
84
#svn status
85
? ph_intro.log
86
? ph_intro.aux
87
M ph_intro.tex
88
</pre>
89
En la primera línea uso el comando ls para ver que archivos hay en este directorio, puedes ver que hay  cinco archivos. Después ejecuto el comando status y subversion responde con tres líneas. El símbolo '?' quiere decir que este archivo no es parte del proyecto y el 'M' que mi copia de ph_intro.tex ha cambiado. Ahora puedo añadir los archivos ph_intro.log y ph_intro.aux con el comando _'add'_, pero como son archivos temporales no me molesto en añadirlos y directamente los puedo borrar. De todos modos debería hacer un _commit_ para enviar los cambios que he hecho en el archivo ph_intro.tex y que los demás programadores puedan verlos.
90
91
h4. ¿Qué ha hecho otra gente?
92
93
Si quieres saber que cambios ha hecho otra gente a un archivo puedes usar el comando log <pre>svn log</pre> o <pre>svn log ruta_al_archivo</pre>
94
Por ejemplo:
95
<pre>
96
# svn log ph_intro.tex
97
------------------------------------------------------------------------
98
r5 | jem | 2006-10-21 17:59:47 +0200 (Sat, 21 Oct 2006) | 1 line
99
Añadido texto de Pepe
100
------------------------------------------------------------------------
101
r4 | mark | 2006-10-17 21:54:53 +0200 (Tue, 17 Oct 2006) | 1 line
102
Puestas nuevas categorías
103
------------------------------------------------------------------------
104
r2 | jem | 2006-10-09 22:30:57 +0200 (Mon, 09 Oct 2006) | 1 line
105
Primer borrador
106
------------------------------------------------------------------------
107
></pre>
108
Aquí puedes ver que ph_intro.tex está actualmente en su quinta revisión, el último cambio lo hizo "jem" con el comentario "Añadido texto de Pepe". También se ve que cuando se hizo ese cambio, se estaba en la revisión 4, enviada por Mark unos cuatro días antes cuando puso nuevas categorías.
109
110
h4. ¿Y si subversion dice algo incorrecto?
111
112
Algunas veces subversion se queja de que algo está mal en tu copia local. Si eso te ocurre probablemente deberías hablar con alguien que esté trabajando contigo y conozca bien el uso de subversion (o mirar en el "libro de subversion":http://svnbook.red-bean.com/). Sin embargo, hay un comando que puedes intentar antes de pedir ayuda:
113
<pre>svn cleanup</pre>
114
Borrará algunos archivos temporales y a veces hace sentirse feliz otra vez a subversion.
115
116
h2. Conflictos
117
118
¿Qué ocurre si dos personas hacen cambios en el mismo archivo al mismo tiempo? Normalmente nada. Subversion vee que los dos habeis hecho algún cambio y coge los dos cambios y los mezcla en una nueva versión del documento. Como ejemplo, veamos este archivo de texto:
119
<pre>
120
This is just some short example text to show
121
how suuversion works when it detects that several
122
users have changed the same file.</pre>
123
Este archivo ha sido enviado al servidor por el usuario A. El usuario B actualiza su copia de trabajo y ve que el archivo existe. B mira el archivo y ve que no está bien escrita la palabra subversion. B corrige el error y hace un _commit_ del archivo.  Al mismo tiempo el usuario A añade más texto al final del archivo y hace también su _commit_ sin haber hecho antes un _update_ (que le habría actualizado los cambios que hizo B). En resumen, que A envia este texto al servidor:
124
<pre>This is just some short example text to show
125
how suuversion works when it detects that several
126
users have changed the same file.
127
Subversion is actually a really useful tool for
128
anyone who uses a computer.</pre>
129
Mientras que B envia este otro texto:
130
<pre>This is just some short example text to show
131
how subversion works when it detects that several
132
users have changed the same file.</pre>
133
Ambos textos modifican el mismo número de versión del archivo, así que ¿cual debería guardar subversion? La respuesta es que  ninguno de los dos. En lugar de eso subversion ve que los cambios no se solapan, lo que quiere decir que subversion los puede mezclar en una nueva versión:
134
<pre>This is just some short example text to show
135
how subversion works when it detects that several
136
users have changed the same file.
137
Subversion is actually a really useful tool for
138
anyone who uses a computer.</pre>
139
Esto es lo que suele ocurrir. No hay que hacer nada para asegurarse de que el documento contiene los últimos cambios. ¿Y qué ocurre si resulta que los cambios se solapan?. La respuesta es muy simple: subversion no hace nada, le deja la responsabilidad de resolver el conflicto a la persona que hizo la última operación de _commit_. (Si B hizo el commit 1 segundo después de A, B es el que tiene que arreglar el conflicto). Como esto nunca me ha ocurrido no voy a explicar como arreglarlo (Hay instrucciones para "arreglarlo aquí":http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html#svn.tour.cycle.resolve )
140
141
142
NOTA: Esta documentación es una traducción libre con algún añadido del texto de "Jan Erik Moström":http://www.mostrom.pp.se/notes/Tutorials/SVNMiniTutorial