subversion keyword expansion

[Andrew O]

  We are using Subversion to control our labview code.  For better tracking of our development and releases we want to capture the Subversion revision in VIs and controls.

  To do this we have started using subversion fixed-length keyword substitution in the VI/ctl descriptions (ie $Revision::                        $)

  This works for us in both our development and application distributions.

  However it is clearly an undocumented feature that the descriptions are stored as ascii text within the .vi/.ctl binary file.

  Does anyone have insight if this behaviour is likely to change in future releases of LabView?  Or, even better, could this 'feature' (or similar) be included in the LabView specification going forwards.  I'm sure it could get widely used in highly controlled environments (ie areospace, medical, etc)

[mikeporter]

Clearly there is no knowing the future and what might happen. Still - and this is only my personal opinion so perhaps someone from NI could comment - if I had to guess I would say that this is very unlikely to change for the simple reason that there would be so little to gain. You aren't going to save any appreciable amount of memory by modifying the way strings in descriptions or labels are stored and I can't think of any other reasons why someone would go to the trouble to change it.

In short, I wouldn't lose any sleep over it.

Mike...

[mikeporter]

never mind, inadvertent double post.

Mike...

Message Edited by mikeporter on 08-22-2007 08:53 PM

[dhedges]

I'm going to disagree with Mike.  I don't think it's safe to plan on this behavior being around in future versions.

VIs and Ctls are proprietary binary files, and National Instruments makes no guarantees about their format.  The format changes every so often.  Perhaps you remember that the VI files saved in LabVIEW 8.0 were roughly 55% smaller than those saved in 7.1.  That's because the file format went through an overhaul.  8.2 and 8.5 did not have significant file format changes, but they do happen.  Some engineer might, for example, want to change the VI description to be stored in unicode for internationalization purposes, or (conversely) compress it for smaller disk image and faster load time.  Either way your system breaks.

I'd be interested to hear more about the use case.  Do you care that the revision number is viewable from the context-help window, or do you just want it to be inside the file somewhere?  Do you need to be able to see the revision number if the VI is loaded through the run-time engine?  How about at edit time?  If there were a place in the file that was safe for SCC to write in but you could only view the contents through an external tool, would that satisfy your use case?

Thanks,
--Dan

[TCPlomp]

Maybe as an advocate of the devil, if you use LV 8.x you can use PushOK SVNSCC plugin to have direct contact between LV and the SVN.
You could edit the LV SCC VIs to include the revision number of the VI in the comments for that specific VI.

Ton

[PJS]

I had been using keyword expansion with source safe since version 4.  However, I have since dumped it. While you can use it with custom controls, it is not really something you want, since when you lay those controls.. The expansion field comes with it.  I guess, to each his own.  But the reality is no matter what schema you choose, something may change in hte future, requiring you to make a switch, or there may be a better idea.   So I would view any idea you have for source code, a version, by version implementation.  For instance, clear case does not support keyword expansion. So when the 'company' made a decision to switch, my schema went up in smoke.  Since changing companies, I am now using subversion.  The point being, do not lose sleep trying to solve a problem for 10 yrs down the road. Worry about today, maybe next week... and go with it.. My $0.02

[Andrew O]

Thanks all for the feedback.  We are likely going to proceed, with caution, down our current path.

Regarding the use case (from my perspective only of course)

  - Don't care if the scc info is in the context-help window

  - Needs to be extractable in both development and run-time modes

      - Need to be able to re-affirm linkage of the run-time and allow auditing of deployment sites

  - Safe SCC location + external utility to read keys (ala 'what' in UNIX) meets my need

      - Need to be able to specify the unsubstituted contents of the safe location. (ie '$Revision::     $')

      - SCC info for all VIs needs to be accessible, even in application build

  - Nice to have - accessible via LabView programming, at least during development

      - Allow integration with custom development tools (eg documentation tools, linkage verification)

-- Andrew

CELESTICA