1 copyright procesix inc. cualquier copia u otro uso debe ser autorizado expresamente por procesix...

1ã Copyright Procesix Inc. Cualquier copia u otro uso debe ser autorizado expresamente por Procesix Inc.

Procesix 2012

Desarrollo con Subversion

Control de Versiones con SubversiónVersión Desarrolladores/Usuarios

Lenin David Lozano ArgelConsultor

Procesix ColombiaEnero de 2012


Procesix 2012


Objetivos, Presentación

Objetivo: Aprender el uso del sistema de control de versiones Subversion, desde

la perspectiva de uso por parte de un desarrollador.

Presentación Quien es? En que plataforma trabaja? Lenguaje, IDE? Para que cree que usará Subversion? Experiencia con VCS? Que sabe de Subversion?

Plan detallado


Procesix 2012


PREGUNTAS?

Gracias!!!!


Procesix 2012


Agenda

Control de Versiones Conceptos Básicos

Copia de trabajo Repositorio …

Ciclo estándar Branching y Merging Buenas practicas Eclipse


Procesix 2012


INTRODUCCIÓN A SUBVERSION

Subversion para desarrolladores

Duración: 1 hora


Procesix 2012


Control de Versiones

Una forma de manejar la complejidad de los proyectos de software es a través de los sistemas de control de versiones.

Llega un punto en el desarrollo de proyectos en el cual…. Hay cuellos de botella en la comunicación. Conocer la ultima versión es crucial. Se llega a una duplicación de esfuerzo. Se presentan sobreescrituras.

Aka Control de Revisiones, aka Control de Código Fuente. Permite almacenar los resultados del proyecto en una ubicación central. Permite hacer seguimiento a los archivos en el tiempo. Cuando se comete un error se puede fácilmente regresar a una versión

anterior que sea correcta. No es una forma de backup, ni de paso de información entre

desarrolladores.


Procesix 2012


Entonces que es?

Gestión del desarrollo de cada elemento de un proyecto a lo largo del tiempo.

Proporciona: Mecanismo de almacenaje de cada elemento que deba gestionarse. Posibilidad de añadir, modificar, mover, borrar… Historial de las acciones realizadas con cada elemento pudiendo volver

a su estado anterior. Otros: Generación de informes de cambio, informes de estado, marcado

con nombre identificativo.

Se utiliza un repositorio, donde se almacena la información de todo el desarrollo.

Útil para trabajar individualmente o en grupo. Servidor Local o Remoto. Permite desarrollos colaborativos. TODO EQUIPO PROFESIONAL DE DESARROLLO LO UTILIZA


Procesix 2012


Por que lo necesitamos?

Es bueno trabajar con carpetas compartidas? Si, pero no es escalable en los proyectos. Microsoft tiene su Windows 7 en una carpeta llamada

“Windows_7_201010”?

Los proyectos grandes que requieren cambios constantes con muchos desarrolladores requieren un SCV para realizar seguimiento a los cambios y evitar el caso general.

Para qué? Necesitas un archivo de Febrero 15 de 2001. Respaldo y Recuperación. Las personas pueden tener la ultima versión. Sincronización. Se dañó un archivo con el que se estaba jugando?. Deshacer cambios. Se hizo un cambio hace un año y tenia un bug. Deshacer cambios

remotos. Dejar mensajes del cambio que fue realizado. Seguimiento a cambios. Saber quien hizo un cambio. Seguimiento a realizadores de cambios. Puedes hacer cambios locales sin afectar a otros. Caja de arena. Modificaciones aisladas del código principal. Branching.


Procesix 2012


Modelos de Versionamiento

Misión Principal Habilitar la edición colaborativa y compartir datos.

Cómo se puede compartir información pero prevenir que se pisen las mangueras?


Procesix 2012


Modelo Bloqueante

Bloqueante (Lock – Modify –Unlock) En algunos sistemas como VSS, se usa este esquema.


Procesix 2012


Problemas del bloqueo

Bloquear puede causar problemas de gestión. Demoras innecesarias y pérdida de tiempo.

Bloquear puede causar una secuencialización innecesaria. Así los cambios no se solapen, dos o mas usuarios no pueden editar el

archivo simultáneamente.

Bloquear puede causar una falsa sensación de seguridad. Cuando hay una dependencia entre varios archivos, no se soluciona

nada bloqueando sólo uno, ya que una dependencia puede cambiar y el proyecto pierde integridad.


Procesix 2012


Modelo No Bloqueante

No bloqueante (Copy – Modify – Merge) Si dos usuarios han recuperado del servidor 2 copias de trabajo que

contienen el mismo archivo, nada les prohíbe a ellos que realicen cambios sobre el archivo.

Puede ser raro, ya que no hay garantía de que los cambios no entren en conflicto.


Procesix 2012


Y si los cambios se solapan?

Se produce un conflicto

Se puede resolver de 3 formas Editando manualmente las líneas conflictivas.

Eligiendo una de las versiones.

Deshaciendo todos los cambios locales.

El tiempo de resolver un conflictoes mucho menor que el tiempo del bloqueo.

Los usuarios pueden trabajar en paralelo, sin tener que esperarse el uno al otro.

La mayoría de los cambios concurrentes no se solapan en absoluto; los conflictos son poco frecuentes.

Un factor critico para la productividad: La comunicación entre los usuarios. ¡Hay que conversar con los compañeros!


Procesix 2012


Taller sobre conceptos de Subversion

Duración del taller 15 minutos

Desarrollo de la evaluación. Realice una investigación de los sistemas de control de versiones Visual

Source Safe, GIT y Subversion y analice sus diferencias, ventajas y desventajas para su trabajo actual

Describa un escenario donde un modelo bloqueante de Control de Versiones sea mas adecuado que un modelo no bloqueante


Procesix 2012


TERMINOLOGIA


Duración: 1/2 hora


Procesix 2012


Terminología - El Repositorio

Es el núcleo principal del sistema subversion. Es el almacenamiento central de los datos del sistema. Usualmente se almacena como un árbol.

Jerarquía de archivos y directorios. Cualquier cantidad de clientes se conectan al directorio

como una arquitectura cliente – servidor. Es una clase de servidor de archivos

Pero, a medida que los archivos cambian, el repositorio recuerda cada versión de esos archivos.

Manejar histórico Se obtiene cualquier versión del archivo.


Procesix 2012


Terminología – Working Copies

Es la copia local de los archivos de un repositorio, en un momento del tiempo o revisión especifico.

Cómo el usuario de un sistema de control de versiones interactúa con un repositorio lleno de varias versiones de un archivo concreto?

Cómo los programas con que se trabajan acceden a estos archivos?

La respuesta es la Copia Local de Trabajo. Es una versión local o una copia local de una versión particular con la

cual el usuario es libre para trabajar. Es responsabilidad del cliente SVN llevar estos cambios nuevamente al

repositorio.


Procesix 2012


Working Copies

Es un directorio común en el sistema local. Contiene un grupo de archivos. Es el área privada propia. No se incorporan cambios desde Subversion, a menos que lo hagas

explicito. Se pueden tener múltiples copias del mismo proyecto.

También contiene archivos extras Un subdirectorio llamado .svn – Directorio administrativo de SVN.

Cómo trabaja? Por cada archivo se guardan 2 cosas:

• Sobre que revisión está basado el archivo (working revision)• Estampa de tiempo, guardando la ultima vez que fue

actualizado por el repositorio.


Procesix 2012


Working Copies – Estados

Con los archivos administrativos y por medio de consultas al repositorio se pueden tener 4 estados.

No modificada, y actual.

• El archivo no se ha modificado en la copia de trabajo. Y no hay cambios en el repositorio. Este archivo no se toca.

Modificada Localmente, y actual.

• Ha sido cambiada localmente, y no se han hecho cambios en el repositorio desde la actualización. Con commit, se almacenan los cambios.

No modificada, y desactualizada.

• No ha sido cambiado localmente pero se han hecho cambios en el repositorio. Se debe hacer un svn update.

Modificada localmente, y desactualizada.

• Se ha cambiado el archivo localmente y en el repositorio. Un commit fallaría, y es necesario actualizar. Se pueden presentar conflictos.


Procesix 2012


Terminología – Revisiones

Cuando un repositorio acepta un cambio, crea un nuevo estado en árbol del sistema de archivos, llamado una REVISION.

Cada revisión tiene un numero único. Es un numero mayor a la revisión anterior. La revisión inicial se numera con 0 y es el directorio raíz vacio.

A diferencia de otros VCS, en subversión los números de revisión son para el árbol, no para archivos particulares.


Procesix 2012


Terminología – Rama (Branch)

Líneas de desarrollo independientes a otras, pero comparten una historia común si se mira lo suficientemente atrás en el tiempo.


Procesix 2012


Terminología – Etiquetas (Tags)

Es una rama sobre la que NO se incluyen cambios. (Línea Base***).

Contiene el código y archivos de una revisión especifica.

Se etiqueta la revisión para establecer un hito en la línea de desarrollo.


Procesix 2012


Aprender la lengua SVN

Conceptos Básicos Repositorio (repo): La base de datos para almacenar archivos. Servidor: El computador que almacena el repo. Cliente: El computador que se conecta al repo. Working Set/Working Copy: Directorio local de archivos, donde se

hacen los cambios. Trunk/Tronco/Main: La ubicación principal del código en el repositorio.

Pensar como un arbol genealógico. HEAD: La última revisión en el repo. ChangeLog/Historia: Lista de cambios hechos a un archivo. Sync: Sincronizar los archivos con lo ultimo en el repo. Revert: Recargar la ultima versión del repo, sobreescribiendo cambios. Delta/Diff: Encontrar la diferencia entre dos archivos, puede ser 2

revisiones. Merge/Parche: Aplicar los cambios de un archivo en otro. Conflicto: Cuando los cambios pendientes a un archivo se contradicen

entre si. Resolver: Arreglar los cambios que se contradicen. Locking/Bloquear: Tomar el control de un archivo para que nadie

pueda editarlo.


Procesix 2012


Taller sobre conceptos de subversion

Duración del taller 15 minutos

Desarrollo de la evaluación.


Procesix 2012


GESTIÓN DEL REPOSITORIO


Duración: 1/2 hora


Procesix 2012


Planear la organización del repositorio

Cual es la mejor forma de organizar un repositorio? Usar un solo repositorio para múltiples proyectos Dar a cada proyecto su propio repositorio. Combinación de los 2. Seguir las buenas practicas.


Procesix 2012


Donde y como establecer el repositorio

Es una pregunta obligatoria, Donde van a vivir las cosas? Además, Cómo será accedido el repositorio? Por quienes será accedido?

Un repositorio por producto/proyecto/línea de producto Generalmente, cuando se esperan diferentes privilegios de acceso

Un solo repositorio para todo Si no se requiere control de acceso por proyecto/producto Especialmente si se requiere copiar o compartir archivos (código) entre

proyectos. Recomendación: USAR VENDOR BRANCHES

No se debe crear el repositorio en un directorio compartido en red.

No puede existir en un filesystem NFS, AFS o Samba.


Procesix 2012


Organización de Repositorio

Crear una jerarquía inicial de directorios Crear 3 directorios debajo del raíz: TRUNK – Desarrollo principal BRANCHES – Ramas de la línea principal de desarrollo TAGS – Ramas que pueden ser destruidas.

No hay una obligación para un layout del repositorio

Creación Se puede usar snv mkdir o svn import (con un layout creado localmente)

$ mkdir tmpdir$ cd tmpdir$ mkdir projectA$ mkdir projectA/trunk

$ svn import . file:///path/to/repos --message 'Initial repository layout‘Adding projectAAdding projectA/trunk


Procesix 2012


Donde se ubica el layout?

Se crean los directorios trunk, tags, branches al nivel donde el código deba ser entregado como un paquete único

Donde se crea la versión de producto No es critico tenerlo bien al principio.

Se puede trabajar con la idea de una “Raíz de Proyecto” Es el punto de anclaje del proyecto Contiene los 3 directorios Un solo repositorio puede tener una “raíz de proyecto” o varias


Procesix 2012


Taller

Objetivo: Estudiar las estructuras de los proyectos actuales en la organización.

Duración: 15 minutos Socialización: 10 minutos

Analizar las ventajas y desventajas de cada esquema. Plantear una solución en la organización


Procesix 2012


CICLO DE TRABAJO


Duración: 2 horas


Procesix 2012


Ciclo de trabajo con Subversion

Actualizar la copia de trabajo

Hacer los cambios

Revisar los cambios

Corregir los errores

Resolver cualquier conflicto

Publicar los cambios


Procesix 2012


Importar archivos y directorios

Operación para introducir en el repositorio la primera revisión de un proyecto.

La operación puede realizarse situándose el usuario en el directorio local que contiene la primera revisión

Se crean los directorios intermedios que sean necesarios. Con el import no se requiere una Working Copy y los archivos son

inmediatamente confirmados en el repositorio Es una buena idea que el import inicial contenga únicamente la

estructura de directorios que se utilizará posteriormente (los directorios trunk, branches y tags)

Pero si no el import se debe realizar sobre el trunk

$ svn import /path/to/mytree \ http://host.example.com/svn/repo/some/project/trunk \ -m “Import inicial“

Hay que tener en cuenta que después de un import, el directorio original local, NO es convertido a una Working Copy. Hay que hacer un check out para poder trabajar.


Procesix 2012


Taller Ciclo de Trabajo con Subversion

Duración del taller 10 mins

Desarrollo del taller Teniendo en cuenta el taller anterior, crear la estructura base, coodinar

con los otros compañeros. Cada persona tendrá su propia aplicación Llevar el proyecto de ejemplo, o algún código personal al repositorio en

la ubicación correspondiente


Procesix 2012


Creando una copia de trabajo

En realidad, para trabajar con Subversion se debe verificar o sacar del repositorio los archivos

Check out, edit y check in. El ciclo se ve.

Se puede revertir el cambio usando el comando revert.

Tronco principal

ArrozHuevosSopa

ArrozHuevos

Jugo

ArrozHuevosSopa

RevertirCheck in

Check out

Copia Local


Procesix 2012


Creando una copia local (2)

La mayoría del tiempo se inicia el trabajo con el repositorio realizando un checkout del proyecto

Este crea una copia de trabajo de ese directorio en la maquina local A menos que sea especificado, esa copia contiene el HEAD de los

directorios y archivos.

svn checkout http://host.example.com/svn/repo/trunk

Se puede hacer checkout mas profundo de cualquier directorio o archivo.

svn checkout http://host.example.com/svn/repo/trunk/src

http://host.example.com/svn/repo/trunk

http://host.example.com/svn/repo/trunk

http://host.example.com/svn/repo/trunk/src

http://host.example.com/svn/repo/trunk/src


Procesix 2012




Desarrollo del taller Crear dos copias locales de trabajo del mismo proyecto con svn en dos

directorios diferentes.


Procesix 2012


Checkout parciales

Muchas veces no se requiere “sacar” todo el árbol de directorios y archivos del repositorio

Trabajar con una porción en la copia local Para sacar posteriormente los archivos ignorados en el checkout inicial Optimizar el uso de los canales de red y la carga sobre el servidor SVN

Checkout tímidos o directorios dispersos Característica de subversion para hacer checkout parciales Se agrega al checkout la opción --depth

Se maneja la profundidad del checkout empty Solo el directorio que se hace checkout, sin hijos files El directorio al que se le hace checkout con sus hijos de tipo

archivo immediates El directorio y sus hijos inmediatos infinity Recursion total


Procesix 2012




Desarrollo del taller Hacer pruebas con los diferentes esquemas de checkout parciales Analizar los resultados


Procesix 2012


Actualizar la copia de trabajo

Se deben hacer las actualizaciones de la copia de trabajo local para incluir los cambios realizados en otras copias de trabajo de otros desarrolladores.

Para proteger datos, Subversion no permite que se haga commit de nuevos cambios a archivos o directorios desactualizados.

Se usa el comando update de svn.

svn update

Ahora se pueden hacer los cambios en la copia local. Cambios de archivo. Cambios de directorio. Cuando se trata de archivos… No hay que anunciar los cambios,

simplemente se realizan con la herramienta de predilección.

Pero si se trata de directorios, la cosa cambia……


Procesix 2012


Cambios en el árbol de directorio.

Involucra cambios a la estructura del directorio. Para cambios en el árbol

No se hacen los cambios inmediatamente, sino que se agenda para el próximo commit. A diferencia de con los archivos.

Los 5 comandos usados para hacer cambios en el árbol svn add FOO

• Adicionar FOO al repositorio. svn delete FOO

• Borra FOO del repositorio. svn copy FOO BAR

• Crea un nuevo item BAR que es un duplicado de FOO. svn move FOO BAR

• BAR se programa para adicionarse como una copia de FOO y FOO se programa para borrado.

svn mkdir FOO

• Un nuevo directorio llamado FOO se crea y se programa para adición.


Procesix 2012




Desarrollo del taller Realizar los siguientes cambios en el proyecto en este orden:

• Adicionar el directorio util• Adicionar nuevos archivos al directorio util• Renombrar el directorio unit por test

Crear el directorio comp usando el explorador o el shell Analizar la situación


Procesix 2012


Revisar los cambios

Antes deshacer visibles los cambios al repo, se debe hacer revisión.

Examinando los cambios usando los comandos Se pueden inferir mensajes de log mas precisos y consistentes a los

cambios. Se puede verificar que se cambió un archivo por accidente. Y deshacer

los cambios antes del commit.

Los comandos que permiten hacer revisión de los cambios son:

svn diff : Se puede ver el detalle de los cambios realizados a los archivos.

svn status: Puedes tener una vista general de los cambios que se han hecho.


Procesix 2012


Corregir los errores

Una vez se ha revisado con diff se puede notar que los cambios no son los deseados

Se puede usar el comando revert para regresar al estado previo a los cambios locales.

Este comando actúa inclusive fuera de línea.

svn revert list.txt (deshechar los cambios)

Taller: Realizar algún cambio sobre algún archivo Deshechar el cambio


Procesix 2012


Resolver algunos conflictos

Con svn status -u se puede predecir conflictos. Pero hay que trabajar con esos conflictos.

$ svn updateU INSTALLG READMEConflict discovered in 'bar.c'.Select: (p) postpone, (df) diff-full, (e) edit, (h) help for more options:

Subversion marca el archivo como con conflicto y pregunta que quieres hacer con el problema.

Las mas comunes son posponer, diff-full, editar. Pero con h, se pueden ver todas las opciones.


Procesix 2012


Resolviendo conflictos manualmente

Suponemos que tenemos conflictos, cuando queremos editar el archivo aparece algo como:

Top piece of breadMayonnaiseLettuceTomatoProvolone<<<<<<< .mineSalamiMortadellaProsciutto=======SauerkrautGrilled Chicken>>>>>>> .r2Creole MustardBottom piece of bread

Los signos de menor que, igual y mayor que son marcadores de conflictos y no son parte de los datos en conflicto.

Se deben eliminar antes del commit.

Modificado por mi

Lo que viene del repo


Procesix 2012


Que opciones se tienen?

Descartar tus cambios y trabajar con lo que puso tu colega Solución mas sencilla. Comando revert a tus cambios y hacer un update

Mantener tus cambios y botar cualquier cosa que hizo tu colega

Sobreescribir localmente tu versión sobre la original y decirle a SVN que se resolvió el conflicto con el comando resolve

Realizar una mezcla manual de ambas versiones en una nueva versión

Editar el archivo original, removiendo las marcas >> y << . Despues se marca como resuelto el conflicto con el comando resolve

UPDATE – RESOLVER – CLEAR? - COMMIT


Procesix 2012


Resolviendo conflictos manualmente

El texto entre los 2 primeros marcadores se componen de los cambios que se hicieron en el área en conflicto.

<<<<<<< .mineSalamiMortadellaProsciutto=======

El texto entre el segundo y tercer conjunto de marcadores es el texto del commit del otro desarrollador.

=======SauerkrautGrilled Chicken>>>>>>> .r2

Obviamente, no se borran indiscriminadamente, se habla con el otro compañero y se resuelven los conflictos.

Después de esto se puede usar svn resolve


Procesix 2012


Confirmando los cambios.

Check in Operación básica para enviar los cambios al repositorio.

Cada vez que se hace check in de una nueva versión se obtiene una nueva revisión.

Tronco principal

Arroz ArrozHuevos

ArrozHuevos

Jugo

ArrozHuevosSopa


Procesix 2012


Confirmando los cambios

Se está listo para llevar los cambios al servidor. Comando svn commit. Envia todos los cambios al repositorio. Se requiere proveer un mensaje de log describiendo el cambio.

Si el log es corto se puede usar –m svn commit -m “Se corrigió un error“

Si se están haciendo mensajes de log en archivos como release changes, se utiliza la opción –F (--file).

svn commit -F logmsg


Procesix 2012



Duración del taller 1/2 hora

Desarrollo del taller En grupo de 2 El usuario 1 debe realizar los siguientes cambios en el proyecto en este

orden:

• Modificar el texto del archivo archivo3.txt en la línea 3.• Hacer commit del archivo.

El usuario 2 deber realizar los siguientes cambios en el proyecto:

• Modificar el texto del archivo archivo3.txt en la línea 3.• Resolver conflictos manualmente


Procesix 2012


Ignorar archivos y directorios

En muchos proyectos existen archivos y directorios que no deben ser puestos en control de versiones

Archivos de relleno Librerias de prueba Directorios de compilados

Para eso se deben ignorar este tipo de archivos al momento de hacer commit

Se usa la propiedad svn:ignore para el area especifica del proyecto

Taller: Ignorar el directorio de clases


Procesix 2012


Examinando el historial.

Subversion permite explorar la historia Examinando las versiones anteriores de archivos y directorios

svn log

• Muestra información general

svn diff

• Muestra detalle a nivel de línea de un cambio en particular.

svn cat

• Recupera un archivo que está en una revisión en particular.

svn list

• Muestra los archivos en un directorio en una revisión especifica.


Procesix 2012


Exportación

La exportación permite generar un release del código limpio

Sin los archivos y directorios de control de SVN

Útil para mantener versiones de código con lenguaje de scripting

No se puede exportar un solo archivo, se exporta todo el árbol

También sirve para limpiar la copia local Haciendo un export al directorio mismo


Procesix 2012


BRANCHING Y MERGING


Duración: 2 horas


Procesix 2012


Que es un Branch?

Situación: Supongamos que se está desarrollando una funcionalidad en un

software, pero se definió una nueva forma de hacerlo y se quiere evaluar si es posible usar esta nueva forma.

Cómo trabajamos con esta situación? Lo mas obvio es hacer una copia del proyecto y trabajar en

las dos copias separadamente. Los cambios se incorporan en una copia o en la otra. O se quiere hacer el mismo cambio en las dos copias.

Este es el concepto de Ramificación (Branch). Una línea de desarrollo que existe independientemente de otra línea Aun comparten una historia común si se remonta a algo lejano en el

tiempo.


Procesix 2012


Branches

Un branch es una línea de desarrollo distinta de la principal. Generalmente los desarrolladores trabajan sobre el trunk del proyecto,

pero en ciertas ocasiones puede ser útil crear una línea de desarrollo paralela, para esto se usa el término branch.

Situaciones en las que se usa un branch Querer comenzar el desarrollo de un nuevo producto a partir de una

versión del que tenemos para darle una orientación diferente. Para abordar un trabajo de mantenimiento u integración. Para atender peticiones de mejora o tareas concretas todo esto sobre

una versión especifica.


Procesix 2012


Cuando creamos ramas?

Depende de la cultura del proyecto No existe una política universal

Política “Nunca tener ramas” Proyectos nacientes que aun no tienen código ejecutable Los usuarios realizan commit diarios al tronco Ocasionalmente el tronco no compila, cuando hay una serie de cambios

“complejos” Pros: Muy fácil de seguir. No hay que aprender de ramas o merge. Cons: Desarrollo caótico, código inestable

Politica “Siempre tener ramas” Proyectos que tienen mantenimiento pesado Cada usuario crea/trabaja en su branch “privado” Cuando se completa el código, alguien revisa los branches y se hace el

merge al tronco Pros: Estabilidad del tronco Cons: Codificadores aislados, conflictos en el merge, trabajo extra.


Procesix 2012


Cuando creamos ramas?

Política “Ramas cuando se necesita” Los usuarios hacen commit diarios en el tronco Regla 1: El tronco debe compilar y pasar las pruebas de regresión. Los

codificadores que violen esta regla se “humillan” públicamente Regla 2: Un commit no puede ser tan grande que desaliente la revisión

de pares Regla 3: Si la regla 1 y 2 entran en conflicto (no es posible hacer la serie

de cambios pequeños sin alterar el tronco), entonces el usuario debe crear un branch y realizar los commit de los cambios en ese branch. Esto permite la revisión de pares sin alterar el tronco

Pros: Tronco estable. Hacer branches y merges es raro Cons: Adiciona una carga adicional al trabajo diario de los usuario, ellos

deben compilar y probar antes de cada commit


Procesix 2012


Taller branches con Subversion

Duración del taller 10 min

Desarrollo del taller Analizar las politicas de branching y establecer la adecuada para su

proyecto. Justificar la respuesta Socializar la respuesta


Procesix 2012


Solución con branches

Ejemplo: Imaginaremos que tenemos un proyecto con una línea de desarrollo

principal (sobre el trunk), y que en ciertos momentos algunas de las versiones (tags) que se marcaron pasaron al entorno de producción. Pero en un determinado momento se detecta un error critico o una tarea (por ejemplo cambiar la integración con otra aplicación) y hay que abordarla de forma rápida sobre la versión que hay en producción y sin pasar toda la nueva funcionalidad de las versiones que la siguieron y que no han pasado por un proceso de pruebas.

El equipo que desarrolla el proyecto debe de crear un branch sobre el tag que marca la versión que hay en producción y sobre la que se quiere implementar alguna tarea concreta.


Procesix 2012


Solución con branches

Para evitar que se repitan tareas en las distintas líneas, cada branch debe representar el desarrollo una tarea concreta para que se vuelva a integrar en la línea principal de desarrollo en poco tiempo, de esta manera la tarea de integración será menos costosa.

Existen casos en los cuales no se debe integrar el trabajo a la línea principal.

Cual caso?


Procesix 2012


Creación de Branches

Un branch es una COPIA!!! Es muy simple.

Se hace una copia del proyecto en el repositorio usando el comando svn copy.

Donde se ponga la copia, depende de lo que se desea. Si se opta por la política de un directorio llamado branches se debe

hacer el subdirectorio con el nombre de la rama.

Este comando causa un commit casi que instantáneo al repositorio.


Procesix 2012


Taller branches con Subversion

Duración del taller 10 min

Desarrollo del taller El archivo archivo3.txt tiene un problema en la linea 3, este debe ser

solucionado mientras que se implementan nuevas características sobre el archivo 3


Procesix 2012


GRACIAS!!!

1 copyright procesix inc. cualquier copia u otro uso debe ser autorizado expresamente por procesix...

Documents