Skip to main content
Announcements
Qlik Community Office Hours, March 20th. Former Talend Community users, ask your questions live. SIGN UP
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

SR1 - SVN

Has anyone downloaded QV11 SR1 and played with the SVN interface?

James

27 Replies
Not applicable
Author

John,

In step 2, the user gets a copy of the -prj as it sits in the repository.  As part of this process the desktop application recreates the .qvw document (as expected).  The process has the desktop application store a blank .qvw document and then applies the -prj xml files.  Once the -prj xml files have applied, then user is presented with the layout, script, etc. for review.  This restored copy of the .qvw is NOT saved until the User tells QlikView to save the document.

IF the user SAVES the document at this point, the resulting -prj xml files are overwritten.  Even though the user has not made any changes some of the -prj xml files are different.  In my case, 9 out of 50 are different.  The next time the user issues the 'Get Latest' command a conflict is detected.

I thought maybe it was due to platform, 32bit/64bit, or possibly different user preferences.  But this occurs between two different working copies of the -prj folder on the same machine.

James

Qlik_Trigg
Employee
Employee

So have spent some time playing around with this today and cant quite replicate your conflict scenario, but put that down to user setup error on my part.  I suspect a date/time stamp is updating and forcing the conflict though I cannot yet confirm that.  Will do some more poking around and talk to the appropriate developers to get more insight.

Cheers

John

Not applicable
Author

John,

Thanks

Should you need an example document, give a shout and I will redact this one I have been playing with and post it....

James

rwunderlich
Partner Ambassador/MVP
Partner Ambassador/MVP

James,

I want to confirm your scenario. The user only does:

1.Open

2. Reload

3. Save

And that creates changes in some of the object.xml files? I would expect a conflict in the AllProperties file, but no others. Any column sorting, object moving/restoring before save will cause change as well because those are layout changes.

I'd be curious to know what files and properties you are getting conflict on.

-Rob

Not applicable
Author

Rob,

It is not quite that simple.  This appears to be an issue with how the .qvw is rebuilt after getting the -prj from the svn repository.  When the desktop application reads the svn repository it must recreate the .qvw based on the files in the -prj folder.

In my test case, three files are different...

AllProperties.xml

CH01_391551278.xml

QlikViewProject.xml

I created a 7zip archive of my test files to show these differences.  (yes, i included the .svn folder... bad developer...)

James

tseebach
Luminary Alumni
Luminary Alumni

Has anyone managed to move code between servers without committing the .qvw?

I looking for at method to maintain a central repository, and how this can be moved between sandbox, test and prodution. But I'm puzzled on how to best handle creating .qvw files if a new file is added to the repos.

I'm disregarding the source control options in qlikview, since are running some very strange commands, and don't allow me to check out dependencies. As far I can tell the buildt in functions are very limited, and don't support a standardlized version control method.

SVN is super scriptable, so I'm thing of making server hooks that perhaps adds a blank .qvw when a new -prj folder i found.

Not applicable
Author

I have Jenkins in place performing builds of the .qvw by use of the 'svn revert', 'svn update', and 'qv.exe /r' commands.  But in my workflow I manually add a blank document for the initial setup.  It would be very interesting to see a script that detected a new -prj folder and copied a blank document into place.

The next step for our group is to setup a code review process that requires an approved signature for changes to the .qvw document stored in the repository.  Note: this has no bearing on the users, only developers, ie. data source, joins, etc.

James

rwunderlich
Partner Ambassador/MVP
Partner Ambassador/MVP

I build the qvw from -prj using VBScript:

The CreateQvw() is enough to create the qvw that will then be populated when a user opens it. If you want it to be fully populated call the OpenClose() as well. The qvw name is determined in another process and passed to the routine. Hopefully this will give you a guide as to the steps to take after checkout. Because it's using QlikView, a GUI is required. I haven't figured out how to build the qvw in a headless environment.

-Rob

 

Function CreateQvw(qvwFullPath)

          Set Qv = CreateObject("QlikTech.QlikView")

          Set docObj = Qv.CreateDoc

          docObj.SaveAs qvwFullPath

          docObj.CloseDoc

          Set Qv = Nothing

          CreateQvw = qvwFullPath

End Function

Function OpenClose(qvwFullPath)

  Set Qv = CreateObject("QlikTech.QlikView")

  Set docObj = Qv.OpenDocEx (qvwFullPath,0,false)  ' Open the document

  docObj.Save

  docObj.CloseDoc

  Set Qv = Nothing

  OpenClose = qvwFullPath

End Function

Not applicable
Author

Rob,

Do you find that you lose actions/triggers associated with fields by using this method?

For example, when the blank document is created using the xml files in the -prj folder, QlikView is not aware of any fields until the document is reloaded.  The association of triggers/actions to those fields is lost (or appears to be) by creating a blank document.

James

Not applicable
Author

Update

QV11 SR1 resolved a couple of minor issues, however there are more difficult issues which everyone should know.

Issues:

1) requires svn 1.6.17 (client)

You cannot use version 1.7 of the svn client with the supplied QV SVN provider dll (source control settings).  Version 1.7 svn merge variables (%base, %mine, and %theirs) are handled incorrectly by the QV dll.  Downgrading to svn 1.6 (client) resolves this issue.  However, downgrading and trying to maintain working copies created under 1.7 OR using Tortoise 1.7 and svn client 1.6; NOT recommended.  Best to start over by uninstalling all the svn client software (including Tortoise, VisualSVN, etc.) and reinstalling the versions supported.

2) Get Project from Source Control creates working copy, regardless of existing working copy

I am being picky, but if the working copy structure already exists...  QV should recognize the working copy and use it instead of creating a new one inside the existing working copy.  (multiple .svn directories cause all kinds of grief).  You can force QV to recognize the structure by copying the SourceControlSettings.ini into the -prj folder within the existing working copy.

3) Field Event Triggers can be lost... ARGH! (yes, i opened a support case)

QV uses the .xml files in the -prj folder to recreate the .qvw document.  The .xml files represent the pieces of the .qvw.  When you 'get project from source control', QV rebuilds the .qvw document.  Triggers based on fields within load statements are not saved in the .xml files.  So when the .qvw document is recreated there is nothing to use to rebuild these triggers.

James