Tag Archive for 'merging'

Page 2 of 2

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.

Our Initial Thoughts

Where did February go?  As a resident of Massachusetts, parts of me (namely my back, shoulders and arms) are quite happy to see those weeks get crossed off the calendar.  Since my last posting here, I’ve not only been shoveling snow though.   Two separate Subversion Live events were held,first in San Jose and then two weeks later in London.

Both days were extremely fruitful for those of us from WANdisco that attended and I hope our attendees felt the same way.   The presentations in the various tracks were well attended, very professional and well received. A great source of information exchange was the roundtable sessions at the conclusion of each day. But what I always find most useful at events like this are the less formal conversations that occur prior to a session, or during a break, or over lunch.  Not surprisingly, inquiries about what our committers were looking to do with regard to enhancing Subversion merge support was the most frequent topic raised and the subsequent discussions and feedback we received was extremely valuable.

So with that information in hand, here’s what is being initially targeted:

  • Better handling of renames across merges
  • partially automated merges
  • Faster merges – improving performance of merge operations
  • Enhancements to importing to handle 3rd Party / Vendor source code

This is really just an initial list. The team is actually still quite busy at the moment working on the final aspects of Subversion 1.7.  But we are also still in active discussions about other use cases that have been raised and additional ideas may still be formulated and as those become more concrete, I’ll be quite happy to write about them here.

By the way, if you are still interested in attending Subversion Live, February’s weather pattern here in the Northeastern U.S. has accommodated you! Our Boston event scheduled for early February has been rescheduled for Tuesday, March 22. The same great agenda awaits but thankfully, the snow may not. I hope to see many of you in Boston and I’d welcome the chance to listen and learn from your experience.

– Rob

P.S.  I really did have to shovel a lot, including my roof!


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.

A Wealth of Information

As I stated in my last entry, there are many rich sources of feedback captured from the Subversion community.  The most obvious source of data is the Subversion project’s issue tracker, which contains a lot of the issues that will drive future updates to Subversion.  But there is a wealth of other data to look at to find what may be hindering users of Subversion.   The Subversion mailing lists and community sites can be particularly helpful in spotting recent trends, frustrations or simply common questions that continue to arise.

But one immediate source to focus our attention on is a couple of feedback sessions that were held about a year ago and hosted by Hyrum Wright and C. Michael Pilato.  The most interesting comment came from Mike’s session:

* Improved branching and merging: Everybody loves merge tracking
  and tree conflicts.  That is, when they don't hate it.
  Subversion should be smarter, and *must* learn to gracefully deal
  with renames.

Needless to say, we are already targeting better ways to handle merges across renames but it never hurts to see that reiterated in the summary of a feedback session such as this.

With respect to merge tracking in general, there are already a well known set of requirements that were captured by the project prior to the improvements delivered in Subversion 1.5.  These are a good reference point to start from but they do reflect the state of the project essentially at 1.4 and we want to update the use cases and capture relevant new use cases.  And while merging is a primary target for continued improvement, it is not the sole focus of this scoping exercise.  By no means are we limiting our attention to just this one topic.

We will continue to review both customer feedback and also the more specific issues captured in the issue tracker as we compile a prioritized list of targeted improvements. Beyond all of this data, I’m working with developers that have been involved in the project for years and their experience and instincts may prove to be as valuable source of ideas as any.

More to come…

– Rob


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.

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


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.