Subversion is a popular open-source source control system.  In my last blog “Intro to SVN“, I gave some examples of how the SlikSVN commands work from the Windows Command Line.  ToirtoseSVN is a window shell menu and GUI for SVN.  After installing TortoiseSVN, you simply right-click on the file or directory, and the TortoiseSVN command appear.

Instead of using Windows Explorer, I use a handy tool called “Total Commander” which makes life easier and faster, so in the screen shots below, that is what you will be seeing.

I changed a file, then right-clicked on it, and selected “SVN Commit”.



Below, I’m showing the code in my short Powershell program, along with the TortoiseSVN Commit screen.  I typed in the reason for my commit (this is the same as doing SVN Commit -m “Add ABCTest to force future conflicts”.  I have a C:\Code\Demo copy of the source programs, and a C:\Code\Demo2 copy.  I needed two copies so I could simulate two people updating the same program, in order to simulate a conflict.



The results of the commit are shown below:



Now below, I try to do an “SVN Update” in the C:\Code\Demo directory. “SVN Update” is similar to “Get Latest” in TFS. It pulls the new code and code changes from the SVN database/library to your local disk/workspace.




The update fails because I had changed line 6 of C:\Code\Demo\Sample1.ps1 to conflict with the changes made and commited from C:\Code\Demo2\Sample1.ps1.  Thus the code in C:\Code\Demo\Sample1.ps1 needs resolution, usually by a Merge process.




I did a right-click, chose “Tortoise SVN” then “Merge” (menu selection not shown here).  Forgot to save that one.

I was kind of surprised by what it did.  It actually created several files in the C:\Code\Demo directory.


Then, in the directory, it preserved my code as Sample1.ps1.mine, and then added the last two releases (or commits) of that program, suffixed with “.r##” where the version number was 7 and 8 in my scenario.


the file called Sample1_Merge.ps1 looks like this:


At this point, you can use any external merge tool, such as WinCompare or the merge tool built into Total Commander.  Or, to use the tool built-in to TortoiseSVN, right click the source code file, select “TortoiseSVN” then “Edit Conflicts” (not Merge).   NOTE: if you use an external merge tool, then after you rmerge is done, you must select “TortoiseSVN” and then “Resolve”.




In my case, the built-in merge tool shows Sample1.ps1.r8 (release 8 from the repository) on the left, and Sample1.ps1.mine on the right.



Highlight the code you want, then click “Use Blocks” and select “Mine” or “Theirs” or the desired choice (screen shot not shown).

Then at the bottom, you see the results of the merge.



When happy with the results, click “Save” , then you have an option to “Mark as Resolved” or “Leave as Conflicted”.  If you are really done with the merge, click “Mark as Resolved”, and the files will be cleaned up (as shown in the following screen shot.  Perhaps you only had time to merge 1/2 the file, and you want to save it and continue tomorrow.  In that case, you could select “Leave as conflicted”.


When you “Resolve”, notice that the .r7, .r8. and .mine files are removed.


Enter your commit comments…


And now see that the version went form revision 8 to revision 9 – and that completes the process.




My client uses SVN (Subversion) instead of TFS; so something new to learn. In the past, I have had clients that used AccuRev and Borland’s StarTeam. So it would seem that 20% or more of my clients have not used TFS for source control.

I downloaded SlikSVN from, and used the free doc here to learn the basics. The doc is available both in PDF format and HTML.  In this blog, I will be sharing my “Introduction to SVN”, which is basically just trying some of the simple commands with a couple of small code files (I chose Powershell instead of BizTalk to keep it super simple.)

The first thing I had to do was to create a “Repository”. I chose the File System repository, which seems to be recommended. It’s also called an “FSFS-backed repository.”

C:\>svnadmin create SVNRepository

When dealing with with multiple users, you will also have to setup a web server and a URL. But for single machine, single user access, you can simply refer to the respository I created as file:///C:/SVNRepository.

I had two Powershell programs that I was using as demos. For example, Version 1 looked like this:

# Neal Version - SVN learning and exercises 
# Date Created: 12/22/2014 

Write-Host "Hello World " 
Write-Host "The End"


Then I added the date, and for small changes just changed the text inside the last "Write-Host" statement.

# Neal Version - SVN learning and exercises 
# Date Created: 12/22/2014 

$showDate = get-date  #added 12/22/2014 
Write-Host "Hello World $showdate" 
Write-Host "The Demo2 Change End" 




c:\Code&gt;svn import c:/Code/Demo file:///c:/SVNRepository -m "Initial Checkin"
Adding  (bin)  Demo\Sample1.ps1
Adding  (bin)  Demo\Sample2.ps1

Committed revision 1.

c:\Code&gt;svn checkout file:///c:/SVNRepository 
A    SVNRepository\Sample1.ps1
A    SVNRepository\Sample2.ps1
Checked out revision 1.

c:\Code&gt;svn status
svn: warning: W155007: 'C:\Code' is not a working copy
c:\Code&gt;cd demo

c:\Code\Demo&gt;svn status
svn: warning: W155007: 'C:\Code\Demo' is not a working copy


The problem above was that I left off the Path from the Checkout statement. The doc shows an example with no Path, so I found it rather confusing. Here is the corrected checkout:

c:\Code&gt;svn checkout file:///C:/SVNRepository C:\Code\Demo2
A    Demo2\Sample1.ps1
A    Demo2\Sample2.ps1
Checked out revision 1.


"SVN status" won't show anything until you change a file. I opened Sample1.ps1 with notepad, changed it, then ran the command. "SVN status" runs totally on the client without accessing the repository.

c:\Code\Demo2&gt;svn status 
M       Sample1.ps1 


One important note, when creating the Powershell programs using the "ISE" utility, it encoded them as UTF-16. This caused SVN to see them as binary, and I had to follow the advice of this StackOverflow post to solve the problem.

I changed the text of the final "Write-Host" statement in Demo2 and checked-it in using the "Commit" subcommand. The -m is required to specify the description of your changes.

c:\Code\Demo2&gt;svn commit -m "Demo2 update Write-Host"
Sending        Sample1.ps1
Transmitting file data .
Committed revision 5.

You can add the -u parm to the "Status" subcommand, and it will show you the files that are in need of update (with the *), i.e. this command now contacts the repository. Since I commited Sample1.ps1 in Demo2, I now switch back to my Demo directory, and see that Sample1.ps1 is out-of-date and in need of update from the repository.

c:\Code\Demo&gt;svn status -v -u
        *        3        3 neal.walters Sample1.ps1
M                4        4 neal.walters Sample2.ps1
                 3        3 neal.walters .
Status against revision:      5

So then I changed the same line of code in C:\Code\Demo\Sample1.ps1 and tried a commit:

c:\Code\Demo&gt;svn commit -m "Test conflict"
Sending        Sample1.ps1
svn: E155011: Commit failed (details follow):
svn: E155011: File 'C:\Code\Demo\Sample1.ps1' is out of date
svn: E160028: File '/Sample1.ps1' is out of date

I should have noticed above that "*" told me that Sample1.ps1 was out of date, and so I need to do an "SVN Update":

c:\Code\Demo&gt;svn commit -m "Test conflict"
Sending        Sample1.ps1
svn: E155011: Commit failed (details follow):
svn: E155011: File 'C:\Code\Demo\Sample1.ps1' is out of date
svn: E160028: File '/Sample1.ps1' is out of date

c:\Code\Demo&gt;svn update
Updating '.':
C    Sample1.ps1
Updated to revision 5.
Conflict discovered in file 'Sample1.ps1'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
        (mc) my side of conflict, (tc) their side of conflict,
        (s) show all options: m
Merging 'Sample1.ps1'.
Conflicting section found during merge:
(1) their version (at line 6)         |(2) your version (at line 6)
Write-Host "The Demo2 Change End"     |Write-Host "The End - Some other Demo
Select: (1) use their version, (2) use your version,
        (12) their version first, then yours,
        (21) your version first, then theirs,
        (e1) edit their version and use the result,
        (e2) edit your version and use the result,
        (eb) edit both versions and use the result,
        (p) postpone this conflicting section leaving conflict markers,
        (a) abort file merge and return to main menu: 2
Merge of 'Sample1.ps1' completed.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
        (r) mark resolved, (mc) my side of conflict,
        (tc) their side of conflict, (s) show all options: r
Resolved conflicted state of 'Sample1.ps1'
Summary of conflicts:
  Text conflicts: 0 remaining (and 1 already resolved)

Above, I selected option (2) for "use your version", causing my change to override the change made by the other "fake" person (i.e. the other directory where I changed the code differently. Then I had to further select "R" for "mark Resolved". After the merge and resolve, the commit works fine:

c:\Code\Demo&gt;svn commit -m "Update text in final msg"
Sending        Sample1.ps1
Sending        Sample2.ps1
Transmitting file data ..
Committed revision 6.

If all the above looks antiquated, I find it that same.Working with the command line utilities to me seems going backward, but yet I know some people love it. Hopefully, in the next blog, I'll show you the similar results by using TortoiseSVN, a graphical user interface which installs as a shell into the Windows right-click facility of Windows Explorer.  It is plug compatible with your existing repository, and you can switch back and forth between the command line and the Tortoise GUI anytime.