TortoiseSVN Right-Click Drag and Drop

Posted on Tuesday 3 April 2007

TortoiseSVNIf you don’t know what subversion and TortoiseSVN are, you’re really missing out. Subversion is on the way to becoming the most popular source code control tool. (And, you don’t want to be left out, do you?)

For those of you who do know about these tools, I’m going to show you something that will probably make you think to yourself, “Wow! That was hiding right under my nose, this whole time? (And, for those of you who don’t know about these tools, hopefully this will peak your curiosity and you’ll check them out.)

But, first, let’s take a quick step back…

Many people overlook the right-click drag and drop menu in Windows Explorer, because there is not a lot of functionality there. To see what I’m talking about, do the following:

  1. right-click on a file (press and hold the right mouse button, but do not release it as you would, normally, to see the context-menu)
  2. (with the right mouse button still pressed) drag the file to another location
  3. release the right mouse button

You should see the context menu shown, below:

Right-Click Drag and Drop

This context menu allows you to choose whether you with to create a copy in the target location, move the file to the target location, create a shortcut in the target location, or cancel the operation.

That’s pretty nice, but it didn’t blow your mind, right? Well, here’s where it gets really interesting…

TortoiseSVN has added some extremely useful options to this right-click drag and drop context menu. And, these fly under the radar of most TortoiseSVN users. Here are some cool features.

When (right-click) dragging and dropping a working copy (revisioned) folder into another working copy folder, you get the following context menu:

Working Copy to Working Copy

I’m not going to explain each of these, but basically they provide easy ways to move and copy working copy files and folders around inside your sandbox — the SVN Move operation will probably save users the most time. After choosing one of these options, you can commit the changes to make them permanent (or revert them to restore the sandbox to its previous state).

I am so glad that I learned about this trick. It really makes reorganizing files and folders a lot less painful. And, source code control tools should be easy to use, if we expect people to use them.

Using Subversion in LabVIEW? The JKI TortoiseSVN Tool for LabVIEW makes it easy by letting you use TortoiseSVN from inside your LabVIEW Projects and VIs.

Subversion and LabVIEW in the Enterprise : If your organization uses LabVIEW and you would like help deploying Subversion in your organization, consider hiring JKI to help get you started. You can contact us via our website.


8 Comments for 'TortoiseSVN Right-Click Drag and Drop'

  1.  
    Todd
    April 3, 2007 | 5:32 am
     

    I currently use Micrsoft Visual SourceSafe, but I would like to switch to an open source solution. It would appear that NI has not tested Subversion with Labview, but CVS has been tested with the PushOK Windows client. While there currently are many short commings with source code control integration into LabView (can’t have a different repository per project) I like a lot of the integration features. Have you tried integrating it with LabView, check in and out form project, for example?

  2.  
    April 3, 2007 | 7:55 am
     

    I considered moving to subversion. I asked our IT department if we already have a subversion service running. I was told that yes we do but there is a flaw in subversion and you should consider using another product. This flaw turned out to be a fact that subversion doesn’t support renaming files but instead files get copied and the original gets deleted. Does anybody have experience on the practical implications of this flaw in LabVIEW development.

    Second issue I’d like to raise is the fact that LabVIEW requires all the files to be renamed or moved in LabVIEW so that links between files don’t get meshed up. This is especially important when using LabVOOP. On the other hand I think subversion requires files to be renamed or moved in subversion so that the revision history doesn’t get meshed up. How these two programs interact in this respect.

    Third issue I’d like to raise up is the fact that LabVOOP requires often recompiling the whole project. As a result each file in the project, even the files you didn’t edit, gets changed. How does this affect the usage of version control software.

    -= EXPRESSIONFLOW =-

  3.  
    April 3, 2007 | 7:59 am
     

    Todd: I use TortoiseSVN as my SCC client. I don’t use the LabVIEW Project Environment’s SCC capabilities (yet), due to the fact that LabVIEW SCC settings are global and not per project. BTW, PushOK makes a Subversion client, too.

  4.  
    Guillaume Lessard
    April 3, 2007 | 12:39 pm
     

    In response to Tomi’s questions:

    1. As far as I’m concerned this is an annoyance rather than a show stopper. The real effect is that when you try to go to a revision that is prior to a rename, you may get an error and you need to browse the repository to get the right filename. This is more an issue for directories than files. I rarely rename files anyway. The other two issues are worse.

    2. Renaming files is a multi-step process between LV and SVN. For this reason as well as #1, I try to avoid having to rename files.

    3. Pre-LabVOOP, I have avoided much of these spurious changes by locking my VIs. I wish it were possible to save the compiled code in a parallel file hierarchy… the project file must make this possible!

  5.  
    Alvin Moore
    April 3, 2007 | 2:10 pm
     

    Jim,
    I had already discovered the way-cool drag and drop stuff in Subversion. It is indeed powerful and useful. I’d appreciate seeing more articles here on subversion and LV, especially given your ad above about having JKI come help you with subversion and LV in the enterprise.
    I use subversion with LV, don’t use LV’s built in version control, and haven’t used the LV OOP much yet so that stumbling block has not hit much.
    I read somewhere that you should not check in your builds into the version control system. So built apps (builds) in LV are not checked in. I can see why this is, because they are huge, but plenty of times it feels like that would be the way to go. That way, I have an exact copy of the build I deployed on such and such date. I was wondering what ya’ll did at JKI. Are you willing to give any general usage pointers on your blog? Thanks.

  6.  
    April 3, 2007 | 2:24 pm
     

    Alvin (and others): I would be happy to write articles on these topics — they are exactly the type of thing that I had in mind. Regarding putting built EXEs (or installers) into SCC, this is not necessarily bad, but is not generally done. I’ll write more about my thoughts on this in a full-fledged article in the coming week (or two). Thank you.

  7.  
    Yen
    April 11, 2007 | 11:41 am
     

    I would also be on the bandwagon of people wanting to see more SVN related posts.

  8.  
    April 12, 2007 | 9:03 am
     

    Hi, Everyone. Due to the large number of requests for articles on SVN, I have just posted an article called Creating a local Subversion repository with TortoiseSVN. Enjoy :)

Leave a comment

(required)

(required)


Information for comment users
Line and paragraph breaks are implemented automatically. Your e-mail address is never displayed. Please consider what you're posting.

Use the buttons below to customise your comment.


RSS feed for comments on this post |

 

Bad Behavior has blocked 2217 access attempts in the last 7 days.