{"id":20,"date":"2008-08-20T15:51:19","date_gmt":"2008-08-20T13:51:19","guid":{"rendered":"http:\/\/blogs.igalia.com\/premio-pfcsoftwarelibre-2008\/sesion-de-traballo-con-svn-e-envio-de-parches"},"modified":"2008-08-20T15:51:19","modified_gmt":"2008-08-20T13:51:19","slug":"sesion-de-traballo-con-svn-e-envio-de-parches","status":"publish","type":"post","link":"https:\/\/blogs.igalia.com\/premio-pfcsoftwarelibre-2008\/2008\/08\/20\/sesion-de-traballo-con-svn-e-envio-de-parches\/","title":{"rendered":"Sesi\u00f3n de traballo con svn e env\u00edo de parches"},"content":{"rendered":"

Logo do \u00faltimo post onde introduciamos os conceptos b\u00e1sicos dun sistema de control de versi\u00f3ns<\/a>, neste imos simular unha sesi\u00f3n de traballo habitual contra un proxecto de software libre<\/strong>.<\/p>\n

Para iso escollemos o noso obxectivo. Neste caso imos usar un c\u00f3digo que recupera perf\u00eds de usuarios e os artistas m\u00e1is escoitados da plataforma last fm<\/a>. O programa est\u00e1 feito na linguaxe perl<\/em><\/a> e usa a API de last fm<\/a> para facelo. A nosa tarefa ser\u00e1 documentar o que fai cada unha das funci\u00f3ns do c\u00f3digo.<\/p>\n

O que necesitamos nun primeiro momento \u00e9 ter instalado no noso ordenador un cliente svn<\/em> para conectarnos \u00f3 servidor e descargar o c\u00f3digo. En Ubuntu o paquete a instalar ch\u00e1mase subversion<\/em>.<\/p>\n

OBTENCI\u00d3N DO C\u00d3DIGO FONTE E REALIZACI\u00d3N DE CAMBIOS <\/strong><\/p>\n

Unha vez o temos imos crear un directorio de traballo temporal para realizar esta sesi\u00f3n. Nunha consola (o s\u00edmbolo $ indica que son comandos de shell<\/em> o que vai a continuaci\u00f3n) facemos o seguinte:<\/p>\n

$ mkdir \/tmp\/lastfm_test<\/p>\n

$ cd \/tmp\/lastfm_test<\/p>\n

$ svn checkout uri_svn<\/em> .<\/p>\n

uri_svn<\/em> = https:\/\/svn.forge.morfeo-project.org\/svn\/freeswmaster\/trunk\/amaneiro\/perl-workshop\/<\/p><\/blockquote>\n

Neste momento temos o c\u00f3digo \u00e1 nosa disposici\u00f3n e podemos empezar a traballar con \u00e9l.<\/p>\n

Si agora observamos as diferencias da nosa copia local de traballo<\/em> (co\u00f1ecida como working copy<\/em>) con respecto \u00f3 repositorio<\/em> (comandos svn diff<\/em>, svn status<\/em>) veremos que a sa\u00edda de ambos comandos \u00e9 vac\u00eda. L\u00f3xicamente, debe ser as\u00ed, porque a\u00ednda non fixemos ningunha modificaci\u00f3n con respecto \u00f3 c\u00f3digo que nos descargamos. \u00c9 un bo momento para ver tam\u00e9n a historia do proxecto (usando o comando svn log<\/em>) e xogar coas m\u00faltiples opci\u00f3ns que pos\u00fae.<\/p>\n

Para seguir coa sesi\u00f3n, abrimos o noso editor favorito e modificamos o ficheiro ex11.pl<\/em> documentando cada unha das funci\u00f3ns.<\/p>\n

Unha vez rematemos, podemos observar os cambios<\/a>: c\u00f3mo variou o estado da nosa copia local de traballo<\/em> con respecto \u00f3 repositorio<\/em>. Comprobamos os ficheiros modificados (comando svn status<\/em>) e logo as modificaci\u00f3ns introducidas en cada un deles (comando svn diff<\/em>).<\/p>\n

SUBINDO OS CAMBIOS REALIZADOS<\/strong><\/p>\n

Agora que sabemos que os cambios que se realizar\u00e1n son os correctos, debemos asegurarnos de ter a \u00faltima versi\u00f3n do c\u00f3digo do repositorio<\/em>, pois \u00e9 posible que algu\u00e9n m\u00e1is estivese traballando en paralelo e o c\u00f3digo que te\u00f1amos na nosa copia local de traballo<\/em> est\u00e9 desactualizado con respecto \u00f3 repositorio<\/em>. Actualizamos pois a nosa copia de traballo<\/em> (comando svn update<\/em>).<\/p>\n

Unha vez resoltos os posibles conflitos existentes<\/a>, estamos listos para enviar os cambios \u00f3 repositorio. Pode darse calquera das 2 situaci\u00f3ns seguintes:<\/p>\n

    \n
  1. Temos unha conta propia no repositorio do proxecto: podemos enviar os cambios directamente.<\/li>\n
  2. Non temos conta no repositorio do proxecto: debemos enviar os cambios a algu\u00e9n que te\u00f1a conta.<\/li>\n<\/ol>\n

    No primeiro caso bastar\u00eda con facer:<\/p>\n

    $ svn commit<\/em><\/p><\/blockquote>\n

    Autom\u00e1ticamente abrir\u00edase o editor de texto predeterminado do sistema e no arquivo que nos abre escribimos unha breve descripci\u00f3n dos cambios realizados (“documentaci\u00f3n das funci\u00f3ns” no noso caso). Gardamos o arquivo e cerramos o editor. Os cambios son enviados \u00f3 repositorio.<\/p>\n

    Si estamos na segunda opci\u00f3n (non temos conta) debemos enviar un parche \u00e1s listas do proxecto para que o revise e o incl\u00faa no repositorio si o considera oportuno.<\/p>\n

    C\u00d3MO ENVIAR UN PARCHE<\/strong><\/p>\n

    Como xa dixemos, \u00e9 posible que non te\u00f1amos acceso \u00f3 repositorio para subir os cambios. Neste caso, a estratexia a seguir consiste en realizar un informe das diferencias entre a nosa copia local de traballo e o repositorio<\/strong>. Ser\u00e1 iso o que lle enviaremos \u00e1s listas do proxecto para que vexan os cambios e os apliquen sobre o repositorio si o creen conveniente.<\/p>\n

    Para facer isto existen as ferramentass diff<\/em> (que compara arquivos li\u00f1a por li\u00f1a) e patch <\/em>(que aplica un parche determinado sobre un arquivo). As\u00ed, un parche pode entenderse como un informe de cambios respecto a un (ou varios) arquivo(s). Podedes observar as funcionalidades de cada unha delas na propia p\u00e1xina do manual. Para o caso que nos ocupa, o propio cliente de subversion<\/em> trae integrada a posibilidade de facer un diff<\/em> da copia de traballo con respecto \u00f3 repositorio.<\/p>\n

    O \u00fanico que temos que facer para ter un arquivo cos cambios respecto \u00f3 repositorio \u00e9:<\/p>\n

    $ svn diff > parche.diff<\/em><\/p><\/blockquote>\n

    Deste modo, no ficheiro parche.diff<\/em> temos os cambios ficheiro por ficheiro. \u00c9ste arquivo ser\u00e1 o que se env\u00eda \u00e1s listas do proxecto para que comproben que o parche \u00e9 correcto, se discuta e se aplique en \u00faltimo caso.<\/p>\n

    Cada proxecto ten as s\u00faas normas sociais<\/em> \u00e1 hora de enviar parches, mais en xeral, boas pr\u00e1cticas \u00e1 hora de realizar e enviar un parche<\/strong> son:<\/p>\n