Subversion, Branching and LabVIEW Project

[Tom Bress]

I've just started using Subversion and TortoiseSVN, and I've got a question. I've organized my vis into projects and have placed them in the trunk of my repository. If I make a branch and open a project in the branch it looks like the sub-vis are all still linked to the trunk. The cross-links did not migrate to the branch. That makes branching inconvenient. Is this just a problem with Subversion? I don't have PushOK installed, LabVIEW doesn't know I'm using source control, and I do all of my source control operations outside the LabVIEW environment. Does this problem exist in supported source control packages like Perforce? Thanks.

[Omar Mussa]

QUOTE (Tom Bress @ Jun 18 2008, 07:42 AM)

If I make a branch and open a project in the branch it looks like the sub-vis are all still linked to the trunk.

Did you do a 'Switch' to the branch? Unless you switch to the branch, you are still working in the trunk.

Typically, the SVN hierarchy looks like this:

trunk\project\...

tags\tag_x\project

branches\branch_x\project

TortoiseSVN will keep your repository pointing to wherever you did a checkout from unless you do a 'Switch' command (it is available from the TortoiseSVN right click menu in Explorer).

[Tom Bress]

Yes, I did a switch to the branch. Then when I tried to open the main vi from within the project I found that the main vi couldn't find the sub-vis, apparently because it was looking for them in the trunk and not the branch.

QUOTE (Omar Mussa @ Jun 18 2008, 10:52 AM)

Did you do a 'Switch' to the branch? Unless you switch to the branch, you are still working in the trunk.

Typically, the SVN hierarchy looks like this:

trunk\project\...

tags\tag_x\project

branches\branch_x\project

TortoiseSVN will keep your repository pointing to wherever you did a checkout from unless you do a 'Switch' command (it is available from the TortoiseSVN right click menu in Explorer).

[Jim Kring]

QUOTE (Tom Bress @ Jun 18 2008, 08:47 AM)

Yes, I did a switch to the branch. Then when I tried to open the main vi from within the project I found that the main vi couldn't find the sub-vis, apparently because it was looking for them in the trunk and not the branch.

Hi Tom,

It would be helpful if you could describe a couple things:

1) What does your repository folder structure look like (with respect to trunk, branches, and tags)?

2) What does your working copy folder structure look like?

Thanks,

-Jim

[Tom Bress]

BTW, I enjoy your Thinking in G blog. My repository looks like this:

>LabVIEW Repository

>>branches

>>>MyBranch

>>>>Applications

>>>>VI Library

>>tags

>>trunk

>>>Applications

>>>VI Library

My working folder contains just the MyBranch:

>Applications

>VI Library

QUOTE (Jim Kring @ Jun 18 2008, 12:10 PM)

Hi Tom,

It would be helpful if you could describe a couple things:

1) What does your repository folder structure look like (with respect to trunk, branches, and tags)?

2) What does your working copy folder structure look like?

Thanks,

-Jim

[James N]

We had a similar problem working with braches early on.

Our repo is structured like so:

../svn/scc/ProjectFiles/Project_xyz/Trunk/

../svn/scc/ProjectFiles/Project_xyz/Branches/

The working copy on our hard drives looks like

..\ProjectFiles\Project_xyz - Pointing to code from the /trunk or /brach directory on the repo.

Do not include \trunk or \branch in this path! This got us the first few times too. LabVIEW VIs know the absolute path to subVIs. If you change the absolute path to any subVIs, things can't be found. As you know.

It's also important that any one else co-developing software keep the exact same directory structure on their hard drive.

We do not have the \trunk revision and the \branch revision checked out on the same computer. You work with one -or- the other at any given time.

-James

[jdunham]

QUOTE (James N @ Jun 18 2008, 10:00 AM)

We had a similar problem working with braches early on.

Our repo is structured like so:

../svn/scc/ProjectFiles/Project_xyz/Trunk/

../svn/scc/ProjectFiles/Project_xyz/Branches/

The working copy on our hard drives looks like

..\ProjectFiles\Project_xyz - Pointing to code from the /trunk or /brach directory on the repo.

Do not include \trunk or \branch in this path! This got us the first few times too. LabVIEW VIs know the absolute path to subVIs. If you change the absolute path to any subVIs, things can't be found. As you know.

It's also important that any one else co-developing software keep the exact same directory structure on their hard drive.

We do not have the \trunk revision and the \branch revision checked out on the same computer. You work with one -or- the other at any given time.

-James

First off, you should not be having these problems. You don't need to switch to Perforce. Something is going wrong.

I don't agree with James, LabView should only be keeping relative, not absolute, paths to each VI.

I keep checkouts on my hard drive from a half-dozen active branches of the same code base, and they don't get cross-linked. Of course I am somewhat careful to make sure there are no links outside a give working copy except to the LabVIEW installation folder (vi.lib).

I can open up multiple branches at the same time, as long as I rename one of the lvproj files (I usually revert afterwards rather than checking the renamed lvproj into SVN).

I can move the working copies of any branch anywhere on my computer and it will open just fine, though all developers on our team do keep the same hard drive layout to make builds easier.

Make sure you are double-checking the repository location of files you are opening by checking in the subversion tab of the windows file properties display.

Look at your VI hierachy with full paths turned on, and make sure that all vis are inside your current working copy or else in vi.lib.

Good luck, and if you have some more information or some samples, we can probably help some more.

[Jim Kring]

QUOTE (Tom Bress @ Jun 18 2008, 09:56 AM)

BTW, I enjoy your Thinking in G blog. My repository looks like this:

>LabVIEW Repository

>>branches

>>>MyBranch

>>>>Applications

>>>>VI Library

>>tags

>>trunk

>>>Applications

>>>VI Library

My working folder contains just the MyBranch:

>Applications

>VI Library

Tom,

> BTW, I enjoy your Thinking in G blog.

Thanks, I enjoy writing it and am very happy to hear that others enjoy reading it

> My repository looks like this...

I agree with jdunham -- I don't see anything wrong with your repository or working copy setup that would inherently cause linkage issues. The problem probably has to do with with accidental cross/bad linkages. Did you ever have multiple working copies checked out that you were working on at about the same time? I'm like jdunham -- I commonly have the trunk and multiple branches checked out at the same time in sibling folders, but I'm extremely cautious/concious about VI linkage.

-Jim

[Tom Bress]

Thanks, your assurance that something is wrong and that I don't need to switch to Perforce is exactly what I was looking for. As I said, I'm new at source control and I wasn't sure if my problems were due to something I did wrong or something inherent in Subversion. I'll go back and try again. Thanks guys, for all the help.

QUOTE (jdunham @ Jun 18 2008, 01:21 PM)

First off, you should not be having these problems. You don't need to switch to Perforce. Something is going wrong.

I don't agree with James, LabView should only be keeping relative, not absolute, paths to each VI.

I keep checkouts on my hard drive from a half-dozen active branches of the same code base, and they don't get cross-linked. Of course I am somewhat careful to make sure there are no links outside a give working copy except to the LabVIEW installation folder (vi.lib).

I can open up multiple branches at the same time, as long as I rename one of the lvproj files (I usually revert afterwards rather than checking the renamed lvproj into SVN).

I can move the working copies of any branch anywhere on my computer and it will open just fine, though all developers on our team do keep the same hard drive layout to make builds easier.

Make sure you are double-checking the repository location of files you are opening by checking in the subversion tab of the windows file properties display.

Look at your VI hierachy with full paths turned on, and make sure that all vis are inside your current working copy or else in vi.lib.

Good luck, and if you have some more information or some samples, we can probably help some more.

[jdunham]

One probable cause is a LabVIEW annoyance. If you are editing your code in the BranchA working copy, and then you close it and open your BranchB working copy by double-clicking the lvproj file or grabbing it from the recent files list, then when you use the Open... or Save As... functions, you usually end up browsing in the folders of the wrong branch! This is because LabVIEW only remembers the most recent folder you used with the file dialog box whether you are opening a VI, or accessing a data file when your program is running (I've complained many times about this).

Of course in many cases, the wrong branch looks indistinguishable from the right branch, so if you don't inspect the file dialog box to see the complete path, it's very easy to save or load VIs from the wrong working copy. You have to be very vigilant. There is a lot NI can do to help this, but it doesn't seem to be much of a priority. I think they don't want to second-guess the user's on-disk folder layout, but this makes it very easy to make a mistake.

OK, so if you are already cross-linked, the best thing to do is to move the working copy to a completely differerent place on the hard drive to make sure LabVIEW's relative path links can't find the cross-linked VIs from the other working copies. Make sure the working copy is moved to a different level (number of folders from the root) to confuse the links. Then when you load, will still have to re-link a lot of the VIs yourself, but when you are done hopefully everything is fixed. Of course you want to immediately Save All and then do an SVN commit.

Godspeed

[PaulG.]

QUOTE (Tom Bress @ Jun 18 2008, 10:42 AM)

I've just started using Subversion and TortoiseSVN ...

Good luck with that. Subversion/TortoiseSVN has it's critics. Even over here.

[crelf]

QUOTE (Tom Bress @ Jun 18 2008, 10:42 AM)

I've just started using Subversion and TortoiseSVN...

I really like Subversion and Tortoise/SVN, mostly because of the extension of the windows shell. That said, I'm a user - I have an IT department that takes care of all of the little issues with the package pair. I don't need to know (nor want to know) how they work, just as long as they do I suggest maybe getting your IT department involved (if you have one )

[Jim Kring]

QUOTE (crelf @ Jun 19 2008, 09:46 AM)

I really like Subversion and Tortoise/SVN, mostly because of the extension of the windows shell. That said, I'm a user - I have an IT department that takes care of all of the little issues with the package pair. I don't need to know (nor want to know) how they work, just as long as they do I suggest maybe getting your IT department involved (if you have one )

Wow! You're IT dept takes care of stuff? That's great! I thought IT just told people not to install software, prevented them from accessing web content, held onto new computers until they become obsolete, and walked around the buildings searching for "unauthorized" equipment plugged into the network.

[crelf]

QUOTE (Jim Kring @ Jun 19 2008, 12:55 PM)

I thought IT just told people not to install software, prevented them from accessing web content, held onto new computers until they become obsolete, and walked around the buildings searching for "unauthorized" equipment plugged into the network.

Not that you're bitter or anything! Yep, my IT department ROCKS! :thumbup:

[Rolf Kalbermatter]

QUOTE (Jim Kring @ Jun 19 2008, 12:55 PM)

Wow! You're IT dept takes care of stuff? That's great! I thought IT just told people not to install software, prevented them from accessing web content, held onto new computers until they become obsolete, and walked around the buildings searching for "unauthorized" equipment plugged into the network.

Well, if you are talking about IT departemetns of big multi billion dollar companies that might happen. But in a smaller company of 20 or so developers if the IT departement gets an annoyence they get a problem very fast

I've been bitten by IT departements at customer sites being more difficult then they should have been IMHO, but if our own would be to difficult they would have a problem.

Rolf Kalbermatter

[crelf]

My IT Department's so awesome, they just announced a series of lunch 'n' learn sessions where they'll be covering some more advanced tool topics (advanced sharepoint, etc), and they actually asked the engineers what they would like to have covered. As a consequence, an advanced Subversion class isn't far away.

[Jim Kring]

QUOTE (rolfk @ Jun 21 2008, 01:06 AM)

Well, if you are talking about IT departemetns of big multi billion dollar companies that might happen. But in a smaller company of 20 or so developers if the IT departement gets an annoyence they get a problem very fast

I've been bitten by IT departements at customer sites being more difficult then they should have been IMHO, but if our own would be to difficult they would have a problem.

I'm actually not bitter. I just couldn't pass up an opportunity to have a little fun at the expense of IT folks. Yes, this problem is really only an issue for some large organizations.

QUOTE (crelf @ Jun 21 2008, 04:18 AM)

My IT Department's so awesome, they just announced a series of lunch 'n' learn sessions where they'll be covering some more advanced tool topics (advanced sharepoint, etc), and

they actually asked the engineers

what they would like to have covered. As a consequence, an advanced Subversion class isn't far away.

Cool! If you learn anything valuable, let us all know.