Tag Archive for 'changelist'

Intro to SmartSVN Change Sets

In Apache Subversion, it’s not unusual for developers to be working on multiple unrelated changes at the same time, in the same project. To distinguish between the different ongoing tasks in your project, SmartSVN supports ‘change sets’, groups of committable files and directories. Not only do change sets allow you to bring some order to your commits and updates, but it’s useful for grouping files together in order to commit them later. These change sets are an extension to the Subversion changelists.

In this short tutorial, we’ll provide an introduction to SmartSVN’s change sets by showing you how to create your first change set, and then how to add and remove files from them.

How to Create Your First Change Set

1) Select the files you wish to add to a new change set.




2) Open the ‘Change Set’  menu and select ‘Move to Change Set….’




3) Enter an appropriate message, which will be displayed as the name of the changelist, and decide whether you want SmartSVN to automatically delete the change set if it ever becomes empty. Select ‘OK’ once you are happy with the information you have entered.











4) SmartSVN will now go ahead and add these files to the change set.




If you don’t want to see them in the normal Files view, unselect View|Files Assigned to Change Set. This allows you to (temporarily) hide even unchanged or modified files which otherwise would clutter the file list.

How to Add a File to an Existing Change Set

1) Select the file you wish to add to an existing change set, followed by the ‘Move to Change Set…’ option.

2) Ensure the ‘Existing Change Set’ option is selected, and select the existing change set of your choice from the ‘Target Change Set’ combobox.











3) Select ‘OK’ to add this file to the existing change set.

Remove a File from a Change Set

1) To remove a file from a Change Set, select the file and open the ‘Move to change set…’ dialog.

2) Select the ‘Remove form Change Set’ option and click ‘OK’.











Right-click a Change Set to commit it. The change set’s Message will be used to prefill the commit message.

Not yet started with SmartSVN? You can download a free SmartSVN Foundation edition at http://smartsvn.com/

Subversion Tip of the Week

Creating Changelists from the Command Line

In the world of modern software development, it’s not unusual for developers to be working on multiple, unrelated changes within the same project. In these situations, Apache Subversion‘s changelists can be an invaluable tool for keeping track of which changes relate to which part of the development effort.

Changelists are labels that can be used to group related files together. Files can be added to a changelist with the ‘svn changelist’ command, followed by the name of the changelist, and the file’s path:

svn changelist “Changelist-name” {path}

In this example, we are adding a text file called ‘Wiki’ to a changelist called ‘Changelist’:

You can add as many files as you want to each changelist, and can create multiple changelists within the same working copy. If you need to check on the status of your changelists, you can use the ‘svn status’ command, followed by the location of your working copy:

This will list all the files that are associated with the different changelists in your working copy.

Tip: There are some limitations worth baring in mind when using changelists:

    • Changelists cannot be sent to the repository, and therefore cannot be shared.
    • Changelists can only be assigned to files, and not directories.
    • Files can only be assigned to one changelist at a time.


Subversion Tip of the Week

Changelists : Bring Some Order to your Working Copy

When modifying a working copy with TortoiseSVN, it can be useful to pinpoint exactly which files you’ve changed, and which files have been changed and committed by others, before you perform a commit. TortoiseSVN has a ‘Check for Modifications’ function especially for this.

1) Start by selecting the ‘Check for Modifications…’ option from the TortoiseSVN menu.

2) This will bring up a dialog displaying every file that has been changed in your working copy, with colour coding to highlight the status.

3) By default, all the modified files will appear in an unordered list. If you have been working on unrelated tasks simultaneously, it may be useful to define which modified files are related to which task, by organizing your files into changelists. To group your files in the ‘Check for Modifications…’ dialog, highlight the files you wish to organize into a changelist, right-click and select ‘Move to changelist.’

4) From here, you can select an existing changelist or create a new changelist. In this example, we’ll create a new changelist. When prompted, enter a name for your changelist and click ‘Ok.’

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. We’re currently running a very special early bird offer: register now using the ‘earlybird’ code to get a 25% discount (note, the early bird offer ends 10th August, so you better be quick!)

Subversion Tip of the Week

Changelists: Bringing Order to your Commits

If you are working on several different issues simultaneously within your working copy, there is a risk of you losing track of which files are related to which change. In these situations, organizing your files into changelists can make them more manageable. Changelists can be created either from the ‘Check for modifications…’ dialog, or from the commit dialog. In this tutorial, we’ll look at creating a changelist from the commit dialog.

1) Start by running an ‘SVN Commit.’ This will bring up an unordered list of all the files you have modified since you last performed a commit.

2) Highlight the files you wish to make up your changelist, right-click and select ‘Move to changelist.’

3) In this example, we’ll create a new changelist. When prompted, enter the name of your changelist and click ‘Ok.’

4) TortoiseSVN will automatically sort all of your modified files into the new changelist. This allows you to see at-a-glance which modifications are related to which tasks, and to separately commit changes relating to different tasks.

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. Find out how our Sherpas can help you!

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.