Control de Versiones con Subversión Versión Desarrolladores/Usuarios Lenin David Lozano Argel Consultor Procesix Colombia Enero de 2012

Objetivos, Presentación 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

PREGUNTAS? Gracias!!!!

Control de Versiones Conceptos Básicos Ciclo estándar Agenda Control de Versiones Conceptos Básicos Copia de trabajo Repositorio … Ciclo estándar Branching y Merging Buenas practicas Eclipse

INTRODUCCIÓN A SUBVERSION Subversion para desarrolladores Duración: 1 hora

Llega un punto en el desarrollo de proyectos en el cual…. 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.

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

Es bueno trabajar con carpetas compartidas? 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.

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?

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

Bloquear puede causar problemas de gestión. 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.

No bloqueante (Copy – Modify – Merge) 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.

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 conflicto es 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!

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

TERMINOLOGIA Subversion para desarrolladores Duración: 1/2 hora

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.

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.

Es un directorio común en el sistema local. 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.

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.

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.

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.

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.

Conceptos Básicos Aprender la lengua SVN 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.

Taller sobre conceptos de subversion Duración del taller 15 minutos Desarrollo de la evaluación.

Gestión del repositorio Subversion para desarrolladores Duración: 1/2 hora

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.

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.

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 projectA Adding projectA/trunk

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

Socialización: 10 minutos 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

CICLO DE TRABAJO Subversion para desarrolladores Duración: 2 horas

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

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.

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

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 Arroz Huevos Jugo Arroz Huevos Sopa Check out Arroz Huevos Sopa Revertir Check in Copia Local

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

Taller Ciclo de Trabajo con Subversion Duración del taller 5 mins Desarrollo del taller Crear dos copias locales de trabajo del mismo proyecto con svn en dos directorios diferentes.

Checkout tímidos o directorios dispersos 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

Taller Ciclo de Trabajo con Subversion Duración del taller 5 mins Desarrollo del taller Hacer pruebas con los diferentes esquemas de checkout parciales Analizar los resultados

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……

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.

Taller Ciclo de Trabajo con Subversion Duración del taller 10 mins 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

Antes deshacer visibles los cambios al repo, se debe hacer revisión. 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.

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

Resolver algunos conflictos Con svn status -u se puede predecir conflictos. Pero hay que trabajar con esos conflictos. $ svn update U INSTALL G README Conflict 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.

Resolviendo conflictos manualmente Suponemos que tenemos conflictos, cuando queremos editar el archivo aparece algo como: Top piece of bread Mayonnaise Lettuce Tomato Provolone <<<<<<< .mine Salami Mortadella Prosciutto ======= Sauerkraut Grilled Chicken >>>>>>> .r2 Creole Mustard Bottom 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

Descartar tus cambios y trabajar con lo que puso tu colega 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

Resolviendo conflictos manualmente El texto entre los 2 primeros marcadores se componen de los cambios que se hicieron en el área en conflicto. <<<<<<< .mine Salami Mortadella Prosciutto ======= El texto entre el segundo y tercer conjunto de marcadores es el texto del commit del otro desarrollador. Sauerkraut Grilled 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

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 Arroz Huevos Arroz Huevos Jugo Arroz Huevos Sopa

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

Taller Ciclo de Trabajo con Subversion 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: Resolver conflictos manualmente

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

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.

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

BRANCHING Y MERGING Subversion para desarrolladores Duración: 2 horas

Este es el concepto de Ramificación (Branch). 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.

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.

Depende de la cultura del proyecto 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.

Política “Ramas cuando se necesita” 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

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

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.

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?

Este comando causa un commit casi que instantáneo al repositorio. 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.

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

GRACIAS!!!