Tag Archive for 'branching'

Page 2 of 2

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.

WANdisco Announces Free Webinars for SVN Community

We hope you’re enjoying our bi-weekly free Subversion webinars! Thank you to everyone who has attended and sent us feedback on what they enjoyed, and what they’d like to see more of. Based on your feedback, we’ve devised another set of free training webinars for the Subversion community.

Here’s what’s coming up over the next couple of months (don’t forget, it’s free to register for any of our Apache Subversion webinars):

1) Hidden Subversion – get ahead of the game, as we share some tricks and techniques that many Subversion users aren’t even aware of.

2) Locking – we cover the Subversion Lock command in detail, including:

  • What is a lock?
  • How do you lock and unlock files?
  • Best practices for avoiding lock conflicts

3) Using Repository Browsers – drill down into the functionality of the Repo Browser, in this one-hour course.

4) Subversion Difference Command – get an overview of the various ways Subversion can compare files and generate meaningful reports.

5) Hook Scripts – these server-side executables can be used for a variety of tasks, including:

  • Automatic email notifications
  • Checkin content validation
  • Automatic backup
  • Specific access control

6) Introduction to uberSVN – an introductory webinar for uberSVN, the open ALM platform for Apache Subversion that’s easy to install, easy to use and easy to extend. This webinar will cover uberSVN’s core capabilities, including:

  • Installation and setup
  • Simplified repository creation and management
  • Team and user administration
  • Social coding capabilities
  • Extendibility with your favorite ALM tools

7) Access Control option with Subversion – need to control access to Apache Subversion repo information, but not sure which option is right for you? This session will weigh up the pros and cons of:

  • Subversion Access Control
  • Hook Scripts
  • uberSVN
  • …and more!

8 ) Branching and Merging – get an intro to the basic concepts of branching and merging, including when to perform a merge and create a branch, the different merge types, and some all-important best practices.

9) Subversion Properties – everything you need to know about SVN Properties! This one hour course will cover:

  • Defining properties
  • Property and “Standards and Procedures”
  • Property name rules
  • Automatic Properties
  • Recursively defining properties
  • ….and more!

Places are limited, so register now to avoid disappointment! And don’t forget to Contact Us if you have any comments, questions or suggestions for future webinars!

Introduction to Apache Subversion

What is Apache Subversion?

Subversion is an Apache-licensed, open source software versioning and version control system that can track changes to files, folders and directories. It can also be used to recover previous versions of data, and examine the history of how a particular dataset has changed. Subversion can operate across networks, encouraging collaboration by allowing team members at various locations to work on the same set of data. Subversion can be used to manage any collection of files – web pages, binaries, documentation – not just source code!

Downloading and Installing Apache Subversion

Certified open source Apache Subversion binaries are available to download from http://www.wandisco.com/subversion/download

To install, open the file to launch the setup wizard and follow the onscreen instructions to define which components you wish to install, and the install location. Enter the name of your server, the host port, and define the repository and repository location prefix – and hit install.

Alternatively, uberSVN makes Subversion easy and intuitive to use, and is free to download and free to use.

Creating your first repository

Once Subversion is installed, the first thing you need to do is create a repository. To create your first repository, open the command line, change the current directory to where you want to create your repository, and run the ‘svnadmin’ command:

svnadmin create {directory name}

Checking out a Project

To start working on your project, you must check out a working copy of the repository. This is achieved with the ‘checkout’ command:

svn checkout file {file location}

Commit Your Changes

Once you’ve made some changes to your working copy, you’ll want to push your changes to the server. Perform an “svn update” and an “svn diff” to test your changes, and resolve any warnings raised by Subversion, before committing. Once you’ve finished checking your modifications, and are ready to store the new revision in the repository, run the ‘commit’ command:

svn commit {path}

Get other people’s changes

When someone else performs a commit to the repository, you’ll need to pull those changes into your working copy, to ensure the latest trunk changes are compatible with what you’re doing in your working copy. Changes can be pulled into your working copy with the update command:

svn update {file name}
or
svn update {directory name}

Adding Files to a Project

Now you know how to checkout a working copy and commit changes back to the repository – but as you continue to develop your working copy, you may wish to add some new files to your project. When adding new files to Subversion, you need to tell the Subversion server about the files with the following command:

svn add {file name}
or
svn add {directory name}

Note that the new files won’t appear in the repository until you perform an ‘svn commit’ and send them to the repository.

Deleting Files from a Project

If at some point you want to remove these files from Subversion, run the delete command:

svn delete {file name}
or
svn delete {directory name}

Again, you must perform a commit before the file is deleted from the repository. You can also run ‘svn list’ to confirm that the file was successfully deleted from the repository.

And if you get stuck…..

The ‘svn –help’ function provides a summary of available commands or, for more information on a particular command, use:

svn help {command}

Other useful commands

  • svn status {path} – prints the status of working copy files and directories.
  • svn diff – display the differences between two revisions.
  • svn merge – applies the differences between two sources to a working copy path.
  • svn move SRC DST – think of this as ‘svn copy’ that automatically deletes the source file. This command moves a file or directory in your working copy, or in the repository. Note that Subversion does not support cross-repository moving, so it is impossible to move files across repositories with this command.
  • svn list – allows you to view the content of the Subversion repository, without having to download a working copy.
  • svn log – Subversion remembers every change made to your files and directories. This command displays the commit log messages. By default, it will show the information for the current working directory of your working copy. Alternatively, different paths can be specified.

Need more info?

On June 14th, 2012 we will be hosting a free ‘Introduction to Subversion’ webinar. This course is intended as a primer for new users or people who are thinking of making the jump to Subversion, and will cover the following topics:

  • Repository basics – creating and organizing
  • Checkouts, working folders, editing files and checkins
  • Reporting on changes
  • Simple branching
  • Simple merging

This webinar is free to attend, but places are limited so register now to avoid disappointment.

Subversion Live: Back for 2012

We’re pleased to announce that, after getting a great response from the Apache Subversion community in 2011, Subversion Live is back for 2012!

Last year, Subversion Live brought the Apache Subversion community sessions covering everything from SVN’s future, to expert-led best practices workshops focused on getting the most out of Subversion, and a unique ‘Roundtable with the Committers’ session.

This year’s conference will take place in San Francisco, Greenwich and London during October. The core Apache Subversion committers will be in attendance, including director of the Apache Software Foundation, Greg Stein, and Apache Subversion Release Manager Hyrum Wright.

Confirmed sessions include:

  • What’s coming in 1.8 with Hyrum Wright, Stefan Fuhrmann, Julian Foad and Philip Martin
  • New Developments in SVN clients
  • Best Practices for Large SVN Deployments
  • Subversion Server Tuning Demo
  • Merge & Performance Improvements
  • Branching & Merging Best Practices
  • Hook Scripts
  • …and more!

Registration for Subversion Live will be opening soon! Be sure to follow @WANdisco and @uberSVN for all the latest, breaking news on Subversion Live 2012.

Even More Free Subversion Webinars

We hope you’re enjoying our bi-weekly free Subversion webinars! After getting a great response from the community, we’ve announced the next few webinars in the series, including another webinar on branching and merging, as so many of you requested!

Here’s what’s coming up over the next few months:

  • Checkout Command – Although checkout is the most frequently used Subversion command, it has many options that few users are aware of. During this session, attendees will learn how to make full use of the checkout command and understand the messages it generates under different scenarios.
  • TortoiseSVN 1.7 New Features – Attend this webinar to learn all about the latest changes and get the most out of TortoiseSVN 1.7.
  • All About the Subversion Commit Command – Take a closer look at the Subversion commit command, including commit dialog options, unversioned files, changelists, and common problems and how to avoid them.
  • Introduction to Subversion – Back to basics! This course is intended as a primer for both new users and people who are thinking of making the jump to Subversion.
  • Version Control using Subversion – Learn a little more about the how and why we use version control; we will point out the advantages of version control, using SVN as an example.
  • Advanced Branching and Merging – This webinar will cover the meaning of merge messages, analyzing branches using revision graphs, using svn:mergeinfo and the different merge types (reintegrating a branch, merging a range of revisions, and merging two different trees.)

All these webinars are free, but places are limited. Register now to avoid disappointment.

Best Practices for Merging in Subversion

A quick Google search will uncover countless tales of merge hell in Subversion but, when used correctly, branching and merging can be an invaluable tool for the Subversion developer. Essentially, a merge takes the differences between two separate revisions and applies them to the working copy path, using various invocations of the svn merge command. A merge never creates a new version, it always modifies a workfile, which is created by the merge and is then edited before the changes are committed back to the repository. Things do get a bit more complicated when conflicts occur during merging. Whenever two or more people have modified the same code, Subversion will flag up any conflicts when you attempt to merge.

While you’re not forced to resolve these conflicts immediately, you will be unable to commit your changes to the repository until all the conflicts have been resolved.

Merging is a crucial function for getting the most out of Subversion. Here are our ten tips, to help you avoid living through your own merge horror story:

1) Project partitioning – consider assigning bugs to team members based on the location of those bugs. This reduces the chances of different people modifying the same files, at the same time.

2) If confused, start over – if you make any errors (e.g you’ve merged the wrong working folder) you can always start over. The ‘Revert’ command will discard all changes.

3) Always start with a checkout or an update – always have the latest code from the trunk before you start resolving any conflicts, so make sure you have just performed a checkout or an update. If you’ve made changes to the working folder before you start the merge, it makes sense to commit that back to the repository, so you have a new revision of what the code looked like before you started your merge.

4) 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.

5) Use appropriate log messages – make it easy for people to go in later and find out what merges happened, what changes were made, etc. The more information you provide, the easier it will be two months later when someone asks whether the changes from a particular branch were ever incorporated into trunk development.

6) 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.

7) Isolate the merge – sometimes, it’s tempting to merge some changes and then add additional planned development before performing a commit. Try to avoid this, as it makes it difficult to separate which changes came from the merge, and which changes were made as part of the rest of the development.

8 ) Don’t become too isolated – 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. To avoid this, you should regularly replicate changes being made within the trunk, into your own branch, just to ensure they fit with your own changes.

9) Use commands – Subversion has some commands to help take the hassle out of merging. These include:

a) svn:mergeinfo – displays the history of merges made into a particular file or directory.

b) –dry-run – previews status codes that would be printed in a real merge, without actually applying any local changes to the working copy.

c) svn log – a svn log command on the /branches URL will display the entire history of a branch – even if a successfully merged branch is no longer visible in the /branches directory, it’s still a part of the repository’s history.

10) ….And don’t panic! – conflicts happen much less frequently than you would think. Whenever different team members can access the same files, there’s going to be occasional conflicts, but Subversion is a great tool for rectifying these conflicts when they do occur.

For more tips on merging, check out our free-to-download ‘Introduction to Branching and Merging’ and ‘Advanced Branching and Merging’ cheat sheets.

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.

The Work Begins

As many reading this may already be aware, WANdisco has announced our intentions to focus our efforts towards continued enhancements to Subversion’s support for branching and merging. As our committers can see the end in sight for their efforts on Subversion 1.7, we are beginning to decide where next to direct our energy.

There already exists a wealth of data in various locations inside and outside of the project that capture good ideas for continuing the improvements to merging in Subversion. What we are not looking to do is to come up with many more ideas on the topic. Instead, we want to review and prioritize what is already out there and  then decide where we can best apply our resources for biggest benefit to the Subversion community.

The work we are doing now is to review the issues, capture the use cases and then do the hard work of applying our committers expertise towards resolving these issues. This process will very likely be incremental. Delivering new enhancements will provide benefits for many of us but it also allows for a new feedback loop to show us what remains to be done and where the most benefits lie for the next set of efforts. What we won’t be doing is trying to do something grandiose that could result in elongated development cycles and delayed delivery of some solutions.

The work has really just begun. We’re now rolling up our sleeves and diving into the work.  It should be fun!

I am planning to blog regularly about the process – your feedback is always welcome.

– Rob

avatar

About rbudas

Rob Budas has over 25 years of software industry experience, with the last 15 years focused on the Software Configuration Management sector. Prior to joining WANdisco, Rob had worked at IBM Rational for 8 years where he was a Sr. Product Manager for Rational ClearCase. He has held various development, technical sales and product management roles throughout his career. Rob holds a Bachelor of Science in Computer and Communication Science from the University of Michigan.