lyonkingdom.com
Greg

SVN: Relocating your checkout

My company has been doing a lot of cleaning house lately and one of the much-needed fixups has been to set up a new server to host our SVN repository. As a result we have to re-point lots of checkouts at the new server. It’s a very simple process using either of two commands. The first is svn switch –relocate, the second is simply svn relocate.  [note that svn switch –relocate is deprecated in 1.7! Use svn relocate going forward!]

Usage is simple, but it’s important to get the URLs correct!

svn switch --relocate http://old.server.url/trunk http://new.server.url/trunk

This is the 'new' 1.7 way:
svn relocate http://old.server.url/trunk http://new.server.url/trunk

It’s also worth noting that you cannot switch branches while you relocate. For instance, if you need to move to a new server AND switch to a branch, do it in two separate steps.

Refer to the svnbook for more information:

http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.switch.html
http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.relocate.html


Posted by Greg on February 5th, 2013 :: Filed under Programming,Subversion

Netbeans 7 with(out) Subversion 1.7

This week I reinstalled my OS (long overdue!) and while I was at it got the latest releases of many pieces of software I use. These updates included both NetBeans 7.0.1 and TortoiseSVN 1.7.1.   Then I used TortioseSVN to check out a project and opened the project in NetBeans.  Next time I started NetBeans I was presented with the following message:

org.tigris.subversion.javahl.ClientException: The path ‘C:\Users\path to my project‘ appears to be part of a Subversion 1.7 or greater
working copy.  Please upgrade your Subversion client to use this
working copy.

After some web searching I realized that the upgrade to Tortoise 1.7.1 meant that I was now using the 1.7 Subversion client…which has some significant differences from the 1.6 client.  It also became apparent that NetBeans hasn’t yet upgraded to Subversion 1.7, but they will do-so soon.  

Here is a link to the story, with some work-arounds if you’re interested:  http://netbeans.org/projects/versioncontrol/pages/Subversion1_7.  I’ve decided I’ll use only TortoiseSVN for my SVN Needs until the NetBeans release that supports SVN 1.7 comes along.


Posted by Greg on November 17th, 2011 :: Filed under Programming,Subversion

SVN best practice #1: Check status before updating!

I maintain several websites as Subversion Checkouts.  I’ve had great luck with this as long as everyone on my team follows a few rules, and I thought I’d start saving & sharing some of them here.  This brief article explains the use of a couple of key SVN commands.

One of the things I’ve gotten in the habit of lately is to check the version of each and every file that I’m about to update whenever I do a big server update like we did last night for a busy website.  In this case it was VERY helpful to have done-so because I accidentally released a new beta version of  a few files that our client hadn’t approved yet.  Since I have the ‘list’ of all files that I’ve changed it’s quite easy to revert a few if necessary.  It works very well.

In brief, here’s what you do:
Before any update, check the status of all files with this svn command:
svn status -u
The status command with the -u option tells SVN to go compare everything locally to what’s in the repository.  You get output like this:
    *   3362   new_feature/feature.msi
    *   3362   new_feature/feature.exe

Any file with a * will be updated if you perform an SVN update, but it also tells you what version you’re currently on.  Then I updated my website to v3450 (including the not-ready-for-prime-time files).  Once I realized my error it was a simple matter to do an svn update to a revision as follows:

svn up -r3362

I performed this update right inside the ‘not-ready-for-prime-time’ folder and it caused these files to update back to the revision closest to 3362.  BAM!  Done and Done.  Note that this update-to-revision is not sticky, so I’ll have to be careful if I update the server again before these particular files are approved.  Also, note that I’ve ignored another best-practice here which is that I should have had my developer put this beta area on a branch, which would have avoided this issue all-together; but that is a topic for another post.

SVN Status can also tell you other important information, here are a couple cases:
?             feature.back
The ? lets you know that this file hasn’t ever been checked in to SVN.
M   *  3362   help.php
this file has been Modified (M) locally without being checked in AND is modified (*) in SVN.  Watch out for potential conflicts!

I really, really don’t like to have me or my programmers editing files right on the production server except in dire circumstances, so I usually go have a talk with someone about it whenever I find these types of entries.  I also make sure to clean them up right away once I notice them.

Anyway, I hope you found this helpful.


Posted by Greg on October 17th, 2011 :: Filed under Subversion,Tips