11-04-2008 06:16 PM
I suppose this has nothing to do with SVN per se because I'm not talking about integrating it into LabView. I'm using SVN to do version control of my files and that's all fine. What I want to do is somehow show the SVN repository version of the current checkout on the front panel. (Note I want the repository version of the whole repository, not the version of the last time a file changed as I would get if I used SVN key properties -- never mind that I don't think $Id$ keys would work in a VI file.) I could probably do it with a "system" function that calls an executable that queries the SVN repository for its version and returns a string. Is there something like this in LabView?
Thanks,
Keith.
11-04-2008 07:37 PM
Hi Keith,
I think you're looking for the "System Exec.vi". In LV 7.1 look in the Communications Pallet, under 8.5 it's under Connectivity.
To run a command, use
cmd /C <your command>
There are many examples using System Exec on this forum.
Cheers!
11-05-2008 01:03 AM - edited 11-05-2008 01:05 AM
I use two VIs to do this action:
It returns the highest revision number in a directory.
They can be downloaded here:
http://lv-cct-tool.svn.sourceforge.net/viewvc/lv-cct-tool/Trunk/
(SVN Info.vi and SVN Revision.vi)
Ton
01-19-2010 11:02 AM
OK chiming in late here, but I was just getting around to looking into this the other day. Up to LabVIEW 8.5.1, you can put text fields on the FP, BD, and or the VI description field, that will auto-populate from SVN.
The text field(s) are:
$Author:: $
$Date:: $
$Rev:: $
You then have to go into tsvn>properties and add the svn:keywords property with the value set to Author Date Rev, space separated. Only include those fields used in the VI text field. Once the file is committed and checked out, the text box is auto populated. very cool.
Now the problem is that with 8.6 (I think-at least this is the case with 9.0) and later, FP and BD strings are represented differently in the binary code, and this technique only works with the vi description field.
I tested this and my field updated as:
$Author:: richard.beauchaine $
$Date:: 2010-01-15 09:23:30 -0500 (Fri, 15 Jan 2010) $
$Rev:: 111 $
Now shipping in the vi.lib\user tags dir are the tagging VIs used to create and read tags similar to variant attributes. You could also extract this from svn via command line and store in attributes on a project wide basis programatically.
Also the OpenG VIs have similar looking text fields but I don't know how they populate them. This is what got me going down this path of inquiry, that and the recollection of an article in LTR some years ago.
I would like to acknowledge various posters on LAVA and Yair for this information.
01-21-2010 10:04 PM
On LabVIEW 8.6 you can store the subversion strings inside the VI description.
Ton
01-22-2010 07:52 AM
Thanks Ton for reinforcing that. That is still the common area that works in all versions. But it is kind of nice to have it magically show up on the FP or BD at checkout.
Since we have not been using this keyword substitution technique anywhere, and our main repository is still in 8.5, I was considering writing a script to put the text field on the FP or BD in the entire repository of code. Simple enough. But then it would not be extensible to stuff in 8.6 and beyond. So then I thought that the script could look at the version and based on that it would instead grab it from the VI description and put it in a FP or BD text field. The problem here being that this is code that would have to run to synch the panel label with the VI description. No longer auto updating from the SCC provider.
But then there are user tags that may be a better place to store all this stuff, we are starting to keep track of requirements, repo version, peer review records on individual files, and instead of parsing out the vi description field, it might be better just to have predefined tag names.
But first I have to get the command line to svn working..
01-22-2010 08:06 AM
You could do the following, but this is completely undocumented and unsupported stuff.
Use the lv_open hook (if I remember correctly, search on OpenG for it; some more details might be found on LAVA). I don't know how to get a reference to the VI that is opened, though (might even be not possible! it's undocumented...). If you get that ref, you could traverse for all decorations and check if the versioning decoration is already in place (identify them by using user tags), if not create one. Look up if the vi is under subversion and if it is, set/update the decoration.
The other way would be to get a hook in the SVN, so it would update all VIs on checkout. This way is at least documented...
Felix