LabVIEW and SVN

[dan_u]

---

@C. Minnella wrote:
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.

---

Actually this might help in some cases. Usually it works just fine with relative paths, so we didn't care yet. Everybody uses his own local path. But Real-Time build specifications for instance just seem to use an absolute destination path. Looks like a bug to me. "Normal" build specifications work fine with relative build paths.

---

@tst wrote:

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.

---

I worked some time using the svn command line client - until a co-worker convinced me to use TSVN. I wouldn't want to live without it anymore

One thing that also causes some problems is the project file. It tends to be modified very quickly (for instance creating a new VI for a small test, then closing it again). So the .lvproj file is very likely to cause conflicts. Since it is an ASCII file (XML) svn will merge it. But this messes up the project file... We lost the build specifications several times due to that. Now we know so we can avoid that.

[minnellac]

"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 guess that is an annoyance. I use the externals property to share common code with many projects, and you are right, I am often prompted to save over the vi's that are used because of many reasons (open in newer version of LV, different path...). I either try not to save (this is where changing that preference in LabVIEW to not prompt to save for automatically updated files would probably help), or save and periodicially revert the externals directory so that all the exclamation points go away, or I just leave them there. The important thing to remember with them is not to commit any changes to the externals directory (particularly because I use the -r option to specify a specific revision when I use the externals property). I would like it if there was a way to prevent TSVN from offering to commit changes in a specific folder (Ignore doesn't work for directories that are already committed).

not to fall into a rathole, but with regard to the DVR, I looked long and hard at that solution, as well as Windows and Linux based solutions, and my conclusion was that there wasn't any way to get the same quality as Tivo without spending upwards of $1k (I don't have extra hardware just laying around). At the time I wasn't willing to pony up $800 for Tivo Series 3 (+200-400 for transfering my lifetime service) for hardware that wasn't capable of receiving SDV broadcasts... anyway, as a result I got the cheap option that really bites, and I am just waiting for something better to come around. There is talk of an upgrade to Tivo that will allow bi-directional communication and enable SDV and OD type content. Here's hoping 🙂

Chris

[tst]

---

C. Minnella wrote:
I would like it if there was a way to prevent TSVN from offering to commit changes in a specific folder (Ignore doesn't work for directories that are already committed).

---

Agreed. That's one of the things that kept annoying me as well. The closest I came to this was using the global ignore settings for the client, but they work on patterns (as opposed to folders or files) and they also work only on files which were never commited.

[PaulG.]

NI search is our friend:

http://zone.ni.com/devzone/cda/tut/p/id/4633

From this link the following:

"Source control integration with LabVIEW has been tested (emphasis mine) with Microsoft Visual SourceSafe, Perforce, Rational ClearCase, PVCS (Serena) Version Manager, MKS Source Integrity, and CVS with the Push Ok Windows client software."

I read over this paragraph 3 times but didn't see SVN mentioned.

The word for today is "tested". Something all of us should know something about. And with something as critical as source control software we should reserve our debates on products National Instruments has taken the time to investigate and TEST.

[tst]

I'm assuming Microsoft didn't specifically test LabVIEW fully to see that it runs properly on Windows (other than the Logo testing I assume the NI drivers have to pass). Does that mean that you should not use LabVIEW? The fact that NI did not officially test the SVN integration with LabVIEW does not mean you can't use it with or without the plugin.

You still haven't mentioned which problems YOU had with SVN. I want to hear about that because I use SVN. If you had objective problems, knowing about them could make my life easier.

[Andy Peters]

---

@PaulG. wrote:

NI search is our friend:

http://zone.ni.com/devzone/cda/tut/p/id/4633

From this link the following:

"Source control integration with LabVIEW has been tested (emphasis mine) with Microsoft Visual SourceSafe, Perforce, Rational ClearCase, PVCS (Serena) Version Manager, MKS Source Integrity, and CVS with the Push Ok Windows client software."

I read over this paragraph 3 times but didn't see SVN mentioned.

The word for today is "tested". Something all of us should know something about. And with something as critical as source control software we should reserve our debates on products National Instruments has taken the time to investigate and TEST.

---

From this link the following:

"Source control integration with LabView (emphasis mine) has been tested with Microsoft Visual SourceSafe, Perforce, Rational ClearCase, PVCS (Serena) Version Manager, MKS Source Integrity, and CVS with the Push Ok Windows client software."

The word for today is "integration." This means that National Instruments has integrated the Microsoft-defined plug-in mechanism for various SCC "providers." into LabView. Subversion (and Bitkeeper, and git) don't conform to this specification, and as such cannot just "plug in" to environments that conform to this.

Also note from http://digital.ni.com/public.nsf/websearch/26EC5904169430CE8625706E00743997?OpenDocument:

"This list of source control providers is not intended to list all compatible providers. (emphasis original) If a certain provider is not listed, it may or may not integrate with the LabVIEW 8.x PDS (emphasis mine). If a source control provider is compatible with the Microsoft Visual Studio .NET development environment, the source control provider should integrate with the LabVIEW 8.x PDS. Typically, source control providers that are compatible with the Microsoft Visual Studio .NET development environment should (emphasis mine) also integrate with the LabVIEW 8.x PDS." 

This means that the specified product ought to work within the LabView environment, but they also might not. These SCC options will also work outside of LabView, in whatever environment they typically provide (command line, custom GUI, whatever). All that this plug-in system does is provide a mechanism for LabView to call the command-line programs that actually do the SCC work. IOW, LabView does exactly what you'd do manually from the command line.

If you require your revision-control system to be integrated into your design environment, then Subverson is not for you, nor is BitKeeper or git. I don't particularly see a reason for this integration, especially on Windows, where the TortoiseSVN client is far superior to all others.

-a

[TCPlomp]

Yeah flamewar!

Well at work I use the MS VSS service and if I do a check in/out of a lot of items I have to refresh the 'Source Control' state to have the icons correct.
At home I use SVN via the PushOK proxy. And it works OK. The problem is that SVN and MS SCC definitions don't match!
SVN doesn't have a check-out but has a commit.
IMHO the commit works easier, but with the format that LabVIEW uses (embedded source and compiled code) a check is neater.
Only difficulty I had with the PushOK library is that the SVN repository needs to be non-accessible for anonymous users. You don't have the option to anonymously browse, and then do a logged-in an action (check in/out).
And the PushOK library always shows pop-ups, even when checking the status of files, so it's not very friendly to use inside automated check-in/release code parts (although I haven't looked at that very throughly.

Ton

[Andy Peters]

---

@TonP wrote:

SVN doesn't have a check-out but has a commit.

---

Of course svn has a checkout!

The command-line commands generally have an alias:

$ svn commit

is also

$ svn ci

(like "check in")

$ svn checkout

is also

$ svn co

which can be confusing, but these aliases are familiar to the CVS user 'cause they're the same.

-a

[dan_u]

I'm not completely familiar with version control terminology, but probably Ton means checkout and lock so others can't work on files that are checked out by somebody else. svn supports locking, but IMHO the standard svn behavior (everybody has a full local copy and can modify anything without server connection required for locking) fits perfectly for LabVIEW due to the earlier mentioned minor issues with recompiling VIs.

[PaulG.]

My problems with SVN were months ago, and it's something I would have preferred to forget. This list is not inclusive of my experience. The problems we had with SVN:

• My first clue: Two developers could "lock" the same VI and make changes. Just this fact alone goes against everything revision control software is supposed to accomplish. This was an issue I had to bring to the attention of IT. The way it was explained to me is that this was "default" behavior and the change/cluge/hack/workaround had to be implemented manually. IT fixed it, but what the hell was that all about??? In "source control" software no less???
• SVN indeed seemed to work OK when it was just me ... or maybe one more developer checking in, checking out, updating , etc. code into and out of the SVN repository. But the more developers that got involved, the more errors and headaches crept into the process.
• Checking out a subdirectory occasionally created errors when attempting to check it back in. My biggest problem with this was that I could have a subdirectory checked out and locked for a week at a time, make numerous changes to numerous VI's in the subdirectory, then if just ONE vi had a problem none of the others could be checked in until the error on the one VI was corrected.
• Although I had no idea what the problems others were having, I saw, on more than one occasion, IT looking over a developer's shoulder who was unsuccessful trying to check in updated code. Sometimes the entire directory had to be deleted, the previous revision reinstated then checked out again, the new code redone and checked back in.
• A developer would create a repository and it would be under his/her name. It would be there for months during a project. Then a few problems would arrise. IT and the developer would work and work trying to resolve it. Eventually it would be working again - but all the repositories would be under another name.
• I would get an error trying to check in some code. I would try the Tortoise/SVN - suggested solution. That would fix that problem but another would arrise. I would fix that. I could do this a half-dozen times then end up right back to the original error.
• It wasn't just me. Quite a few of us had trouble. I heard that the transition from VSS to SVN described as "painful" more than once from more than one individual.
• It got so frustrating, and I had heard it so often for so long that if I had heard that insipid Tortoise/SVN error sound ONE MORE TIME I was going to start taking hostages. I finally went into the Tortoise options and changed that particular .wav to a Homer Simpson "DOH!". That helped ... for a while. After that, when I tried to check in a list of VI's with an error in one of the first ones the error sound would go "DDDDDDDDDDDDDDD DOH!!!"
• If I was doing something wrong, and there are workarounds with all of these issues, I (or anyone else, for that matter) were not made aware of them. I eventually left that company and have no idea how it's working for them now. But I DON'T CARE.

I'm done. I feel better now.