Languages

User login


Guia ràpida per a emprar subversion


Aquest document preten fer una breu introducció a l'ús de subversion com a desenvolupador, és a dir, treballar amb la còpia del repositori i aplicar-hi modificacions. Inclou també una guia pas a pas de les ordres més habituals utilitzades en una sessió de treball amb subversion.

Visió general

El primer que hem de fer és aconseguir la copia actual de repositori. Per a fer això emprem la comanda "checkout", o la seva abreviació "co":


svn co http://ruta.al.repositori.net/projecte directori/

Poden passar dues coses: si tothom pot llegir el projecte aquest es baixarà sense problemes, però si s'ha d'estar autentificat demanarà el teu nom d'usuari i clau d'accés per descarregar el repositori.

Si no especifiquem el directori ho descarregarà dins d'una carpeta amb el nom del projecte.

Ara ja tenim la copia activa del nostre projecte. Ara anirem modificant els arxius i fent-hi les modificacions que volguem. Una nota molt important: el arxius i directoris no es poden afegir i esborrar directament (amb cp, mv, o similars). Això només faria que els canvis fossin visibles al nostre directori, però al fer un commit, ordre per aplicar els canvis, aquests no tindran efecte i al fer un checkout tornaríem a baixar l'arxiu esborrat.

Si volem variar alguna cosa del repositori ho hem de fer a través de l'svn. Les ordres d'aquest que haurem de fer servir són les següents, que passo a enumerar amb una breu descripció:

  1. update: Actualitza la nostra copia. => svn update
  2. add : afegeix l'arxiu que s'indica al repositori. => svn add fitxer
  3. delete: esborra l'arxiu que s'indica al respositori.=> svn delete fitxer
  4. copy: copia l'arxiu que volem amb un altre nom. => svn copy fitxeroriginal fitxercreat
  5. move: mou i renombra l'arxiu especificat. => svn move fitxeroriginal fitxercreat
  6. commit: aplica els canvis al repositori (si tens permisos d'escriptura) => svn commit

Dir que aquests paràmetres tenen abreviacions en alguns casos que són més fàcils d'emprar. Per veure-les 'svn help'.

És una bona pràctica efectuar 'svn status' abans de fer un commit, ja que ens indicarà que és el que ha canviat a la nostra copia respecte el repositori. Hi ha diversos indicadors que ens poden sortir al cantó de l'arxiu especificat:


  • A:
    El fitxer, directori o link simbòlic serà afegit al repositori.

  • C:
    L'arxiu presenta un conflicte. Això és quan un altre programador ha fet canvis mentre nosaltres modificavem la nostra copia local i es superposen amb la nova copia. S'ha de resoldre el conflicte abans d'actualitzar el repositori.(raó per a actualitzar constantment la nostra copia local)

  • D:
    El fitxer, directori o link simbòlic serà eliminat del repositori.

  • M
    : Els continguts de l'arxiu ha estat modificats.i

  • X:
    El directori no té versió ( mirar en "External Definitions" de la guia oficial.

  • ?:
    El fitxer, directori o link simbòlic no està sota cap versió.

  • !:
    El fitxer, directori o link simbòlic està a la versió de control del repositori però no es troba o està d'alguna manera incomplet. Això per exemple pot passar quan s'esborra un arxiu a mà, sense fer servir el subversion o un checkout incomplet.

  • ~:
    El fitxer, directori o link simbòlic està al repositori com un tipus d'objecte, però el que hi ha a la teva copia de treball és diferent. Per exemple si esborres un arxiu i crees un directori amb el mateix nom.

  • I:
    Subversion "ignora" l'arxiu, directori o link simbòlic, provablement perquè tu li has dit.

Amb "svn status" podem fins i tot saber qui ha fet les actualitzacions dels arxius que han canviat amb "svn status --verbose".

Si el que volem és veure quins canvis hem aplicat ho podem veure amb "svn diff", que mostrarà les diferències que hem fet a cada arxiu. Això també va bé per a crear patchs: "svn diff > patch".

Per últim si hem fet un canvi a un arxiu i volem tornar-lo al seu estat original ho podem fer amb "svn revert arxiu", o a tot el repositori si ho fem sense argument "svn revert".

Quan fem un update i llavors un status pots passar que vegem un arxiu marcat amb una "C", que indicaria que la modificació que s'ha efectuat sobre el repositori i a la nostra còpia local no coincideixen. Quan passa això el subversion indica a dins del teu arxiu on hi ha els conflictes i es creen tres arxius:

  1. arxiu.mine: Arxiu que teniem a la copia local al moment de fer l'update.
  2. arxiu.rOLDREV: Copia de l'arxiu que teniem en base en el moment de començar a treballar amb l'arxiu.
  3. arxiu.rNEWREV: Nova versió que hi ha al repositori.

* OLDREV i NEWREV són els números de la revisió a la que pertanyen les còpies.

Subversion no et deixarà fer un "commit" fins que no esborris aquests tres arxius temporals.

Hi ha 3 tres maneres de resoldre el conflicte: Barrejar els dos arxius a mà, copiar una de les dues còpies de versió sobre de la teva o fer un "revert" de l'arxiu per a desfer tots els teus canvis. Un cop has pres alguna d'aquestes accions només has d'escriure "svn resolved fitxer" per indicar a subversion que has resolt el conflicte.

Cicle de treball habitual

En general, una sessió de treball al repositori aniria així:

  1. Checkout (creació de la working copy local):
    svn co http://ruta.al.repositori.net/projecte dir_local/
  2. Ens posem dins el directori de la còpia de treball. Modifiquem els arxius que calgui.
    • Si hem d'afegir un nou arxiu (que ja tenim) al repositori:
      cp /usr/local/arxiu.c .
      svn add arxiu.c
    • Si ens cal modificar l'estructura de directoris:
      svn mkdir nou_directori
      svn mv dir_vell dir_nou
    • Si ens cal eliminar un arxiu o directori:
      svn delete arxiu
    • Si ens equivoquem i volem retornar a la versió activa de part del repositori:
      svn revert directori
  3. Mirem què ha canviat del repositori mentre hi treballàvem:
    svn update
  4. Resolem els possibles conflictes que hi pugui haver entre els canvis locals i la feina d'altres desenvolupadors (marcats amb C quan fem l'update), parlant amb ells i consensuant els canvis. Fet això, escrivim:
    svn resolved nom_arxiu.c
  5. Mirem quins canvis introduirem al repositori si fem un "commit":
    svn status
    svn diff
  6. Actualitzem el repositori amb els nostres canvis (si tenim permisos per fer-ho):
    svn commit arxiu -m "Canvi realitzat"

Procediment habitual de treball amb svn

  • Els programadors posen tota la feina nova al trunk.
    Els canvis diaris s'envien a /trunk: noves característiques, correcció d'errors, etc.
  • El trunk es copia a una branca de “llançament”.
    Quan l'equip pensa que el programari està llest per llençar-lo (diguem una versió 1.0), llavors copiem el /trunk a /branches/1.0.
  • Els equips continuen treballant en paral·lel.
    Un equip comença una comprovació rigorosa de la branca de llançament, mentre l'altre equip continua fent nova feina (per la versió 2.0) a /trunk. Si es troben bugs a un o altre lloc, les correccions es porten d'un lloc a un altre segons sigui necessari. Peró arriba un moment en que aquest procés s'atura. La branca es “congela” per fer una comprovació final abans del llançament.
  • La branca es marca i es distribueix.
    Quan la comprovació s'acaba, /branches/1.0 es copia a /tags/1.0.0 com a instantània de referència. Ara podem empaquetar la marca i distribuir-la als clients.
  • La branca es manté durant el temps.
    Mentre la feina continua al /trunk per la versió 2.0, la correcció d'errades es continua portant del /trunk cap a /branches/1.0. Quan s'han acumulat prou correccions, podem decidir fer una versió 1.0.1: /branches/1.0 es copia a /tags/1.0.1 i la marca s'empaqueta i es distribueix.
  • El procés sencer es repeteix a mesura que el programari madura: quan la feina per la 2.0 s'acaba, es crea una nova branca 2.0, es comprova i eventualment es distribueix. Al cap dels anys el repositori acaba amb un nombre de branques de llançament en mode de “manteniment”, i amb un nombre de “tags” representant versions finals distribuïdes.

(extret de http://www.milnou.net/~amanya/blog/)

Comentaris

Opcions de visualització de comentaris

Selecciona la vostra manera preferida de visualitzar els comentaris i feu clic en "Desa la configuració" per activar els canvis.

arreglat

ja l'he esborrar, em penso ;-)

Arreglant estropells

En el cas que haguem fet un commit d'una revisió i haguem introduït canvis que no desitjàvem a un fitxer podem forçar, a la còpia local, que es retorni el seu contingut a una revisió anterior. Fins i tot podem ressucitar fitxers que s'hagin esborrat d'una revisió a una altra. Després de corregir la còpia local, podrem fer un altre commit i deixar les coses en un estat correcte.

Això es fa amb la comanda svn merge.

Suposem que treballem a la revisió 10, introduim un canvi equivocat al fitxer hola.c, i fem el commit, passant a la revisió 11. Per retornar la còpia local d'hola.c a l'estat anterior al commit (en aquest cas, passem de la revisió 11 a la 10), escrivim:

$ svn merge -r 11:10 hola.c

Un cop fet això, tindrem hola.c a l'estat en què estava a la revisió 10. Seguirem tenint la working copy a la revisió 11, conservant per tant els canvis que haguéssim fet a la resta de fitxers. Quan haguem comprovat que hola.c està tal i volíem, fem un altre commit i passem a la revisió 12.

També pot resultar útil veure l'estat del repositori en una revisió anterior a l'actual, per repassar-ne l'estat o compilar versions antigues d'un programa. Per fer-ho, escrivim: svn update -r 10, on 10 és el número de revisió que volem inspeccionar.

Recuperant versions antigues

Si sabem el número de la revisió que volem recuperar d'un fitxer, podem fer-ho amb aquesta comanda:

svn export -r 260 fitxer_actual.sh versio_antiga.sh

Això ens crearà el fitxer "versio_antiga.sh" que serà la revisió 260 del "fitxer_actual.sh"
Si no sabem la revisió, podem veure un log de canvis del fitxer:

svn log fitxer_actual.sh