Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
In order to get better information from your customers in case of support it is good to know the exact version of an app, the customer uses, even if you are not the only developer in your company and if there are many apps under development.
This HowTo will show, how to implement subversion revision details of your app in your app that you have version controlled. So the customer can tell you, what version it is, our you can see it by yourself.
This HowTo is for people that are familiar with the version control system "subversion" and it's client implementation named "TortoiseSVN". But the solution shown here can be adapted to other SVN clients and perhaps other version control systems as well.
If you have a continuous integration system (ok, QV apps do not need to be compiled) or you have installed your version control system on your QV Server it might be possible to adapt this solution for server side use.
First proofread this HowTo and test it before you use it for production. There is no warranty that it will work as described here. The code this HowTo contains is not bulletproofed and is just for demonstration. So it is simplified.
As you might know, it is possible to implement subversion as an version control system into the QV Client. But as you might also know, this implementation does not support a lot subversion features and commands. So myself and many others decided to use a full subversion client to have all the commands you need.
The client this HowTO uses is TortoiseSVN so it is possible to use client side post-commit hooks and if you installed the svn binaries as well, your system should know the SubWCRev command as well. To check this
Figure 1: Output of SubWCRev command
I you get something like "Command not found" verify that the command location is in your path. In a standard 64 bit installation the default location is "C:\Program Files\TortoiseSVN\bin\". Be sure to work with the 64 bit command interpreter, if you have 64 bit TortoiseSVN installed and with the 32 bit command interpreter if 32 bit TortoiseSVN.
The solution assumes that you have got a 99.Shared Folder and within your other container(s) you should have apps under version control so that folders with "-prj" suffix exists belonging to the apps.
In order to get this feature you first have to create two folders and place three files in there.
In the .\QDF\99.Shared_Folders\6.Script\ folder create a folder named "3.VersionControl"
Within the subfolder "3.VersionControl" create another folder named "1.Subversion" so you end up with this folder: ".\QDF\99.Shared_Folders\6.Script\3.VersionControl\1.Subversion"
Within this new created folder place the three files contained in the attachment SVNRevision.zip of this HowTo.
The files in SVNRevision.zip are:
At a final step you have to edit the AppPath in SVNRevision.cmd file to point to the root folder containing your apps under version control. ( You also could edit the value of SVN.RepositoryRootOfProject in SVNRevsion.tmpl so that evaluating SVN.Path in your case will work later on)
That's it. Now you are prepared to implement the solution.
You just have to double click the file SVNRevision.cmd. So what has happened? First of all a SVNRevision.log file is generated. (If you want, you could have a look inside later on).
I will describe more details now and finally you can have a look at figure 2, the big picture.
If you take a look into your App folder and navigate to your app, let us name it "SVNTest.qvw" you will see your folder "SVNTest-prj" and an new created file SVNTest.qvw.svn.revision.qvs. If you use TortoiseSVN diff tool or any other diff tool and compare the file SVNRevision.tmpl with the new created file you will see, that each keyword is substituted by an exact value.
It must be clear to everyone that this new file should not be added to version control. You have to add this in your ignore list or you add a general pattern *.svn.revsion.qvs to your ignore list. Read subversion documentation for detailed explanation.
Notice that the name of the new created file is created with the name of the QVW file followed by the suffix ".svn.revision.qvs".
To implement information of this file in your app while reloading, you simply have to copy two lines in the comment of the new file and paste it in your LoadScript. Simply copy
let SVN.DocumentName=DocumentName();
$(Include=$(QvWorkPath)\$(SVN.DocumentName).svn.revision.qvs);
and paste it into your app. Then simply reload and you have the information in your app.
You can see all this in figure 2.
Figure2: Implementation within you app
On the upper right hand side of this picture you see the file browser showing the SVNTest.qvw, its "-prj" folder for version control and the new created ".qvs"-file.
On the upper left hand side you see the reload code. On the lower left hand side you see the table viewer. The table you see has been created by the included file. On the lower right hand side you see the content of the SVN_Revsion table.
If you want you can display this table in your app.
If the command SVNRevision.cmd is executed, the template file SVNRevsion.tmpl is used for keyword substitution so that you have a standard generation of the ...svn.revision.qvs files.
If for some reason you want a special template for one of you apps, you can place a template file beside the QVW file named "<QVW-Filename>.svn.revision.tmpl". So in my example I just copied the file SVNRevisionDefault.tmpl beside SVNTest.qvw, named it SVNTest.qvw.svn.revision.tmpl and did the SVNRevsion.cmd command again (see figure 3).
It's a good practice to add this special template to version control.
Figure 3: Customizing the generation for a single app
After reloading I found all keywords that are documented in the subversion documentation as variables in the app (figure 4).
Figure 4: Revision details as SVN variables
So as I told at the beginning, we will implement this feature as a post-commit hook so that the included qvs-files reflect the actual version information. So to do this (in TortoiseSVN) you just have to configure the hook.
In my case I decided to use relative path based on the repository root. So I first added and committed the SVNRevsion.cmd and template file SVNRevsion.tmpl to the version control system.
Then on the Application Root folder ( You have set the path in the SVNRevsion.cmd file before) I added the hook as you could see in figure 5 as a property on the Application Root folder ( not recursively!).
Figure 5: Settings of the post-commit client side hook
So if you do changes to your app now and commit the "-prj" folder, this hook is fired and the SVNRevision Command is executed. The "...svn.revsion.qvs" files get updated and after reload of the app you have "up to date" revision information in you app.
If you what to move your app and deploy it, you have to move/copy the qvs file as well. Don't forget this as a final step.
With the solution shown here you have a easy and configurable way of implementing detailed revision information in your app. You can define default code for your include files using the SVNRevsion.tmpl or even define special code for special apps using a template for this app.
You can implement this as a command that you simply execute manually or implement it as a client side hook. It should also be possible to implement it in a continuous integration server like cruisecontrol, if subversion is installed on that server as well.
Great work Frank! Btw, have you read my IDE development environment document?Qlik IDE Development environment.pdf
Cheers
Magnus
Hallo Magnus,
thx for your positive reply. I hope my English in that document is not so bad.
Your document I have not known until now and have just scanned it. Great work as well. The editor Sublime is new to me but as you would guess, Tortoise and VisualSVNServer are tools I use as well. As an editor I use Notepad++ because we have to use that one in our team. There is a language definition for QlikView Scripts by João Dias de Carvalho Neto and you have a project plug in as well.
Do you know Jonas Wiklander's blog about version control? It has 5 parts. Part 1 shows a solution for creating the prj folder (You should thing about implementing his script in QDF). This script does not only create a prj folder, it creates the files in it by simply open and store the document automatic.
He also describes very good, in which case version control does not work or has a crazy behaviour.
Summing it all up one can say, that many solutions in this community have to do with a lag of
within QV client. So my wish to future versions of QV is to fill this lags with a good solution.
Regards
Frank
@ Frank: Had some wish as Frank in 2008.... developed in 2009 QQversioner for that... (with DIFF results available directly in Qlik dynamic associative interface ...), but got tired after a while... 😞
@ Magnus: As you can see, Notepad++ is perhaps even more popular than Sublime in Qlik community.... Since it also has Qlik language definitions, I would like to ask you if the Qlik IDE environment you have created has major benefits from Sublime that Notepad++ cannot cover ? Do you recommend the switch from N++ to sublime ?
Forgot the essential, to thank you both for your work !
Hallo Cotiso,
thx for your input. So I am a bit confused about so many Frank's. Do you know the film "Calamari Union" by Aki Kaurismäki? There are so many Frank's. I love that film .
So I searched for QQversioner. I was not able to get it to have a look.
You couldn't, because we've discontinued it for some years... Just wanted to underline that I understand and agree with your wish... 😉