Tag Archive for 'conflict'

Subversion Tip of the Week

SmartSVN’s Project Settings Menu 

SmartSVN’s ‘global preferences’ is a method of specifying settings across all your SmartSVN projects for efficiency and simplicity. However, sometimes you need to change settings for a single project, which is where the ‘Project Settings’ menu comes in handy.

In this week’s tip, we’ll look at some of the SmartSVN settings you can apply using this menu.

Accessing Project Settings

To access SmartSVN’s Project Settings, open the ‘Project’ menu and select ‘Settings.’ The different options are listed on the dialog box’s left-hand side.

project settings

1) Text File Encoding

This affects how file contents are presented. Choose from:

  • Use system’s default encoding – SmartSVN uses the system’s encoding when displaying files. This is the default setting for SmartSVN.

  • Use the following encoding – Select your own encoding from the dropdown menu. This is useful if you’re dealing with international characters, which may otherwise be encoded incorrectly.

Note, if you’ve specified a file type using the MIME-Type property, SmartSVN will choose this over the text file encoding settings.

2) Refresh/Scan

SmartSVN can either scan the ‘whole project’ or the ‘root directory only’ when you open a project. In most instances, you’ll want to scan the entire project, but if you’re working with particularly large repositories, the ‘root directory only’ option can speed up this initial scan and avoid high memory consumption.

3) Working Copy

Clicking on ‘Working Copy’ presents you with several checkboxes:

working copy

  • (Re)set to Commit-Times after manipulating local files – tells SmartSVN to always use a local file’s internal Apache Subversion property commit-time. This is useful for ensuring consistency across timezones, and between clients and the Subversion repository.

  • Apply auto-props from SVN ‘config’ file to added files – tells SmartSVN to use the auto-props from the SVN ‘config’ file. With auto-props enabled, you can perform tasks such as automatically inserting keywords into text files and ensuring every file has EOLs that are consistent with the operating system. Not only are auto-props a time-saving feature, but they can help you avoid human error within your project.

  • Keep input files after merging (monitored merge) – tells SmartSVN to always keep the .aux files following a merge, even for non-conflicting files. These files are stored in the ‘merged’ state and can be used to gain a deeper insight into what has changed during the merge.

4) Locks

Apache Subversion is built around a ‘copy-modify-merge’ model, but there are times when a ‘lock-modify-unlock’ model may be appropriate, for example when you’re working on image files, which cannot easily be merged. SmartSVN has full support for locking and unlocking files, but if you’re going to make heavy use of locks, you can configure SmartSVN to automatically flag certain files as requiring locking before anyone begins working on them. This is a useful reminder, especially if your project contains multiple non-mergeable files. Open the ‘Lock’ section of the Project Settings dialog and select either ‘all binary files’ or ‘every file,’ if required. The default is ‘no file.’

You can also choose whether SmartSVN should suggest releasing or keeping locks whenever you perform a commit, which is a helpful reminder if your team are working with multiple locks. Finally, the ‘Automatically scan for locks’ option tells SmartSVN to scan for locked files at specified intervals.

Find out more about locks by reading our ‘Locking and Unlocking in SmartSVN’ blog post.

5) Conflicts

When SmartSVN encounters conflicts, it adds new extensions to the conflicting files to help distinguish between them. By default, SmartSVN will take its cues from the config file, but if you want to specify particular extensions, you can select ‘Use following extensions’ and type the desired extensions into the textbox.

Remember, you can download your free edition of SmartSVN Professional at www.smartsvn.com/download

Subversion Tip of the Week

Solving Conflicts with SmartSVN

Conflicts can be tricky for Apache Subversion users, but SmartSVN comes with a dedicated ‘Conflict Solver’ that takes the pain out of resolving them. SmartSVN’s built-in Conflict Solver combines the freedom of a general, three-way-merge with the ability to detect and resolve any conflicts that occur during the development lifecycle.

To access this conflict solver, open the ‘Query’ menu and select ‘Conflict solver.’

conflict solver

The contents of the two conflicted files are displayed on the right and left text areas, and the differences between the left and right content is highlighted by coloured regions within the text views.

Once you have finished editing your files, open the ‘Modify’ menu and select ‘Mark Resolved’ to mark the conflicting file(s) as resolved. In this dialog, you can also opt to:

  • Leave as is – apply no further modifications to the resolved file.
  • Take old – accept the version in the working copy, as it was before the update or merge  was performed.
  • Take new – the pristine copy after the update or merge was performed.
  • Take working copy – the pristine copy before the update or merge was performed.

If you’re working with conflicted directories, you have the option to ‘Resolve files and subdirectories recursively.’  If selected, all conflicting files and directories within the selected directory will be resolved.

Note, you must resolve all the conflicts before you can commit the file(s)/directories.

Not yet started with SmartSVN? Claim your free 30 day trial at www.smartsvn.com/download

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

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.

 

 

 

 

Relocate

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.

Resolving Conflicts in Subversion

When you are performing a commit in Subversion, you may very occasionally encounter the dreaded Subversion conflict, and your commit will fail. A lot of drama is made about conflicts in version control, but Subversion has all the functionality you need to quickly resolve conflicts when they arise.

Conflicts occur when you attempt to commit a file that has been updated in the repository since you performed your check out, e.g:

    • File A is checked out by Person A.
    • Person B commits a change to File A in the repository.
    • Person A makes a change to File A, and tries to commit file A to the repository. Subversion will flag up a conflict.

 

When you encounter a conflict, the first step is to run an update on your working copy:

svn update (path)

Subversion will then attempt to merge the repository’s changes into your working copy, while retaining the changes in your working copy. If the changes affect different sections of the file (e.g different lines of code) the server will successfully merge the changes, and you will be able to complete your commit. But, what if you’ve modified the exact same part of the file, and Subversion is unable to merge the changes? Subversion will mark the file as being in ‘conflict’ and the problem will need to be resolved manually.

To resolve the conflict, open the corresponding folder in your working copy. You will see three versions of the conflicted file – two with filename extensions based on their revision number, and one without a numerical extension, which is the working file. The file with the highest numbered extension is the repository’s most recent file, and the file with the lower revision number is your local file. There are three possible ways to resolve this conflict:

    • Replace the repository’s version with your local version.
    • Keep the repository’s most recent version.
    • Manually merge the changes from the repository’s version and the local version.

 

Once you’ve decided which item to keep – or finished manually merging the changes into a single file – replace the working file with the finished item, and delete the duplicates generated by Subversion. Now, you will be able to successfully complete your commit. It is also worth bearing in mind that in some situations (particularly those where your changes are minimal) it may be quicker to delete your working copy of the conflicted file, perform an update and then reapply your changes to the freshly checked out file, rather than trying to resolve the conflict.

Avoiding Conflicts

Although Subversion has functionality for resolving conflicts, the best cause of action is to avoid conflicts in the first place. There are several measures you can take to avoid running into conflicts in Subversion:

    • One of the most effective ways is also the simplest: communicate with your colleagues. Discussing what you’re working on, is an easy way to avoid unintentionally working on the same files.
    • A more heavy-handed approach, is to employ Subversion’s lock command. Subversion is built around a ‘copy-modify-merge’ model, but there are times when a ‘lock-modify-unlock’ model may be appropriate (for example, when you are working on image files, which cannot easily be merged.) Locking in Subversion allows the ‘lock owner’ to exclusively modify a file in a repository (note that it is currently not possible to restrict access to an entire directory tree.)

To create a lock, create a property on a directory tree called ‘lock’:

svn propset lock

Commit this property to the repository (note that 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!

    • Perform an ‘svn update’ on your working copy whenever a colleague commits a change that may affect you.
    • Commit frequently – this will reduce the complexity of conflicts, when they do occur.