LabVIEW and SVN

[PaulG.]

"... As mentioned above, the problem with recompiling VIs when changing a global or SubVI connector pattern is not a version control issue, but LabVIEW behavior.
But I disagree with tst that committing every single recompiled VI is useful as this might cause lots of conflicts when multiple developers are working on the same project. We're using conditional disable and different targets so VIs recompile basically always. I try to keep track of the changes and commit only VIs which I really did modify (keeping track of the changes is anyway good practice so one can write a meaningful log message). From time to time, we do a mass compile (for a specific conditional disable symbol) and commit all modified VIs to have everything consistent."

Holy cow! All the workarounds you had to come up with just to make it work!

I think you made my point for me better than I made it myself.

[dan_u]

Well then please tell me ANYTHING I said that is related to SVN. The "workarounds" are just LabVIEW things, they are not connected to SVN. Would be the same with any other version control system.
It requires some effort to setup and use any version control system. If you're not willing to take this effort, well, then stick with shared directories or whatever your solution is.

Daniel

[Andy Peters]

What I meant about "That's not a good use of a source-code control system" is that rather than all developers sharing the same working copy, each developer should have his/her own working copy.

Sharing a working copy can lead to all sorts of problems. Just imagine if two users are modifying the same VI. I save it first, and my changes aren't reflected in the copy in memory on your computer, so your changes overwrite mine (if the OS will even allow this). Who commits? What happens if I do an svn update while you're working on the project? etc etc.

-a

[Andy Peters]

"Holy cow! All the workarounds you had to come up with just to make it work! I think you made my point for me better than I made it myself. "

The problems you are chafing against are LabView problems, not Subversion. You'd have the exact same problems with any revision-control system.

-a

[tst]

---

PaulG. wrote:

I had no trouble at all with VSS but our IT guys didn't like it.

I would have to agree with your IT guys. I'm probably not using it right, but I was asked to work with a client's VSS system. At first I tried using it from inside LabVIEW (7.0), but I couldn't get it to work properly, so I moved to using the file structure directory, as I was used to from SVN.

In this case, VSS was pretty hopeless for the way I was using it. Since this was during the development phase and my changes often affected many VIs, it became extremely annoying to check changes in, because VSS would have to start by comparing the entire hierarchy and then it would have to compare each of the changed files to check it in. That means transferring all the binary data across the network and comparing it and with roughly 15-20 MB of source code that would take time.

Perhaps working the way Dan suggested would help, but I didn't really consider it. Since I was practically a lone developer at that client's, I just checked everything in at the end of the day (a 5 to 10 minute operation).

Perforce is pricey.

---

I'm pretty sure Perforce has a free version with a small number of licenses. It should work for small teams.

---

dan_u wrote:
But I disagree with tst that committing every single recompiled VI is useful as this might cause lots of conflicts when multiple developers are working on the same project. We're using conditional disable and different targets so VIs recompile basically always.

---

This might be an artifact of how we work. We still use 7.0, so we don't use the CDS and even when working with targets (although it has been a while since I last did that), we just compile a stand alone executable for the target. We haven't had a chance to have multiple developers work on the same parts of the same project at the same time, but I feel that hard drive space and the data transfer through our LAN are cheaper than the headaches involved with making sure people don't have different versions.

I suspect we would keep doing the same, but I suppose it is possible we would work differently if we came up against the same conditions as you.

[PaulG.]

"The problems you are chafing against are LabView problems, not Subversion. You'd have the exact same problems with any revision-control system."

That's possible - but I seriously doubt it. When I was working with VSS any LV-related problems and workarounds might have already been implemented before I started using it. But that was simply not the case when we moved over to SVN. And if I had been around when we were getting VSS implemented but had had just as much trouble getting it to work I would have bitched just as much and just as vocally.

I refuse to believe that NI allows LV to remain this difficult to source control.

[minnellac]

I think there may have been a misunderstanding here. I believe what gt5816v was saying was that they map a local directory to a drive letter (not a network share) for each developer so that each developer's working copy is located at the same path. It seems like a novel approach, but personally, I haven't really had a problem with that aspect of SVN and LabVIEW.

I use TortoiseSVN as well with LabVIEW, and I have to say it works pretty well for me. My perspective may be colored by the fact that I was not using any SCC before SVN, so it seems like a definite improvement to me. It's the same reason why people who go from normal TV to time shifting with a cable company supplied DVR (SA8300, for example) think it's an improvement, while my previous experience with Tivo gives me the perspective to say that the cable company supplied DVR is a piece of crap...

anyway, there's my 2c
Chris

[tst]

Paul, you still haven't said what Subversion-specific problems you ran against.

Whether you believe it or not is irrelevant - LabVIEW does keep the compiled code in the same file as the source code and does recompile at times where you might not expect it. TSVN simply has the design of working through the Windows shell and displaying all changed files very prominently. Personally, I can't really see myself working with TSVN and not committing regularly. If I wouldn't, my Explorer view would be full of red exclamation marks. I suppose I could set it up not to show those icon overlays, but I happen to like them.

[Andy Peters]

" I think there may have been a misunderstanding here. I believe what gt5816v was saying was that they map a local directory to a drive letter (not a network share) for each developer so that each developer's working copy is located at the same path. It seems like a novel approach, but personally, I haven't really had a problem with that aspect of SVN and LabVIEW."

Ah, I see. I suppose you could arbitrarily decide that each user's sandbox is something like C:\Projects\projname so each user checks out the project into the same directory structure. I can see how that would help deal with LabView's insistence on marking things as changed because they were moved to a different path.

Now, you're completely hosed (at least with LV 7.1, dunno about 😎 if you have some subVIs that you track as their own projects and they're included in your main project using the svn:externals property. Obviously in that case the externals are checked out into a different location, and as such LabView thinks they're changed and it wants you to re-save them. The whole aspect of LabView thinking that a change in directory or path means that the VI has "changed" is outright hostile to reasonable version control. (My comment to a co-worker this morning: "It's fscking STUPID.")

"I use TortoiseSVN as well with LabVIEW, and I have to say it works pretty well for me. My perspective may be colored by the fact that I was not using any SCC before SVN, so it seems like a definite improvement to me. It's the same reason why people who go from normal TV to time shifting with a cable company supplied DVR (SA8300, for example) think it's an improvement, while my previous experience with Tivo gives me the perspective to say that the cable company supplied DVR is a piece of crap..."

I've also used VSS, CVS, bitkeeper and git and each has their strengths and weaknesses (OK, that's a lie; VSS has no strengths, only weaknesses and fatal flaws). I just prefer Subversion, due in no small part to the TortoiseSVN client.

As for the cable-suppled DVR versus a TiVo, I chose to build a DVR system based on a Mac mini, an Elgato eyeTV 200 and a big FireWire hard disk. That machine also acts as my Subversion repo server. Works well.

a

[Andy Peters]

"I refuse to believe that NI allows LV to remain this difficult to source control."

Believe it.

As another example, the Xilinx tools are also openly hostile to source control. You have to figure out which files are needed to rebuild a project. The .ise project file has gone from a text format to binary, and that binary can get quite large. And when you talk to the Xilinx FAEs, they all say, "I never use the GUI, I just use Makefiles and the command line." Still, for each version of their tools, you have to figure out what's changed in the build process and what ancillary files are needed.

At least Xilinx finally figured out how to make their tools reference VHDL sources from an arbitrary location, rather than forcing them to be copied to the main project directory. Now if only they could let you specify where to put temporary and report files, instead of dumping them into that main project directory.

-a