Tag Archive for 'resolve'

Subversion Live: What’s Coming in SVN 1.8?

Apache Subversion 1.8 is currently scheduled for release later this year, so it’s no surprise that Subversion Live London’s ‘What’s Coming in 1.8: Overview’ session drew a large crowd, especially as the session was conducted by core Subversion committers Julian Foad, Stefan Fuhrmann, Ben Reser and Philip Martin.

First, the committers covered what the community can expect from the 1.8 release process, and stressed the importance of community testing during the Release Candidate stage. “The Release Candidates are your opportunity to tell us about the bugs that really hurt you,” said Stefan.

The session then moved onto the new functionality that’s planned for this release, with an in-depth explanation of the following:

  • EV2 – a new framework for Subversion 1.8
  • Deltification improvements – the committers stressed that this will be particularly useful for people working on large repositories
  • A new benchmarking tool for identifying server and performance bottlenecks
  • Support for –include -externals in SVN Commit
  • SVN Merge improvements – users will no longer have to distinguish between a reintegrate merge and a sync merge
  • svn mergeinfo will include a summary diagram as the default output
  • revprop handling – improved handling during backup
  • A more interactive SVN Resolve command

  • Three new options for SVN Diff (–ignore-properties, –properties-only, and –patch-compatible)
  • A new password agent on UNIX
  • svnadmin freeze – this command will delay commits while other operations are performed on the repository. Throughout this process, the repository remains live. The committers revealed that this new feature was inspired by a conversation with an attendee at Subversion Live 2011.

Unsurprisingly, many attendees used the Q and A time at the end of the presentation to quiz the core committers on the finer details of the upcoming 1.8 release, especially the changes to inherited properties, pristine copies, reintegrate merges, and even Subversion’s bindings. The bindings question led to an invitation for the audience members to become Subversion committers themselves: “If the bindings are important to your business, send us a patch,” said Philip Martin.

Another topic of conversation during the Q and A section, was whether upgrading the working copy to 1.8 should be a manual or an automatic process. The general consensus among Subversion Live attendees seemed to be that it should be manual.

Attendees were also able to get advice from the committers on how to leverage Subversion 1.8’s features for their own individual use cases. In fact, there were so many questions that the next session was due to start before all the attendees’ questions were answered. Thankfully, all of the core committers were at Subversion Live throughout the last day (and were also available for more questioning during the Committer Roundtable session) giving attendees plenty of time to find out more about Subversion 1.8.

Read all about Subversion Live 2012, with our recaps of Day One and Day Two, and an in-depth look at the Subversion Live Keynote.

Getting More out of Version Control with SmartSVN

In our previous SmartSVN posts, we covered essential functionality to get you off to a flying start with this cross-platform graphical client for Apache Subversion. In this post, we cover some more advanced options, including performing a reverse merge, reverting local changes and resolving any conflicts that occur when you try to perform a commit with SmartSVN.

Didn’t catch our intro to SmartSVN series? Get up to speed with the following links:

Reverse Merge

As Subversion remembers every change that’s committed to the repository, it’s possible to revert to previous revisions of your project. This is useful if you introduce a code-breaking feature in revision 15, and need to revert to a revision before it all went wrong. This is achieved by performing a ‘reverse merge’ i.e merging the changes in your current revision, to an earlier revision.

To perform a reverse merge with SmartSVN:

1) Select the ‘Merge’ item from the ‘Modify’ menu.

2) In the Merge dialog, enter the revision number you wish to roll back to.








If you need more information about the different revisions, click the ‘Select…’ button next to the ‘Revision Range’ textbox. The subsequent dialog displays the different revisions, alongside the commit message, time, author and path data for each revision. Note, the green arrows indicate revisions not yet merged.








3) Ensure the ‘Reverse merge’ checkbox is selected and finally, click ‘Merge.’

4) Remember to commit your changes to the repository, to make this reverse merge permanent!

Alternatively, right-click the revision you wish to reverse-merge in the Transactions tool window and select “Rollback.”


Revert overwrites any local changes made to the working copy, with the file content held in the repository. Note, this command should be used with caution: a revert effectively deletes all the changes made since your last commit, and once they are gone there is no way to recover them.

To perform a revert with SmartSVN, right-click on the file/directory you wish to revert, and select the ‘Revert’ option from the drop-down menu  (alternatively, select the ‘revert’ button from the toolbar.)








SmartSVN will ask you to confirm the revert. Select the ‘Revert’ button to go ahead and remove all your local changes.






At some point during your project’s lifecycle, your repository may change location and therefore get a new URL. This can be solved by deleting your working copy and performing a checkout from the new repository location, but there is a quicker way to solve this problem: the ‘Relocate’ command can be used to rewrite all the URLs associated with the files and folders in your working copy, with the new URLs. This allows you to continue using your current working copy and, of course, to successfully commit all your hard work back to the repository.

1) Open the ‘Modify’ menu and select ‘Relocate…’

2) The ‘Relocate’ dialog displays the URL of the selected directory. In the ‘To URL’ option, specify the replacement URL.







3) Select ‘Relocate’ to change the repository for your directory.

Note, this operation should be used with caution, as if used incorrectly it can corrupt your working copy. The ‘Relocate’ command should not be used to:

  • move to a different Subversion repository.
  • switch to a different branch or directory within the same repository.

Resolving Conflicts

When you are performing a commit in Apache Subversion, you may occasionally encounter the dreaded Subversion conflict, and your commit will fail. Thankfully, SmartSVN comes with a ‘conflict solver’ to help resolve these conflicts when they do occur. To access this conflict solver, open the ‘Query’ menu and select ‘Conflict solver.’











In the ‘Mark Resolved’ dialog, you can opt to:

  • Leave the file/directory as it is.
  • Take the version in the working copy, as it was before the update or merge was performed.
  • Take the new version – the pristine copy after the update or merge was performed.
  • Take the old version – the pristine copy before the update or merge was performed.
Select the appropriate checkbox and select ‘Ok.’ The conflict should now be resolved, and you can commit your changes to the repository to make them permanent.
Set a Property
‘Properties’ in Subversion are useful for associating metadata with the files placed under version control. To set a property for your Subversion files or directories using SmartSVN, open the ‘Properties’ menu and click ‘Select or delete Property….’
Use the drop-down ‘Property’ menu to select the desired Subversion internal property. The default properties are:
  • svn:eol-style – makes the client convert line-endings in text files. This property is used when the working copy is required in a specific EOL style.
  • svn:executable – makes files on Unix-hosted working copies executable.
  • svn:externals – a multi-line value defined on a directory that allows parts of other repositories to be automatically checked out.
  • svn:ignore – a list of unversioned filename patterns that should be ignored by ‘svn status’ and other subcommands.
  • svn:keywords – Subversion has the ability to substitute keywords into the contents of a file itself when changes are made. Keywords are useful for automatically maintaining information (such as author, revision number, etc) that would be too time-consuming to keep changing by hand.
  • svn:mergeinfo – this property is used to track merge data and is automatically maintained by the ‘SVN merge’ command.
  • svn:mime-type – indicates the file’s MIME type and allows the client to decide if contextual merging is safe during updates. Note, this property affects the handling of diffs and merging.
  • svn:needs-lock – tells the client that files should be checked out with permissions set to read-only. This is designed to be used in conjunction with the ‘SVN Lock’ command, to remind the developer to obtain a lock before beginning work on a file. This saves the developer from spending time modifying a file and then discovering it’s locked when it’s time to commit.

Select a value for your property (if applicable) and hit the ‘Ok’ button to set the new property.

Visit http://smartsvn.com/ to claim your free download of SmartSVN Foundation.