Tag Archive for 'best practices'

Subversion Live: Branching and Merging Best Practices

You may already have heard that Subversion Live is back for 2012, once again bringing the Apache Subversion community their own conference series. This year’s conference series is bigger and better than ever, with events taking place in San Francisco (October 10th & 11th) Greenwich Connecticut (October 16th & 17th) and London (October 23rd & 24th).

Confirmed sessions include:

  • What’s coming in 1.8
  • Best Practices for Large SVN Deployments
  • Merge & Performance Improvements
  • Apache Bloodhound
  • Hook Scripts
  • ….and more!

As part of Subversion Live 2012, WANdisco’s Director of Training Mike Lester will deliver a session on branching and merging best practices. We caught up with Mike, to find out what Subversion Live attendees can expect from ‘Branching & Merging Best Practices,’ and how 1.7’s merge tracking enhancements impacted Subversion users.

In your opinion, why does branching and merging remain such a hot topic for Subversion developers?

Mike Lester: People fear merging and thus avoid using branches, one of the most powerful tools built into Apache Subversion. They forget that as developers they have been doing branching and merging by hand for years, and fail to take advantage of all the capabilities that Subversion can bring to these activities.

Apache Subversion 1.7 introduced some merge tracking enhancements. How did these impact the branching and merging process for SVN users?

Mike Lester: By isolating the subtree mergeinfo updates to only the subtrees affected by a merge, rather than updating all subtree merge info, it makes keeping track of what was actually changed easier to monitor.

Who would benefit from attending ‘Branching and Merging Best Practices?

Mike Lester: Anyone that uses Subversion on multi-developer projects needs to come up with a plan on how they will use branches and merging. If you don’t have a plan yet or think your current procedures might be improved, this talk should help.

Can you give us a sneak preview of some of the best practices you’ll share in your Subversion Live session?

Mike Lester: Options on when to merge, guidelines of monitoring branches, examples of how project planning must change to do branching and merging and in a controlled manner.

Not signed up yet? Visit http://www.wandisco.com/svn-live-2012 to register, or find out more!

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.

Making Your Version Control Solution Agile

Maintaining a successful version control system is an important part of an agile project: version control allows you to easily roll back to a previous revision rather than manually unpicking changes; makes it easy to share your latest changes across distributed teams, and provides you with a quick and convenient sandbox in the form of a branch. These are just some of the benefits of version control, but there are some measures you can take to get even more out of your system. In this post, we share five tips for making your version control solution agile.

1) Set some guidelines

Maintaining a version control system can be a complex task, so implementing some guidelines – and making sure your whole team sticks to them! – can save you from unnecessary admin work later on.

  • Plan your layout – implementing a logical project layout from the very beginning can save you time and energy at a later date. Some version control systems, such as Apache Subversion, don’t impose a particular project structure, so it’s even more important to plan your layout in advance.
  • Be consistent with your file/folder names – a logical naming convention will make it easy to locate particular items.
  • Make your guidelines easily accessible – any conventions should be explained in a coding conventions file, which must be accessible to all members of your team. Consider placing these coding conventions under version control alongside the rest of your project, so they are always to hand.

2) Your code should always compile

In an agile project your code should always compile, which is where version control’s branching and merging functionality comes in handy. Any experimental development or new features should be confined to separate branches, and they should only be brought into the trunk when they’ve been tested to check they won’t break the build. This will ensure that the code in the trunk is always stable, and always compiles.

3) Place your whole project under version control

Version control isn’t just for source code management; you should place all files and folders related to your project under version control. Not only will this make it easier to locate files by keeping everything related to your project in one place, but version control’s ability to roll back to previous revisions is useless if you cannot then use that previous revision, or if you need to spend hours re-instating a list of related tools. Documentation, tools and libraries are all worth placing under version control, alongside your code.

4) Use Branches Wisely

Branches work best when they’re short lived. Being able to create a branch and customize the code to fit a particular customer’s requirements is one of the benefits of version control, but beware of maintaining this branch indefinitely alongside your main development line – multiple codebases can be costly and time-consuming to maintain.

5) Consider Enterprise Version Control Solutions

Our Subversion MultiSite solution combines open source Apache Subversion version control technology with value-added functionality designed to help teams stay agile, including:

  • No single point of failure
  • Automated failover
  • Built-in continuous hot backup and automated recovery
  • Continuous build integration
  • ….and more.

Want to learn more about Subversion MultiSite? On June 6th, 2012 WANdisco will hold a free webinar looking at the findings of an independent Forrester TEI study of a Fortune 500 company that implemented Subversion MultiSite. Visit the ‘Forrester Research on Optimizing Global Distributed Software Development Using Subversion’ page now to register.

All About the Subversion Commit Command

Apache Subversion’s ‘SVN Commit’ command sends changes from your working copy to the central repository, and is an essential command for sharing changes with the rest of your team. In this post we’ll show you how to perform an ‘SVN Commit’ before moving onto some best practices to bear in mind when committing your changes.

1) To perform a commit, you must first open the terminal window. To open this in Windows, press the “Windows key” and “r.” This will open a ‘Run’ dialog box.

2) Enter ‘cmd’ and click ‘OK.’

3) The terminal window will open. This is where you’ll enter all your SVN commands.

4) A commit is performed using the ‘SVN Commit’ command, the location of your working copy, and an appropriate log message. So, if your working copy has a location of C:\Users\Jessica\Documents\New_Project, the command would be:

5) Hit ‘Enter’ and your changes will be committed to the repository.

SVN Commit: 5 Best Practices

  • Always perform an ‘SVN Update’ before committing changes – this will help to avoid conflicts, and allows you to check how your changes perform in the latest version of the project.
  • Don’t commit unrelated changes – (i.e two bug fixes in one commit) this will make it difficult to distinguish where changes originated from and it can cause major headaches if the team decides to roll back to a particular revision.
  • Commit little and often – commit small changes frequently, instead of committing many small changes bundled into one large chunk. This will reduce the chances of encountering complications such as merge conflicts, and will reduce the complexity of conflicts when they do occur.
  • Never commit half-completed code – this will make rolling back to a previous revision tricky. This may seem to go against the concept of ‘commit little and often,’ but the solution is to split the task you’re working on into manageable but logical pieces, and then commit these regularly.
  • Make use of log messages – it is good practice to enter as much information as possible in the log message, as this can be an invaluable source of information if you need to revisit this particular revision at a later date. When performing a commit, the log message is entered in the “–message” format (e.g “–added ReadMe file”)

Need more info?

On June 7th we’ll be holding a free ‘All About the Subversion Commit Command’ webinar. This one hour webinar will cover:

  • Commit dialog options
  • Files or folders
  • Unversioned files
  • Ignored files
  • Drag and drop
  • Changelists
  • Common problems and how to avoid them

‘All About the Subversion Commit Command’ is free to attend but places are limited, so register now to avoid disappointment.

10 Best Practices for Version Control

Used correctly, version control is an invaluable tool – but following some basic guidelines can help you get even more out of your version control system. In this post, we share ten best practices for getting the most out of version control.

1) Version control everything…..

Version control is no longer just for source code management. Thanks to user-friendly and intuitive tools such as TortoiseSVN and uberSVN, version control is increasingly becoming a tool for programmers and non-programmers alike. Consider encouraging every member of your team (including the non-techies) to keep all files and folders related to your project under version control. This could include meeting minutes and whiteboard notes, architectural designs and user documentation. Even for documents that are unlikely to change, it’s useful to have everything in one place and available to everyone on the team.

2) …but don’t treat version control as a backup system

Although version control does provide you with a backup of your files and folders on a remote server, using your version control like a backup system is a bad habit that doesn’t make the most of the system’s unique functionality (although it is possible to backup your Apache Subversion repositories.)

3) Commit easily readable documents

If you’re committing documents that require formatting before they can be read, consider committing them in a more accessible form, such as a PDF. In addition to making documents quicker and easier to access, this allows you to refer people directly to a document in the repository. However, remember to update both versions of the document when you make changes (or better yet, automate this process.)

4) Be consistent with your file/folder names

Implementing a logical naming convention will make it easier to locate particular items. Ideally, this naming convention should be explained in a coding conventions file, which is accessible to all members of your team, and this convention should extend to all the projects in your repository.

5) Commit little and often

Commit small changes frequently, instead of committing many small changes bundled into one large chunk. This will reduce the chances of encountering complications such as merge conflicts, and will reduce the complexity of such conflicts when they do occur.

6) Only commit finished work

Never commit half-completed code. This seems to go against the concept of ‘commit little and often,’ but the solution is to split the task you’re working on into manageable but logical pieces, and then commit these regularly.

7) Update regularly

This ties into the concept of ‘commit little and often.’ Perform regular updates on your working copy, to keep up to date with the changes being made in the trunk. This is important, even if it seems your current work has little to do with the rest of the team. It is also good practice to update your working copy before making any changes.

8 ) Make use of log messages

Always make use of log messages, and make sure you include as much information as possible (what changes were made, why, and by whom, etc.) If the commit deals with a specific bug or change request, include the issue or bug number in the log message.

9) Implement a sane project layout

Maintaining a version control system can become a complex task, so implementing a logical project layout from the beginning is crucial. Some version control systems, such as Apache Subversion, don’t impose a strict project or repository structure, which makes planning your layout in advance even more important.

10) Test, test, test

Get into the habit of systematically testing everything, especially before you perform a commit or a merge. Also consider CI and assertion testing on feature branches, which is a useful way to indicate code maturity and progress.

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.

9 Ways to Dominate Development with Jenkins

Last month, we were proud to co-host another free training webinar with our friends at CloudBees. ‘9 Ways to Dominate Development with Jenkins’ was presented by WANdisco’s Director of Training, Mike Lester, and CloudBees’ Elite Developer and Architect, Ryan Campbell. Mike covered the essentials of setting up Jenkins through uberSVN, the free, open ALM platform for Apache Subversion, before CloudBees’ Ryan Campbell shared a grand total of nine best practices for using Jenkins with uberSVN.

The tips included how best to backup the Jenkins continuous integration server. Webinar attendees were shown how to locate their configuration data in the $JENKINS_HOME directory. The location of this directory varies depending on how you install Jenkins, but in uberSVN you can check this using the Configure Systems screen. To access this screen, simply click on ‘Manage Jenkins’ in the Jenkins tab of uberSVN.

From here, select the ‘Configure Systems’ option.

This will take you to the all-important Jenkins Home directory, which contains the data you will need to backup.

Webinar attendees also learnt that it’s possible to create a backup while Jenkins is running, as Jenkins makes changes atomically to the cloud system. Whenever you change your configuration, Jenkins writes that configuration file to a temporary file and then moves it over atomically at the operating system level, which means creating a backup of a live Jenkins installation isn’t a problem.

The webinar also shared advice for planning disk capacity for Jenkins, the benefits of native installers, adding additional distributed builds to your Jenkins instance, and more.

Missed the webinar the first time around? The good news is that the entire webinar replay is now available to view on-demand, from our Webinar Replay page. And, if you enjoyed ‘9 Ways to Dominate Development with Jenkins,’ you can sign up for more of our upcoming webinars at http://www.wandisco.com/training/webinars.

Subversion Tip of the Week

Admin Best Practices

Apache Subversion users have 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 code in the trunk should be stable – all experimental development should be confined to separate branches.
  • Consider CI and automated regression testing – these can help ensure there is no regression in the all-important trunk. uberSVN users can download the popular Jenkins open source CI server for free from inside their installation.

  • Make snapshots of your project – tags should be used to make snapshots of your project at certain points during the development process (e.g tagging a snapshot as ‘Release 1.0.’) It is also good practice to make snapshots of your project before implementing major new features. This makes it easier to roll back and effectively ‘undo’ the new feature, if required.
  • Take care when making structural changes – structural changes should always be performed on the trunk, when there are no branches waiting to be merged. This can help development teams avoid serious and time-consuming conflicts.
  • Use changelists – if you are working on several different issues simultaneously, there is a risk of losing track of which files relate to which issue. In these situations, it can be helpful to organize your files into ‘Changelists.’ Changelists can be created either from the commit dialog, or the ‘Check for modifications’ dialog. In this example, we’ll look at creating a changelist from the commit dialog:

1) Highlight the files you wish to place into a changelist, right-click and select ‘Move to changelist.’ In this example, we’ll be creating a new changelist.

2) Enter a name for your changelist and select ‘Ok.’

3) Your modified files will now be automatically organized according to the new changelist. This allows you to see at-a-glance, which modifications have been made for each task, and to commit these changes separately.

Subversion Tip of the Week

Structuring Your Repository

Implementing a logical project layout in Apache Subversion right from the beginning, can save you from administrative hell later. 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 code in the trunk should be stable – all experimental development should be confined to separate branches.
  • Consider continuous integration and automated regression testing – these can help ensure there is no regression in the all-important trunk. uberSVN users can download the popular Jenkins open source CI server for free from inside their installation.
    • Make snapshots of your project – tags should be used to make snapshots of your project at certain points during the development process (e.g. tagging a snapshot as ‘Release 1.0.’) It is also good practice to make snapshots of your project before implementing major new features. This makes it easier to roll back and effectively ‘undo’ the new feature, if required.
    • Take care when making structural changes – structural changes should always be performed on the trunk, when there are no branches waiting to be merged. This can help development teams avoid serious and time-consuming conflicts.

    Mike Lester is WANdisco’s Director of Training. Mike has more than 33 years of experience in the software industry, having spent the past 26 years focusing on training and consulting for Subversion and other software configuration management systems. Mike delivers WANdisco’s free training webinars, and regularly shares his SVN know-how at the WANdisco blog. Mike is also available for Enterprise Training.