Project conflicts using SVN

[mirode]

I have two systems with LV2014 working on the same project using TortoiseSVN. I use one system at a time for edits then make a SVN commit, then switch to other system, update my project directories and continue working there, while the 1st system is being used for testing.

Whereas it generally works (but needs significant amount of time for loading and compiling the VIs in each iteration) I often get the error that some VIs from the OpenG package could not be loaded. Please note that I have all of the necessary packages properly installed on both machines.

My workaround is to manually find affected VIs on the OpenG palette and place them somewhere on a block diagram, then LV asks me if I want to use these VIs in replacement for the missing project items, which I confirm and everything is OK.

Why is LV unable to locate these VIs in its own palettes and link them properly? Is there a better workoround?

I seem to have a similiar problem with the DLLs. At "random" times after a SVN update all of my VIs using the call library node loose track of the dlls (broken arrow), even if the "Library name or path" field shows correct location and library. I know there have been several threads about this last issue but in my case if I manually go to to this location and manually select the library at exactly the same place, then klick OK then everything is working. But I have to repeat this for every single VI using the DLL....

Thanks in advance for any suggestions.

[mikeporter]

Make sure all the paths are exactly the same on both systems. The root drive letter can be different, but otherwise they should be the same for all components.

Is the shared code under SVN control as well?

Mike...

[Bob_Schor]

Are you using LabVIEW Project?  I am assuming both systems have similar LabVIEW installations (i.e. you let LabVIEW install itself where it wanted), and both systems have the same OS (so the LabVIEW binaries are in identical folders).  I'll also assume that you have used VIPM to install OpenG in its default place.

I do what you describe all the time, and (almost) never have a problem (except when I forget to "Update First, Commit Last").  I assume that all of the VIs that you are creating are being saved in the top-level folder that is the SVN Working Copy folder.  You can check to make sure a VI didn't "sneak into the mix" from outside by turning on Show Item Paths from the Project Menu on the Project Menu Bar.  You can also look at what shows in Dependencies to see if something "unexpected" is being referenced.

Sometimes if things get really out of whack, another thing to try is to Commit on Machine 1, rename (you will be deleting it soon) the Working Copy on Machine 2, then doing a fresh CheckOut on Machine 2.  Verify that things are working, then delete the renamed "backup".

SVN has saved my behind numerous times ...

Bob Schor

[mirode]

Thank you for your replies.

I've actually been using diffrent paths on both machines...

Also, one of the machines has a 64 bit LV version vs 32 bit on the other (this obviously results in diffrent LV root folder for dependencies, although it is strange that it only affects just one package out of several).

Now I am tiding all these things up (takes some time) and will post once I am able to verify it again.

BTW, I obviously use LV projects and the package manager to install packages

[mikeporter · Accepted solution]

So why are you using the LV root folder to hold your code -- dependencies or not. A better solution is to creat a common workspace based off the PC's root drive. The structure that I prefer has a directory C:/workspace. Inside workspace are two subdirectories: Projects and Toolbox.

Toolbox is where I store all my reusable bits of code. This is also the directory at which you point your user.lib menu.

Projects contains a subdirectory for each unique project that you are working on.

For more information, check here: http://www.notatamelion.com/2014/10/13/conventional-wisdom/

Mike...

[Bob_Schor]

Yikes!  One thing I am extemely careful to do with LabVIEW and SVN is to be absolutely certain that I'm using the same LabVIEW version on my code.  In my case, it is all LabVIEW 32, but I have LabVIEW 2011 through 2014 (and soon, I hope, 2015).  I haven't ever installed LabVIEW 64-bit, but I'd be very surprised if (say) LabVIEW 2012 32-bit and LabVIEw 2012 64-bit VIs were identical.

One way to Have Your Cake and Subversion, too, is to have separate repositories for 32 and 64-bit code bases, with perhaps periodic tests (and I have no idea how to do this) to ensure the codes are essentially the same.  This sounds to me like a situation fraught with pitfalls ...

Bob Schor

[mikeporter]

If the OP has LabVIEW configured to separate the object code from the source, it shouldn't be a problem. Each system will have its own compiled objects.

The reusable stuff should be set to read only and the LabVIEW settings to not save automatic changes, and to treat read only as locked should be checked.

Mike...

[mirode]

I have applied most of your sugestions to my systems and at least for now it seems that of my problems are gone (have not had the possibility to test both ways yet).

BTW, actually, I am not using LV folders to hold my code nad have (maybe not that well structured as yours, but still) a separate folder structure based on the root. Good, this was diffrent on both machines, now it is the same.

However, LV folders are where LV holds the packages which cause conflicts when changing between 32 and 64 bit installations (OpenG in my case, not other packages though). Which still I do not understand why.

I will need some extra time to go through the your link in more detail, but I like the idea. Thanks.

[Bob_Schor]

You do not want the packages in your Repository!  Try to have your Working Copy consist only of your LabVIEW code that you are developing -- leave the "constant" things like the libraries deployed on the (various) machines that you use for development.  Note that because LabVIEW is "version-specific", if you open a LabVIEW 2012 32-bit Working Copy and manipulate it with either (a) a later version (say, LabVIEW 2014) or (b) a "different-bit" version (say, LabVIEW 2012 64-bit), if you commit this to the trunk, when you update it you will not be able to open it again in the original LabVIEW.

This is a (minor? major?) difficulty of handling LabVIEW in Tortoise SVN.  My solution (so far) is to try to keep a "standard" for most of my LabVIEW work.  In particular, I only use LabVIEW 32-bit.  When I am ready to move to a new version of LabVIEW, say from LabVIEW 2012 to LabVIEW 2015 (which I haven't done yet, but plan to do), I "tag" my current LabVIEW 2012 Working Copy, open the Working Copy in the new LabVIEW (e.g. 2015), do a Close All (which generally recompiles most of the VIs, and do the Commit, with a comment that I've moved the code to LabVIEW 2015.  Once all of my repositories have been similarly updated, I'm ready to use the new version.  If, for some reason, I need to "go back" to the old version, I can always just check out the Tag (and give it a new name).

Bob Schor

[mikeporter]

Bob, I'm afraid this is one where we are going to need to agree to disagree.

All your code should be in a repository -- though not necessarily the same one. Each project I work on has its own repository, plus another for me toolbox -- the reusable bits.

Combine that structure with the settings I gave before, and life is good.

Mike...