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
ekech_infomotio
Partner - Creator II
Partner - Creator II

As I want to integrate QV with SVN, too, I will test it next week. Qliktech said, they did some changes in the XML-structures (we had some problems with IR and lost settings when using XML-Files / -prj-Folder). Hope, they fixed this kind of problem and we get a real seemless integration...

regards,

Edgar

Not applicable
Author

Here is what I found (so far)

Pros:

1)  management of the -prj (including creation) is handled by the desktop client

2)  .qvw is NOT stored in SVN; when you checkout the working copy the .qvw is created from the -prj files

3)  add project to SVN and get project from SVN work well.  however, you will need to setup the project folder structure (branches, tag, trunk) on your own.

Cons:

1) Requires an external merge tool.  There are some settings to point to the tool of your choice.  I am still trying to get kdiff3 and tortoise to accept the incoming file names.  If I drop out to windows explorer, the standard TortoiseSVN plugin will start up the merge tool correctly.  I prefer kdiff3 and it handles the required changes.  Sure would be nice to have visual tool that showed the difference instead of inferring the placement of objects.

2) Documentation.  Or the lack thereof...

Some recommended steps to use the interface:

1) Always 'Get Latest Version' to avoid conflicts, prior to making changes.

2) Be prepared to resolve conflicts externally.

More to come, I suspect...

James

Not applicable
Author

Update

After extensive testing over the past two days, I am even more confused regarding the ability to use a version control system to track changes to QlikView documents.

Base Assumption:

Never store the .qvw in the repository.  You cannot view the changes to the binary and the resulting repository growth can be overwhelming.  Which means the QlikView desktop is require to get the latest version of the .qvw -prj files and rebuild the .qvw document.

Findings:

The QlikView desktop will successfully rebuild the .qvw based on the objects stored in the -prj folder and placed in the repository.  What is upsetting is that when the document is rebuilt, certain values stored in the .xml objects are CHANGED by simply rebuilding the document.  If you reload the data, other values are also changed.  The result:  the -prj folder now contains .xml files that differ from the repository.

So what, you ask?  Is that not the point of the repository?

Take the typical use of a source code repository...

Dev creates the .qvw document and uses the QlikView desktop to 'Add Project to Source Control', which adds the -prj folder into the repository

User 'Get Project from Source Control' which creates a working copy of the -prj folder and rebuilds the .qvw document.

Test Server 'Get Project from Source Control' which creates a working copy of the -prj folder and rebuilds the .qvw document and the reloads the data.  (QVS, Access Point, auto build tool)

User reports an issue and requests a modification

Dev uses the QlikView desktop option to 'Get Latest Version' of the -prj folder (best practice to stay up to date, before starting new changes.)

Dev makes changes and uses the 'Check in Pending Changes' into the repository

User gets the latest changes, and finds that conflicts have occured (remember, the QlikView desktop has rebuilt the document and .xml files in the -prj folder used by User are now different than the repository)

Test Server gets the latest working copy, finds that conflicts have occured....

Question:

Does this happen using the TFS interface?

James

Qlik_Trigg
Employee
Employee

Why are you placing the QVW in the repository?  The whole purpoe of the integration is to move the component files (found int he PRJ folder) into the repository and manage from this definition.  The goal has never been to version control the QVW given its potential size (with the data).

Not applicable
Author

Perhaps I was not clear, the base assumption I made is in total agreement with your statement.  I am NOT storing the .qvw document.  Only the files that are stored automatically by the QlikView desktop.

It is these files that are in conflict between the different working copies.

Anonymous
Not applicable
Author

I had made the assumption that the .qvw would be stored in the repository but with the data stripped out, sort of how Publisher opens the .qvw without data when it performs a reload. We're going to go ahead and test it anyway to see if it will work for us.

Not applicable
Author

John,

I reread the above post and realized the wording did not reflect actual process.  It has been edited to more accurately reflect the actions taken by each individual in the process.

thanks,

James

Qlik_Trigg
Employee
Employee

James

I want to ask some questions of your steps (which I've nunbered for ease of reference). Can understand #2 & #3, but is the user going to test the document on the test server or locally? Lets say its tested locally by the user and posted on the test server.  So developer does some work and checks in changes.  User gets the latest and finds these changes; doesnt seem unreasonable that their version is going to be in conflict. Now one best practice maybe for the user to clear out their PRJ folder before doing get latest, if they are not doing development.  Same maybe true for the test server.

I guess what I am looking for guidance on is what do you expect the user and test server to be faced with in steps 7 & 8?

jmgilpin wrote:

Take the typical use of a source code repository...

  1. Dev creates the .qvw document and uses the QlikView desktop to 'Add Project to Source Control', which adds the -prj folder into the repository
  2. User 'Get Project from Source Control' which creates a working copy of the -prj folder and rebuilds the .qvw document.
  3. Test Server 'Get Project from Source Control' which creates a working copy of the -prj folder and rebuilds the .qvw document and the reloads the data.  (QVS, Access Point, auto build tool)
  4. User reports an issue and requests a modification
  5. Dev uses the QlikView desktop option to 'Get Latest Version' of the -prj folder (best practice to stay up to date, before starting new changes.)
  6. Dev makes changes and uses the 'Check in Pending Changes' into the repository
  7. User gets the latest changes, and finds that conflicts have occured (remember, the QlikView desktop has rebuilt the document and .xml files in the -prj folder used by User are now different than the repository)
  8. Test Server gets the latest working copy, finds that conflicts have occured....

Question:

Does this happen using the TFS interface?

James

Not applicable
Author

John,

If neither the user nor the test server has made changes, no conflicts should occur.

But it appears that the desktop is making changes to the .xml files based on the presence of data.  Sort criteria, present/not present, etc.

James