Tip of the Week Blog

Subversion Tip of the Week

Published by jthornsby on May 8, 2012 in General, Subversion, Tip of the Week and WANdisco. 0 Comments Tags: , , , , , , , .

Revert to a previous revision

As Apache Subversion remembers every change made to its files and directories, it is always possible to roll back to a previous version of your project. This can be a life-saver if new features have turned out to be unnecessary, or even introduced bugs into your project. Simply rolling back to a revision before it all went wrong, can be far quicker and easier than trying to fix all of the problems manually.

Reverting to a previous revision in Subversion, is simply a matter of merging the changes in your current revision, to an earlier revision. To get started with reverting to a previous revision, select ‘Merge’ from the TortoiseSVN menu.

Select ‘merge a range of revisions.’ Click ‘Next.’

Select ‘Show Log.’

Select the revision you wish to roll back to. In this instance, we’ll revert to revision 13.

The selected revision will be automatically entered into the ‘Merge’ dialog. Ensure ‘Reverse merge’ is selected, and click ‘Next.’

This dialog allows you to set a range of options for merging. However, in most instances the default settings can be used. Click ‘Merge.’

Subversion will now roll your working copy back to revision 13.

Tip: Remember that the merge command only changes files in the working copy, so you must remember to commit your changes back to the repository.

Our Support Engineers are the Sherpas of Source Control Management! Just as traditional Sherpas use their deep knowledge of local terrain to assist mountain climbers in reaching the highest peaks and avoiding pitfalls along the way, WANdisco’s Subversion Sherpas use their extensive experience to guide customers away from problems and enable them to get the most out of Subversion. Our ‘Team Sherpa’ consists of highly skilled support engineers and core Subversion developers who have been working on the Subversion project since it began, and are also uniquely positioned to help you migrate to the latest and greatest releases of SVN. You can hire one of our Subversion Sherpas today, by visiting http://www.wandisco.com/subversion/support

Subversion Tip of the Week

Published by sherpa on April 30, 2012 in General, Subversion, Tip of the Week and WANdisco. 0 Comments Tags: , , , , , , , , , , , .

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

Published by sherpa on April 23, 2012 in General, Subversion, Tip of the Week and WANdisco. 0 Comments Tags: , , , , , , , , .

Merging a Range of Revisions with TortoiseSVN

TortoiseSVN’s ‘Merge’ functionality is essential for projects where separate lines of development are maintained. At some point, the changes will need to be merged from one branch, into the trunk (or vice versa!) This method is useful when you have made one, or more, revisions to a branch (or trunk) and you need to port these changes to a different branch.

1) Select the branch where you wish to perform your merge. Right-click and select the ‘Merge’ option from the TortoiseSVN sub-menu.

2) Select ‘Merge a range of revisions’ and click ‘Next.’

3) Select the URL containing the changes you wish to port to your working copy, and the revision range to merge. For more information on the different revisions you can choose from, click ‘Show Log.’

4) This dialog displays all the recent changes and log comments. To merge the changes from a particular revision, simply select that revision. To select a range of revisions, use the Shift-modifier. When you are happy with your selection, click ‘Ok.’

5) The range of revisions you are about to merge are automatically added to the Merge dialog. Click ‘Next.’

6) This page lets you specify some advanced options, although in most situations you can use the default settings. Click ‘Merge.’

7) You will see the following message, informing you that your merge has been successful.

TIP: Merging always takes place within a working copy, and it is good practice to perform a merge into an unmodified working copy. If you have made some changes to your working copy, you should commit these first – merging can become a complicated process, and if a merge doesn’t go quite as expected, the quick-fix ‘Revert’ command will discard all changes, including any you neglected to commit before starting the merge.

Our Support Engineers are the Sherpas of Source Control Management! Just as traditional Sherpas use their deep knowledge of local terrain to assist mountain climbers in reaching the highest peaks and avoiding pitfalls along the way, WANdisco’s Subversion Sherpas use their extensive experience to guide customers away from problems and enable them to get the most out of Subversion. Our ‘Team Sherpa’ consists of highly skilled support engineers and core Subversion developers who have been working on the Subversion project since it began, and are also uniquely positioned to help you migrate to the latest and greatest releases of SVN. You can hire one of our Subversion Sherpas today, by visiting http://www.wandisco.com/subversion/support

Subversion Tip of the Week

Published by sherpa on April 16, 2012 in General, Subversion, Tip of the Week and WANdisco. 1 Comment Tags: , , , , , , , , , , , .

Editing Log Messages

At some point, you may wish to add, delete, or alter the information contained within the log messages from previous revisions. This is made easy with TortoiseSVN.

Tip: The ability to edit log messages is disabled by default. To enable it, modify the pre-revprop-change hook, which can be found in the “hooks” folder of your repository.

1) To get started, select the ‘Show log’ option from the TortoiseSVN menu.

2) In the ‘Log messages’ dialog, right-click on the desired revision and select ‘Edit log message.’

3) You can now edit the revision’s log message. Once you are happy with the changes, click ‘Ok’ to save them.

Our Support Engineers are the Sherpas of Source Control Management! Just as traditional Sherpas use their deep knowledge of local terrain to assist mountain climbers in reaching the highest peaks and avoiding pitfalls along the way, WANdisco’s Subversion Sherpas use their extensive experience to guide customers away from problems and enable them to get the most out of Subversion. Our ‘Team Sherpa’ consists of highly skilled support engineers and core Subversion developers who have been working on the Subversion project since it began, and are also uniquely positioned to help you migrate to the latest and greatest releases of SVN. You can hire one of our Subversion Sherpas today, by visiting http://www.wandisco.com/subversion/support

Subversion Tip of the Week

Published by sherpa on April 10, 2012 in General, Subversion, Tip of the Week and WANdisco. 0 Comments Tags: , , , , , , , , .

Solving the “Working Copy is out of date” Error

When attempting to commit your changes back to the Subversion repository, you may see a “working copy is out of date” error similar to the one below.

There are three main causes of a “working copy is out of date” error:

1) If your commit was interrupted in the time between the new vision being added to the server, and the client performing its post-commit admin tasks, leftover debris from this failed commit could be causing the error. The first step, is to determine whether the changes actually reached the server or not. This is achieved with the ‘svn log’ command:

svn log (PATH)

If ‘svn log’ reveals that the commit actually succeeded, you need to bring your working copy in line with the repository. In this instance, you can use ‘svn revert’ to revert the local changes:

svn revert (PATH)

Now, run an ‘svn update’ to get your changes back from the server.

2) Another possible cause, is mixed revisions. The SVN commit command only increases the revision number for the files it touches, which can lead to different revision numbers within the same repository. There are certain operations that will fail if the repository has a more recent version of the node. This can be fixed by running ‘svn update’ in the working copy.

3) Finally, your working copy could actually be out of date! If someone has committed their own changes to the repository since you checked out, or last updated, your working copy, an ‘svn update’ is required before you can commit your changes.

Our Support Engineers are the Sherpas of Source Control Management! Just as traditional Sherpas use their deep knowledge of local terrain to assist mountain climbers in reaching the highest peaks and avoiding pitfalls along the way, WANdisco’s Subversion Sherpas use their extensive experience to guide customers away from problems and enable them to get the most out of Subversion. Our ‘Team Sherpa’ consists of highly skilled support engineers and core Subversion developers who have been working on the Subversion project since it began, and are also uniquely positioned to help you migrate to the latest and greatest releases of SVN. You can hire one of our Subversion Sherpas today, by visiting http://www.wandisco.com/subversion/support

Subversion Tip of the Week

Published by sherpa on April 2, 2012 in General, Subversion, Tip of the Week and WANdisco. 0 Comments Tags: , , , , , , , , , , .

TortoiseSVN Quickstart

TortoiseSVN is a popular Windows client for Apache Subversion, that makes version control easy! This week, we will cover all the basic TortoiseSVN operations in six easy steps.

1) The first step, is to checkout a working copy. Open the location on your hard drive where you wish to create your working copy, right-click and select ‘SVN Checkout.’

2) In the Checkout dialog, enter the URL of your repository and click ‘Ok.’

3) TortoiseSVN will now checkout a working copy. Click ‘Ok.’

4) Make some changes to your working copy. Note that if these changes include creating new files, you must ‘Add’ them to TortoiseSVN before they are placed under version control.

5) Once you have finished making your changes, click ‘SVN Commit…’ to commit your changes back to the repository.

6) Another essential function for your TortoiseSVN development, is ‘SVN Update.’ This command pulls updates from the repository into your working copy, reducing the chances of encountering merge conflicts when you perform your own commits. This is made easy with TortoiseSVN, simply select the ‘SVN Update’ option from the Windows context menu.

And that’s it! You’re now ready to continue making changes to your working copy, and committing them back to the repository, while running regular ‘SVN Updates’ to ensure all the latest repository changes are pulled into your working copy.

Need some extra help with your TortoiseSVN installation? We provide professional support for TortoiseSVN

Our Support Engineers are the Sherpas of Source Control Management! Just as traditional Sherpas use their deep knowledge of local terrain to assist mountain climbers in reaching the highest peaks and avoiding pitfalls along the way, WANdisco’s Subversion Sherpas use their extensive experience to guide customers away from problems and enable them to get the most out of Subversion. Our ‘Team Sherpa’ consists of highly skilled support engineers and core Subversion developers who have been working on the Subversion project since it began, and are also uniquely positioned to help you migrate to the latest and greatest releases of SVN. You can hire one of our Subversion Sherpas today, by visiting http://www.wandisco.com/subversion/support

Subversion Tip of the Week

Published by sherpa on March 26, 2012 in General, Subversion, Tip of the Week and WANdisco. 2 Comments Tags: , , , , , , , , .

How to Checkout a Single File

While Apache Subversion does not allow you to checkout a single file as such, if you checkout a copy of your entire repository, there is a way to export a single file from that working copy (note, this exported file will not be under version control.) Exporting a single file in this way, makes use of the ‘svn export’ command.

1) To get started, checkout a copy of your repository, decide which file you wish to export and then open the terminal window. To export a particular file from your working copy, to a particular location, use the following command:

svn export PATH1 PATH2

(PATH1 is the location of the file you wish to export, and PATH2 is the location where it will be exported to.)

In this example, the command will look like this:

2) Following a successful export, you will see an “Export complete” message.

3) You will notice an unversioned copy of the file has appeared in the specified location. In this example, this is on the desktop.

Need some extra help with your Subversion implementation? We offer professional support for Apache Subversion, featuring guaranteed response times and 24-by-7 worldwide coverage.

Subversion Tip of the Week

Published by mlester on March 13, 2012 in General, Subversion, Tip of the Week and WANdisco. 0 Comments Tags: , , , , , , , , , .

Using an Editor for Entering Log Messages from Command Line

When you are using Apache Subversion from the command line, whether from Windows or UNIX, it is possible to have an editor pop-up and enter the required Log Message.

There are three methods for getting the Log Message into Subversion.

1) Use the –message (-m) option and put the message string in quotes.
svn ci –m”Fixed bug # 4322”
2) Use the –file (-F) option and put the message in a file
svn ci –F logtxt.dat
3) Or, have SVN launch an editor and use it to compose your message.

Of these three, the last one is the easiest.

If you do not use any of the above options, you will receive the following message.

Setting up an editor is quite easy. There are two different options.

Use the configuration file or use an environmental variable to point to the editor.

To use the configuration file you need to modify the config file and add the line that tells Subversion to use an external editor.

### Section for configuring external helper applications.

[helpers]

### Set editor-cmd to the command used to invoke your text editor.
### This will override the environment variables that Subversion
### examines by default to find this information ($EDITOR, et al).

editor-cmd = notepad.exe

To use the environmental variable, set the EDITOR variable to your editor. In the command window, execute the following line.

set EDITOR=notepad.exe

You can use any editor that can be initiated from the command line. I have used both Notepad and TextPad.

Below, I show the screen that comes up in Notepad, then the screen filled out with my comments, then running the Log Command to see the new log message.

This is the screen that pops-up when using notepad.exe. The existing text tells you the file(s) modified and where to add the Log Message.

Here I have added in the Log Message. After this save the file, then exit the editor.

Here I ran the “LOG” command to see the new Log Message. Note: The extra lines in the editor were purged.

If you exit your editor without saving its contents, you will receive the following message.

The options are:
(a)bort – Cancel the COMMIT command.
(c)ontinue-Finish the commit with no Log Message.
(e)dit-Bring the editor back.

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.

Subversion Tip of the Week

Published by mlester on March 13, 2012 in General, Subversion, Tip of the Week and WANdisco. 0 Comments Tags: , , , , , , , .

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.

Subversion Tip of the Week

Published by jthornsby on March 5, 2012 in Subversion, Tip of the Week and WANdisco. 3 Comments Tags: , , , , .

Avoiding Conflicts in Subversion

Occasionally, when performing a commit in Apache Subversion, you may encounter the dreaded Subversion conflict, and your commit will fail. Subversion has all the tools needed to resolve conflicts when they do occur, but the best course of action is to avoid running into conflicts in the first place. Thankfully, there are some measures you can take, to reduce the chances of encountering merge conflicts.

  • Communicate with your colleagues! If you’re aware of what the rest of your team is working on, there’s less chance you’ll unintentionally alter the same file.
  • Perform an ‘svn update’ on your working copy whenever a colleague commits a change that could potentially affect you.

  • In more extreme cases, consider employing the Subversion lock command, which allows the ‘lock owner’ to exclusively modify a file in a repository. To create a lock, simply create a property on a directory tree called ‘lock’:

    • svn propset lock

    Commit this property to the repository (it doesn’t matter what value the lock property is set to.) If anyone tries to commit to a locked file, Subversion will have to authenticate that they are the lock owner, before it allows the commit. Just remember to unlock the file when you’re done – or risk annoying your colleagues!

  • Commit frequently – this will reduce the complexity of conflicts, when they do occur.