VirtualBox Article

[M.Julien]

Hi

Have you try to use a virtual machine with TortoiseSVN (on the host and on a virtual machine), without any problem ?

[mprimrose]

TortoiseSVN is a client used to access a Subversion server which can either be on the same machine, on a different machine, or even running in a VM.  I have had the Subversion server on the host side of the machine with TortoiseSVN running on the VM side of the same machine.  I have also ran the Subversion server in a VM.  The VM's ethernet connectivity must be set up properly for the TortoiseSVN to access the Subversion server.  If you can open a webpage on the VM you can get to a Subversion server.

More on Subversion and TortoiseSVN here:

http://decibel.ni.com/content/groups/large-labview-application-development/blog/2010/03/29/using-sub...

Mark

[johnny_icon]

I typically keep all my source code one one machine, and map network drives to that location, including mapped drives on the VM. That way I only have one Tortoise client to update, and don't have to maintain updates on the VMs.

[Jean-Louis]

We mainly use notebooks for LabVIEW development.

On each notebook we have two partitions:

> C:\ for operating sytem and applications

> D:\ for data

In order to manage different LabVIEW environment, we are thinking of using different virtual machines for the system partition and keep the D:\ partition (data) visible from the VM through VirtualBox shared folder.

Question : are you doing the same ?

I have tried to install TortoiseSVN 1.6.7 on the main machine (Windows 7) and on the VM (VirtualBox)

Both are seeing D:\Data\Myprojet but the overlay icons are not correct on the machine which has not done the SVN extraction.

Question : did anybody meet the same problem ?

[mprimrose]

Jean-Louis,

This is a known TortoiseSVN problem.  http://tortoisesvn.tigris.org/faq.html#ovlsubst

Why are the overlay icons on SUBSTed drives messed up?

If your working copy is on a SUBST drive the icons might be mixed up.

The problem arises because the cache tries to fetch the status for two "different" locations at the same time, but those locations are actually the same so there are two status fetchings for the same working copy at the same time.

There is an easy way to solve this: just exclude the original path from showing overlays (settings->icon overlays->exclude paths).

For example, if you have mapped \\station\folder\wc to g: then put "\\station\folder\wc*" as the exclude pattern.

Another way to make the overlays work is to set the "Status cache" setting from "Default" to "Shell".

[johnny_icon]

Just wanted to update this thread with some new info:

I've recently adopted the VirtualPC feature of Windows7. I still use VirtualBox on other OS's, but Windows7 has a virtualization feature. This avoids the issue of using a license key (so you can use it elsewhere). I'm sure there are pros and cons to using each platform, but so far, they very similarly suit my needs, so I'm using the "integrated" one (I had to actually download VirtualPC and XPMode).

[DavidZ.]

This post is one year old, I hope to get some reaction all the same...

To giawerx:

In your (a bit older) post in the Mobile interest group about using the PDA toolkit with Virtual Machines you wrote, that you had to move your data to the VM to make it work. On my side I am on that point and this works fine, including Tortoise SVN.  Your installation article helped me a lot to set all up. Thank you very much!

Now in your newer post from Apr 3 2010 in this discussion you wrote: "I typically keep all my source code on one machine, and map network drives to that location, including mapped drives on the VM. That way I only have one Tortoise client to update, and don't have to maintain updates on the VMs."

Did I understand you right, you keep your labview project code version controlled on the physical drive of your PC, while working on it from the VM? Because that's exactly what I'd like to do.

How did you manage to get around the problems when working on your labview project files outside the VM? Or is there still no solution?

So far I didn't manage this, as described in my question to Patrick's "A couple of tricks for working with VirtualBox" . I always get the Error "Labview: File permission error."

Thanks a lot for any recommendation!

[johnny_icon]

Hi Dazur,

I've switched from VirtualBox to running Virtual PC in Windows 7 (for various reasons, but mostly because it is now native). Although I ocassionally keep source code on the VM, I ususally try to keep it on the physical machine's hard drive, and map that resource as a shared drive to the VMs. I ocassionally run into network issues and errors. I have found this link to generally fix my problem (tweaking a registry value on the host machine - about halfway through the article):

http://www.edugeek.net/forums/networks/8972-strange-slow-file-download-via-unc-mapped-drive.html

The Registry value they mention is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DisableTaskOffload = 1

I'm not sure this will help you on VIrtualBox, but I thought I'd share it so you can try it out.

[DavidZ.]

Hi giawerx

The registry entry mentioned unfortunately didn't help me and I can't use Windows 7 yet to use its Virtual PC.

But I found another workaround from cpschnuffel in the VirtualBox Forum . Don't know if this way is obvious, but it helped me, so instead of using the Shared Folders from VirtualBox I set the SVN-controlled-folder with the Labview-project-files located on my guest-XP's drive to "Share this folder" and then I mapped from inside the XP-VM a network drive to that folder. I can work now with Labview 8.5.1 on the files outside the VM, all SVN-controlled, readable and writable from the VM- and the guest-side without any error messages. (Apart from the work on my Labview-project-files I still use the VM's shared folders.)