SVN Pre Commit Hook

[Niatross]

I am trying to write some pre commit hooks which Tortoise SVN can call.

I would like these hooks to run VI Analyser tests on all modified/new files and run any unit tests associated with these files.

Currently my main stumbling block is that I can't call the VI Analyser API from an executable. When I say I can't call it what I mean is it just hangs and doesn't do anything, no progress, no errors.

I thought maybe I could get the executable to open a VI in the LabVIEW IDE which would then call the VI Analyser API but that isn't working very well as it is asking if I want to add the VI to the project I am currently working on.

I have also tried calling the vi using VI server as suggested here https://forums.ni.com/t5/LabVIEW/Autorun-VI-from-command-line/td-p/1246020

This also results in VI analyser just hanging.

Does anyone have any ideas how to call VI Analyser from a executable, or even better is there a toolkit available that I haven't found that does this already?

[billko]

You are going to force the user to run VI Analyzer before committing?  That seems, to me, to be a terrible thing to do.  If it's their branch, they should be able to do anything they want with it, and that includes committing broken VIs.

[Niatross]

It’s only for my use really, and I’m wanting to set it as a manual pre commit hook (I manually press a button to run tests)

It’s the best way I can see if bringing the vi analyser into my workflow. 

from my reading it also isn’t unusual to always run tests (unit tests and linters) before a commit/merge. It helps to enforce the idea that only complete code should be on the repo. Or have I misunderstood, we have only just started implementing version control. 

[Niatross]

So I did manage to get my executable to open a VI which calls the VI Analyser API in the development environment so it is working well. It is just very very slow. My current workflow is:

- Pre Commit hook runs caller.exe and passes the files which are going to be modified in this commit as an argument

- Caller.exe opens a vi by running system exec and executing "labview.exe VITest.vi" (This takes quite a while, ~5-10 secs, and then the LabVIEW IDE actually has to load all the required dependencies, another ~3secs)

- VITest.vi runs a custom saved VI Analyser test on all modified VI's (It also seems to take a long time to for the VIAn New Task VI to load a saved analyser configuration (~5-10s)

In summary I have got it to work and it probably will be useful but I would like it to run a lot quicker. I would appreciate any suggestions that anyone has. (I will post code later when it is neat)

[billko]

I would say that your branch is your branch; you do with it what you want.  The trunk, on the other hand... only working code goes there.  You are working from a branch, right?  You're not working from the trunk?

If I were to impose a requirement on commit, I think it would be far more useful to force a user to put in a comment.

Sooo... picture this:

You are working on a project, but your main VI is broken because, let's say that all the states haven't been created yet, so you aren't committing until they are.  You have quite a bit done, but there's more to do.  Then the hard drive crashes, and the data is not retrievable.  It would've been so easy to "commit as you go" - that is, every time you complete a section of the main VI, commit to save your work.  Then, when the hard drive dies, you still have most of your work.

[Niatross]

I do see where you are coming from, but I am not trying to force people/me to run them before committing, Tortoise SVN gives you a little button in the commit window to manually run pre commit hooks. I am just trying to utilise this to make it easier and more natural to run unit tests and VI Analyser. One of my main issues with both of these is that they are really quite slow so been able to run them only on modified code seemed appealing.

Another issue I have with VI analyser is I have never been able to work out a way of configuring a custom test and then easily run it only on a single VI. There are some useful things that I would like to check (Not least of which is spelling mistakes) but unless I am missing something you either have to pre identify which VI's you want to analyse and save it in your configuration which means you end up analysing everything every time. Alternatively you can right click on the VI and run the default which has every test enabled which gives you a lot of results, not all of which I necessarily want to check.

Been able to only analyse changed VI's at commit seemed like a really quick way of doing some simple checks whilst minimising the amount I have to do to actually run the test, meaning I am much more likely to do it.

If I am missing an easier way of doing this let me know because I can see there are going to be some problems with my plan.

---

@billko wrote:

I would say that your branch is your branch; you do with it what you want.  The trunk, on the other hand... only working code goes there.  You are working from a branch, right?  You're not working from the trunk?

---

Yes, I am currently only working in the trunk. I am new to version control systems and am still doing my research/getting used to it and working out how to fit into my workflow. My current thought process behind only modifying the trunk is that I remove any possibilities of having to do conflict resolution, which I have found difficult in LabVIEW so far. Also, because I am a solo developer I don't have to worry about breaking the trunk for others. I am guessing you would thoroughly recommend only working from branches then? How come?

[billko]

---

@Niatross wrote:

I do see where you are coming from, but I am not trying to force people/me to run them before committing, Tortoise SVN gives you a little button in the commit window to manually run pre commit hooks. I am just trying to utilise this to make it easier and more natural to run unit tests and VI Analyser. One of my main issues with both of these is that they are really quite slow so been able to run them only on modified code seemed appealing.

Another issue I have with VI analyser is I have never been able to work out a way of configuring a custom test and then easily run it only on a single VI. There are some useful things that I would like to check (Not least of which is spelling mistakes) but unless I am missing something you either have to pre identify which VI's you want to analyse and save it in your configuration which means you end up analysing everything every time. Alternatively you can right click on the VI and run the default which has every test enabled which gives you a lot of results, not all of which I necessarily want to check.

Been able to only analyse changed VI's at commit seemed like a really quick way of doing some simple checks whilst minimising the amount I have to do to actually run the test, meaning I am much more likely to do it.

If I am missing an easier way of doing this let me know because I can see there are going to be some problems with my plan.

---

@billko wrote:

I would say that your branch is your branch; you do with it what you want.  The trunk, on the other hand... only working code goes there.  You are working from a branch, right?  You're not working from the trunk?

---

Yes, I am currently only working in the trunk. I am new to version control systems and am still doing my research/getting used to it and working out how to fit into my workflow. My current thought process behind only modifying the trunk is that I remove any possibilities of having to do conflict resolution, which I have found difficult in LabVIEW so far. Also, because I am a solo developer I don't have to worry about breaking the trunk for others. I am guessing you would thoroughly recommend only working from branches then? How come?

---

I recommend working from your own branch even if you are the only one.  This is your workflow for when others are merging to the trunk, so you may as well make the mistakes now when only you will be paying for them.