Tag Archive for 'branch'

Page 2 of 2

Branching in Apache Subversion Made Easy

Branching is a powerful and useful feature of Apache Subversion but, because it has a reputation for being difficult to master, many users never take advantage of it. In this post we’ll show you how to create a new branch, and then switch to this branch ready to begin working on its contents.

Creating a Branch in 5 Steps

1) To get started, right click on the folder you want to copy to a branch, and select the ‘Branch/Tag’ option from the TortoiseSVN menu.










2) In the ‘To path’ box, enter the location you want your branch to be copied to.

3) Enter a log message in the ‘Log message’ box.

4) Select which revision you wish to copy (this is typically HEAD revision, but you can specify another revision, if required.)

5) Click ‘OK.’










You have now created your branch!






3 Steps to Switch to Your New Branch

Now you’ve created a new branch, you’ll need to switch to it in order to begin working on its contents.

1) Right-click on the top level folder of your project and select ‘Switch’ from the TortoiseSVN context menu.

2) Enter the URL of the new branch you just created.

3) Ensure the ‘Head Revision’ button is selected, and click ‘Ok.’







The new branch will appear in your working copy!

Note, any changes that have not been committed to the repository will be merged when you run the switch command. Make sure you’ve either committed your changes before performing the switch, or revert your working copy to a revision that has already been committed to the repository.

Need more Subversion know-how? After getting a great response from the Apache Subversion community in 2011, Subversion Live is back for 2012, bringing the Subversion community sessions covering everything from Subversion’s future, to expert-led best practices workshops, as well as the unique opportunity to meet the core Subversion committers.

Getting Started with Apache Subversion

As the world’s most popular version control system, Apache Subversion has plenty to offer newcomers:

1. It’s an established project – accepted into the Apache Incubator in 2009 and graduating a year later, today Subversion is an Apache Top Level Project maintained by a global community of contributors.

2. Rich ecosystem – Apache Subversion users have access to countless free client tools, GUIs and plugins developed by the community. SVN also integrates with most of the major IDEs, including Eclipse and Microsoft Visual Studio.

3. Free Community Support – Have a question about Subversion? There’s no shortage of mailing lists and forums (including SVNForum.) In many cases, your question will have already been asked (and answered) by someone else. If you can’t find the answer, you can always post it yourself and the community will be happy to help you out.

4. Professional Support – Subversion has a great community of users who are always willing to answer queries, but mailing lists and forums aren’t always the ideal place to reach out to when disaster strikes your enterprise deployment. At WANdisco, we offer professional support services for Subversion, that includes 24-by-7 worldwide coverage, guaranteed response times, and indemnification coverage, for those who need that added security.

5. Powerful branching and merging functionality – Branching and merging can be a pain-point for Apache Subversion users but, used correctly, branching and merging can be Subversion’s greatest strength. We have some free branching and merging refcards, to help you master these potentially tricky issues.

Apache Subversion has plenty to offer users, but if you’re new to SVN – or even version control in general! – it can be difficult to know where to start. To help newcomers get off to a flying start with Subversion, we’ve just released a ‘Getting Started with Subversion’ refcard. This refcard covers all the essential information you need to get going with Subversion, including what Subversion actually is, the basic work cycle you can expect to encounter, and an installation guide. It then demonstrates how to create your first repository and covers the essential commands – svn checkout and svn commit.

Getting Started with Subversion’ is free to download. We’ll be adding more refcards in the coming weeks, so keep checking back for all the latest Free Training Content.

Subversion Tip of the Week

Branching and Merging Best Practices

For those unfamiliar with version control, branching and merging in Apache Subversion can be a daunting prospect. But when used correctly, branching and merging can be one of the most powerful tools at your disposal. Here are some tips for avoiding merge hell – and those dreaded conflicts!

  • Isolate the merge – when performing a merge, do not add any additional planned development before performing the merge. This will make it difficult to distinguish where changes originated, and can cause major headaches if the team decides to roll back to previous revisions.
  • Use log messages – leave as much information as possible in your log messages (e.g what changes were made, why, and by whom, etc.) Log messages can be an invaluable source of information, if you need to revisit a particular revision at a later date. TortoiseSVN comes with functionality for ensuring that all team members leave appropriate log messages, including ‘Properties’ that are specific to TortoiseSVN. In this example, we’ll cover the ‘tsvn:logminsize’ property:

1) Select the properties option from the TortoiseSVN menu; this will bring up the properties dialog. Select ‘New’ property and click ‘Log sizes.’

2) You can now set the minimum number of characters for a commit message. TortoiseSVN will then block any commits with a log message shorter than the characters specified.

  • Use branches for new features and major bugs – this allows new features/bugs to be worked on immediately, regardless of the work currently underway in the trunk, or in neighbouring branches.
  • Delete unwanted branches – branches that are no longer required should be deleted. Note, deleting branches will have no effect on repository size, as the item will only be removed from the revision in question, and all subsequent revisions. It will still exist in all previous revisions, and can be viewed or recovered at any time.
  • Merge on logical checkpoints – in most cases, it makes sense to merge when the ‘from’ part of the merge (i.e the branch you’ve been working on) has reached the level of quality where changes are testable and compilable. Do not merge anytime an experimental new change has been made to the branch.
  • Merge soon – fix conflicts as soon as possible. The quicker you resolve conflicts and commit those changes back to the repository, the sooner the rest of your team can take your changes into account when working on their own part of the development effort.
  • If confused, start over – if you make any errors (for example, you’ve merged the wrong working folder) you can always start over. Simply right-click on your working copy and select ‘Revert’ to discard all local changes.

Need more Subversion know-how? After getting a great response from the Apache Subversion community in 2011, Subversion Live is back for 2012, bringing the Subversion community sessions covering everything from Subversion’s future, to expert-led best practices workshops, as well as the unique opportunity to meet the core Subversion committers.

WANdisco Releases Subversion ‘Branching and Merging’ Refcards

Branching and merging can be a pain-point for Apache Subversion users but when used correctly, they become an invaluable tool for getting the most out of version control. Not sure where to start with your branching and merging strategy? Our brand new refcards have all the info you need to get to grips with branching and merging.

‘Introduction to Merging in Apache Subversion’

Merging doesn’t need to be frightening! ‘Introduction to Merging in Apache Subversion’ starts with the basic question of ‘what is merging,’ before showing you how to perform the different types of merges, including reverse merges, and finally sharing some best practices to help you avoid merge hell.

This refcard covers:

  • What is ‘Merging’?
  • How to Merge in Subversion:
  • – Merge a Range of Revisions
    – Reintegrate a Branch
    – Merge Two Different Trees

  • Reverse Merge
  • Merging Feature Branches
  • Merging Best Practices

‘Introduction to Branching in Apache Subversion’

Introduction to Branching in Apache Subversion’ covers the essential know-how you need to get started with branching in Subversion, including:

  • What is a Branch?
  • How to Create a Branch
  • Identifying Branches
  • Deleting Branches

We’ll be adding more refcards over the coming weeks, so keep checking back for even more free training content. We also run frequent free webinars for the Apache Subversion community, more info is available at the Free Training Webinars page.

Deleting Branches in Subversion

In Apache Subversion, it’s easy to create new branches to the point where they become confusing. To simplify things, branches can be typically divided into two categories:

Permanent – you may want to store certain folders or projects in permanent branches, e.g copies of released code stored in tagged branches.

Temporary – can be used to test new technology or experiment with new features. Temporary branches should have a defined lifetime, and at the end of that lifetime they should be deleted. It is good practice to label a branch as temporary in the accompanying log message, and to note who is responsible for deleting that branch.

To delete a branch, simply:

  • Select the branch you wish to delete.
  • Right-click and select the ‘delete’ command.

There are several reasons why you might delete a branch:

1) House-keeping – regularly deleting branches helps to reduce the clutter in the branches directory, and to avoid confusion for anyone browsing the repository, who might expect to find ongoing development in abandoned branches. When all abandoned branches are routinely deleted, a glance at the branches directory can tell you which branches are still active.
2) Following a merge – when you’ve finished all the work in a branch and merged the changes back to the trunk, the branch becomes completely redundant and can be deleted.
3) Following reintegration – the ‘–reintegrate’ command option allows Subversion to merge from a branch to the trunk, by replicating only the changes that are unique to the branch. Subversion achieves this by comparing the latest trunk with the latest branch, and applying the resulting difference to the trunk. This is useful in a number of situations, including when all the changes made within the trunk have been ported to the branch, so the only difference is the branch changes. A ‘–reintegrate’ merge uses Subversion’s merge-tracking features to calculate the correct revision ranges to use, and checks to ensure the branch is truly up-to-date with the latest changes in the trunk. These checks ensure the reintegration will not overwrite work other team members have committed to the trunk.

Once a ‘–reintegration’ merge has been performed, the branch shouldn’t be used for development, as any future reintegration will be interpreted as a trunk change by Subversion’s merge tracking, and it will attempt to merge the branch-to-trunk merge back into the branch. The reintegrated branch should therefore be deleted, and if you wish to continue working on the branch, you should re-create it from the trunk.

Recovering Deleted Branches

Deleting branches in Subversion does not completely remove them from the repository; it just removes them from the HEAD revision. You can always go back to an earlier revision to view and recapture the branch, or the files that were in that branch. Useful commands for revisiting deleted branches, include:

  • svn log –verbose – run this in the directory that used to contain the deleted item. –verbose displays a list of all the changed items in each revision, allowing you to locate the exact revision where you deleted the desired file or directory.
  • svn merge -r – can be used to roll back a change that has already been committed. ‘svn merge -r’ merges the changes from your current revision back to a revision with the changes you wish to revert to. Rolling back a change is like any other svn merge operation, so ‘svn status’ and ‘svn diff’ should be employed to approve the changes. Since the merge happens at the local working copy level, you need to use ‘svn commit’ to send the final version to the repository.
  • svn checkout –revision (number) – checks out a particular deleted branch.
  • svn switch – updates the working copy to a different URL, typically one that shares a common ancestor with the current working copy.
  • svn revert filename – rolls back local changes, on the local working copy only.

Alternatives to Deleting

If you do not wish to delete branches, there are some alternatives commonly employed by developers:

  • create an ‘inactive’ folder and move your unneeded branches to that folder.
  • rename the branches to show they are inactive.

Busy Developer’s Guide to Subversion Best Practices

Need some quick tips on Subversion best practices, covering everything from structuring your repository, to avoiding merge hell, and advice on testing? In this post, we share some rapid-fire advice for busy developers who need to get the most out of Subversion straight away.

Repository Structure

Subversion gives users the freedom to structure their repository according to a project’s particular needs, but if you don’t implement a logical project layout, you’re running the risk of creating an administrative nightmare. Here are some general rules worth bearing in mind when creating a new Subversion repository, to ensure all that freedom doesn’t lead to complications!

  • The trunk shouldn’t break – the trunk should always be stable, and should always compile. To ensure the trunk doesn’t break, all risky development should be confined to the branches, and CI and automated regression testing should also be considered, to ensure there is no regression in the trunk.
  • Use tags – tags should be used to make snapshots of your project at certain points along the development process (e.g tagging a copy of ‘Release 1.0’.) It can also be useful to make snapshots of your code before implementing major new features, in case you need to roll back to before a feature was introduced.
  • Working copies should always be checked out from the top level of the branch/trunk – i.e /trunk or /branches/(branch name)
  • The root directory of the working copy should be named after the branch that it is checked out from (e.g “ProjectA”)
  • Make structural changes to the trunk – structural changes to the repository (directory or file renaming, and directory or file deletion) should always be performed on the trunk, at a time when there are no outstanding branches waiting to be merged. This can help teams avoid serious merge conflicts.

Want more advice on setting up your repository? For more information, see our post Subversion Best Practices: Repository Structure

Branching & Merging

Branching and merging can be a pain-point for Subversion users, but when used correctly, branching and merging is one of the most powerful tools at your disposal. Here are some tips for avoiding merge hell – and that dreaded merge conflict!

  • Make use of log messages – when performing merges, it is good practice to leave as much information in the log message as possible (what changes were made, why, and by whom, etc.) Remember, the more information you provide, the easier it will be months down the line, when you need to find out if a particular branch was ever incorporated into the trunk.
  • One thing at a time – when performing a merge, it is important to isolate the merge (i.e only make changes that are necessary to resolve the conflict) – do not add any additional planned development before performing the commit. Likewise, do not commit unrelated code changes in the same commit (i.e two bug fixes in one commit). Both of these actions make it difficult to distinguish where changes originated from, and can cause major headaches if the team decides to roll back to a particular revision.
  • Use branches – branches should be created for new features and major bugs. Bug fix branches are particularly useful, as they allow bugs to be worked on immediately, regardless of the work underway in the trunk, or in neighbouring branches.
  • Use ‘svn update’ – branches should be kept up to date with changes committed to the trunk, by regularly running ‘svn update’. Even if it seems your changes have little to do with the rest of the team, by the time you’ve finished perfecting your branch, the trunk may have evolved to the point that it’s a nightmare to merge your changes.
    It is good practice to also run ‘svn update’ on the working copy before you begin making any changes. This ensures that your working copy is up to date with the latest version in the repository.
  • Commit often – commit small changes frequently, as oppose to committing many small changes in one large chunk. This will help reduce the chances of encountering merge conflicts, and will help reduce the complexity of conflicts that do occur.
  • Delete unwanted branches – branches that are no longer required can be deleted. There are several reasons why you may decide to delete a branch, but the main ones are:

    – To reduce clutter.
    – A successful merge has been performed, and the branch is now redundant.
    – A successful reintegration merge has been performed, and any future reintegration of that branch will confuse Subversion’s merge tracking capabilities.

Branches should not be deleted to reduce the repository size, as deleting branches does not actually remove them from the repository, it just removes them from the HEAD revision.

For even more information on branching and merging, check our out blog on Best Practices for Merging in Subversion


And lastly, test everything! Get into the habit of systematically testing every feature and bug fix implemented after merging, and consider CI and assertion testing on feature branches, which are useful for indicating code maturity and progress. As a minimum, automated regression testing should occur on the build of the feature branch.

Where Did That Branch Go?

When teaching “Subversion User” classes, one of the frequently asked questions is “When do you delete a branch?”

Unfortunately the reason they are asking about deleting branches is because they are concerned with saving space. And as all experienced SVNers know, deleting will have no effect on repository size. Remember, when anything is deleted in Subversion, whether it is a project (folder), a file or a property, it is only deleted in the revision where it is deleted, and subsequent revisions. It still exists in all previous revisions and can be viewed or recovered at any time.

So the question remains. “When, or why would you ever delete a project?”

First let’s look at the cases when you would NEVER delete a branch:

1) Some branches are always needed such as the “trunk” or branches that contain other branches like the folders “tags”, and “branches”. This assumes you are using the TTB layout format.
2) Some branches are referenced frequently. The branches in the “tags” folders that hold your recently released versions are used to create releasable code and compare to current trunk development efforts repeatedly.
3) Branches where concurrent development is taking place. Before the branch is merged back to the trunk (or wherever it was branched from) it would be confusing to delete the branch. It might also lead to someone forgetting to do the merge.

So that leaves us with the following types of branches that MAY be candidates for deletion.

1) Abandoned work efforts. For example, you may start a branch to do concurrent development, and later decide to do the work in the trunk. What do you do with the abandoned branch?
2) Branches that represent old versions of your code. Let’s be realistic, if you are on Release 5.6.004 you may go back to Release 5.6.003 or Release 5.5.012. But how likely is it you are going to need to reference Release 1.0.01 from 4 years ago.
3) Mistakes created when using the COPY command. You meant to create a Release branch from revision 1255 of the trunk and you mistakenly selected the revision 1250.

All three of these are good examples of when you might do a deletion. But if you are going to do a deletion you should have some rules. And these rules should be part of your organization’s “Policies and Procedures”. (We actually spend considerable time in the “WANdisco Subversion Administration Class” talking about the contents and importance of Subversion Policies and procedures.)

Rule 1) Always use the log message to document that a deletion has been done and why. There is a new TortoiseSVN property (tsvn:logtemplatedelete) that provides your users with a template of the information you might want them to fill out. To see a demonstration of this property in use, see this short video. http://www.youtube.com/watch?v=foNQME4rcVQ

Rule 2) (optional) Instead of deleting folders, move them to a folder called “Deleted”. This makes the “deleted” branches/folders easier to find and recover.
Rule 3) Make sure everyone knows how to restore deleted folders/branches.

The best reason to delete any file or folder from a Subversion project is to make the viewing of the rest of the project easier. The less information you have to look at, the more likely you WON’T checkout a branch incorrectly or use the difference command with the wrong branch. Both of these actions might waste your time or create some sort of error that could go unnoticed.

What Do ‘Trunk,’ ‘Branch’ and ‘Tag’ Really Mean?

‘Trunk,’ ‘tags’ and ‘branches’ are common conventions in Subversion, and most Subversion projects employ them in some shape or form, but there’s often some confusion surrounding these concepts. Essentially, ‘trunk,’ ‘tags’ and ‘branch’ all refer to directories in Subversion, but they’re used to distinguish how users handle these directories. Subversion doesn’t force you to organize your project into trunk, tags and branches, but arranging your data in this conventional format allows you to access the wealth of Subversion tutorials and guidelines online – and, of course, it makes it easier to reach out to the community for help if you get stuck! In this post, we provide a quick introduction to the trunk, tags and branches conventions, alongside some practical advice for getting the most out of these conventions.


The trunk is the main line of development in a Subversion repository. It contains the main codebase and is always stable. In the early days of a project, there will be little need for branches and tags, as you will spend most of your time making changes and committing them back to the trunk of your repository.


The Subversion repository remembers every change written to it. This allows the client to read the latest version of the filesystem tree, but also to view the previous states of the filesystem. Users can tag certain revisions of the repository with more human-readable file names (e.g “release-2.0”) for easy reference. In this scenario, if you ever need to look at the source code for version 2.0 again, you can easily locate the tagged file and pull the code back out.


Branching is a line of development that exists independently of another line. Branches allow developers to work on code independently of the work going on in the trunk. Branches can be made either from:

The working copy:

  • right-click on your working project and select branch/tag.
  • specify where you want the information to go.
  • add a log message to explain why you’re creating this branch.

The repository:

  • from within the repository browser, select where you want to branch from and right-click
  • select the ‘copy-to’ command
  • specify the name of the new branch and the location where the branch should be created
  • add an optional log message to describe why you’re creating this branch

So, when should you branch? Every project is slightly different, but there are some common reasons to create a branch:

1) Concurrent development branch: When performing concurrent development, to isolate development. This is the most common reason to create a branch.
2) Release branch: To tag a project and keep track of released code. Upon completing a release, the development team create a branch and tag it with a name that is meaningful to that release (e.g “release-2.0”) This provides an identifiable record of how the released code looks.
3) Experimental branch: To test a new technology that may not necessarily become a part of the main branch. If the experiment works out, the new code can always be merged into the trunk.
4) Custom branch: When modifying the code for a customer’s particular need.

You would not normally create a branch for small changes, and do not normally branch from the tags folder, as the tag folder specifies what a release looks like at a certain point in time, and branching from that folder can lead to confusion.

Ready to get started with Subversion? Binaries of the latest Apache Subversion releases can be downloaded from the WANdisco website now.

Branching Options for Development

Branching and merging is a contentious issue for the Subversion community, with even the most experienced Subversion users sometimes needing extra guidance on how best to manage their branches. In our latest webinar, Michael Lester, WANdisco’s Director of Training, provided an introduction to branching and merging which ranged from the basic, ‘what is a branch?’ question, to the different development models open to Subversion users, and advice on managing deleted branches.

Essentially, a branch is a line of development that exists independently of another line. Branches allow developers to work on code independently of the work going on in the trunk. No changes made within a branch are seen by people working in the trunk, or in any other branches. There’s no real limit on the number of branches that can be created, but there are some general development models for branching that Michael addressed in the webinar:

1) “Branching Nothing” Development Model

In this model, all of the development is done within the trunk. In ideal circumstances, all of the checkouts and commits will be in line, and no-one will check out the same thing at the same time, but it’s likely there will eventually be a situation where multiple people checkout the same code simultaneously, and then it becomes a race to see who can make their commit first. The second person to make their commit will receive a message alerting them that their commit has failed, and that they must update their working copy.

‘Updating the working copy’ takes the differences between what was checked out and edited, and what the other person has modified, and applies it to the working files. In the best case scenario, this is a straightforward update, but in some cases it can create a conflict situation.

The branching nothing model can create ‘update hesitation,’ where the developers are aware that performing a commit could force them to go back and deal with other peoples’ changes – a potentially time-consuming and annoying process! – which encourages them to wait until the last minute to make their commit. The branching nothing development model tends to get more complicated, the more people who are working on the same code, at the same time.

2) “Branch Everything” Development Model

With this development model, every change within a project is given its own branch; either a ‘bug branch’ or an ‘enhancement branch.’ People are assigned to work on a particular branch, and these branches are then merged into the trunk. This has a number of advantages:

  • All work is isolated. You don’t have to worry about other changes interfering with yours until the merge happens.
  • All work is scheduled. There is a defined branch for everything that needs to be worked on.
  • All work is branched from a stable trunk revision.
  • Small, independent merges mean it’s usually easier to resolve changes.

However, there are also some disadvantages to this development model:

  • Lots of branches.
  • Lots of merges.
  • A lot of overhead for some very straightforward fixes, e.g the misspelling of a word, or a column heading not being centered.

3) “Branch Big Things” Development Model

With this development model, every task is divided into one of two categories:

  • A small development effort – worked on directly in the trunk, with no branching or merging required!
  • A big development effort – tasks such as a complicated bug or enhancement are given their own branch.

This categorisation is based on:

  • Relationship to other bugs / enhancements – is the change likely to impact any other code?
  • How much testing is required? – some changes may require virtually no testing (e.g correcting a misspelt word) but other times you will literally have to do system-level testing to ensure the changes haven’t had any unforeseen negative effects.
  • How long will the bug/enhancement take?

Deleting Branches & Finding Deleted Branches

Regardless of whether you branch everything, or follow the ‘branch big things’ development model, if you’re going to branch, then at some point you’ll have to delete some of the old branches. Deleting branches is simply a matter of:

1) Go to the repo browser.
2) Right click on the branch you want to delete.
3) Select the delete command.

Remember that when you delete a branch, it gets deleted from the revision folder but not from the repository. You can always go back to an earlier revision to see how the branch looked, and have the option of exporting the code from the deleted branch, or recovering the branch and recreating it in a later revision.

To make it easier to locate a deleted branch, it is a often a good idea to write something in the log message upon deleting that branch. Another good idea, is to create a ‘deleted branch’ folder, where you can store branches that you no longer need.

Need more advice on branching and merging? The full webinar is available for replay now. Our next webinar, ‘uberSVN: Access Control Management’ will show you how to quickly setup access control for Subversion users and how to easily create repository access rules, allocate users to teams, and monitor team activities. The webinar will take place on October 27th, 2011.