SVN: Tagging and Branching

What are "branches" and "tags" when we're talking about SVN? A tag is simply a specially marked revision: it allows us to give a revision a friendlier name than, say, "revision 901". This is why tags are usually associated to a new release of our product. For this reason, it's common practice to create a tag each time a new version of the software is released, setting the file versions in concordance with the tag name. For instance, a normal name for a tag would be "Version 3.2.0".

On the other hand, a branch is a separate line of development, and it can be used in various scenarios. Say we need to do a major refactoring without breaking our colleagues' solution, and we need to commit along the way because work will be long and complex. So we create a branch, as a copy of the "trunk" (the main development line), and work there. When we're done, we merge our changes back into the trunk. When we do that, we say the branch is "reintegrated" into the trunk and stops existing.

Another usage of branches is isolating maintenance work. Say we release an initial version of some of our products. After that, we create a "maintenance branch" for each of them and keep working on the trunk. When our customers report bugs or request new functionality, we switch to working on the product branch and do only what our client requested and nothing else. Once we're done, we merge the branch's changes back into the trunk and go back to working on the trunk. These branches are not "reintegrated" as in the previous scenario; they exist as long as we offer support for our products.

To use these features in TortoiseSVN, just right-click the working copy and select the "Branch/Tag" option. For "Tag", selecting a revision and defining the tag name is enough. In the "Tag" case, the workflow is similar, with some extra options. Once the tag or branch is created, it is possible to use the "Switch" option to take our working copy to a specific tag or branch. It's important to remember that after switching to a tag, trying to perform a commit will trigger a warning. This is due to the fact that, by convention, tags are created and never changed again.

For more details:

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