SVN: Tagging y Branching

¿Qué son un Tag y un Branch de SVN? Ambos son creados inicialmente como copias del "trunk" de una carpeta SVN. Un Tag es simplemente una revisión SVN marcada especialmente, lo que nos permite darle un nombre más amigable que "revisión 901". Es por esto que es usual ir crear un tag cada vez que se publica una nueva versión del software, marcando la versión de los archivos en concordancia con el nombre del tag; un nombre esperable para un tag sería "Versión 3.2.0".

Por otro lado, un branch es una línea de desarrollo separada, y se usa en varios escenarios. Supongamos que queremos hacer un gran refactoring sin interferir con el trabajo del equipo, y queremos hacer commits a lo largo de nuestro trabajo porque es largo y complejo. Por lo tanto, creamos un branch como una copia del "trunk" (la línea principal de desarrollo) y trabajamos ahí. Cuando terminamos, hacemos un merge de nuestros cambios en el trunk, "reintegrando" el branch, que deja de existir al hacer eso.

Otro uso de los branches es aislar el trabajo de mantenimiento del de desarrollo. Supongamos que entregamos una versión inicial de varios de nuestros productos. Luego de eso, creamos un "branch de mantenimiento" para cada producto y seguimos trabajando en el trunk. Cuando nos llegan un reporte de bugs o pedido de nueva funcionalidad para un producto, pasamos a trabajar en el branch de ese producto. Hacemos lo mínimo necesario para resolver lo pedido, y una vez hecho y probado, hacemos un merge de los cambios hacia el trunk. Estos branches no son "reintegrados" al trunk como en el escenario anterior; existen mientras demos soporte para el producto asociado.

Para usar esta funcionalidad con Tortoise SVN, basta hacer click derecho a nuestra working copy, y seleccionar "Branch/Tag" en el menú contextual. Con "Tag", basta con elegir una revisión y definir el nombre del tag. Crear un branch es similar, con algunas opciones extra. Una vez creado el branch o el tag, con la opción "Switch" se puede llevar la working copy a un tag o branch específico. Es importante recordar que si se hace un switch a un tag, al intentar hacer un commit saltará un warning. Esto es porque, por convención, los tags se crean y no se tocan nunca más.

Para más detalles:

Comments

Post a Comment

Popular posts from this blog

VB.NET: Raise base class events from a derived class

Spanish version / Versión en Español Say we: Have a class we want to divide into subclasses The future base class has events The refactoring leads us to the need of raising an event declared in the base class, from a derived class. When we try to do point 3, we will get a compile error saying that a derived class cannot raise events from a base class. To get around this, we add a protected method in the base class which encapsulates the RaiseEvent call, and call that method from the derived class using MyBase. This way: In the base class (parameters as needed): Protected Overridable Sub OnMessageGenerated(ByVal NewSender As Object, ByVal NewMessage As String) RaiseEvent MessageGenerated(NewSender, New MessageEventArgs(NewMessage)) End Sub And in the derived class: 'Do stuff 'Raise base class event MyBase.OnMessageGenerated( Me, "Message" ) 'Do more stuff... References: Mark Gilbert post
Keep reading

Apache Kafka - I - High level architecture and concepts

Image
Spanish version / Versión en Español First of all, what is Apache Kafka ? An initial definition for it is "a high-throughput distributed messaging system". Breaking this down a bit: High throughput: One of the main goals of Kafka is to process as much messages per unit of time as possible, in a scalable and fault-tolerant way. For example, LinkedIn , which is where Kafka originated, needs to achieve throughputs in the order of 20 million messages per second and 3 GB of data per second. Distributed messaging system: In a generic distributed system , networked computers work together for a common goal. In Kafka's case, that goal is to send data from points A 1 , A 2 , ... A N , to B 1 , B 2 , ... B M . A common benefit of this kind of system, which is crucial to Kafka's success, is horizontal scalability : the ability to handle higher and higher volumes of data by adding nodes to the system (not to be confused with  vertical scalability , whic
Keep reading

Upgrading Lodash from 3.x to 4.x

Spanish version / Versión en Español There are many breaking changes from version 3.x to 4.x; all changes are detailed in the Lodash changelog . There is also a list of deprecated functions , with a regex you can use to detect usages in your code. However, since it is not an exhaustive list, I will list the changes I encountered when performing my own migration, to help anyone undergoing the same process. Direct renames This section includes functions in which only the name changed, i.e. the arguments and return value are the same. 3.x 4.x contains includes first head rest tail invoke invokeMap padLeft padStart padRight padEnd Direct renames if not using thisArg This section includes functions in which the only change is dropping "thisArg". If you are not using it, you can just rename. If you are using thisArg in 3.x, it can be dropped if you are using iteratee to acce
Keep reading