Thank you for your reply. I think that I was avoiding the VDPadmin tool was because in the past I've made changes to the VQL and the VDPAdmin tool would NOT mark the element as changed.
Furthermore, when I would try to check in my VQL changes through the VDPAdmin tool I was unable to check in the changes because the VDPAdmin Tool would report that nothing changed.
This failure to mark the elements have changed contributed to me not trusting the tool when it comes to changes.
Another example: When I recently did a source refresh on my base view some new fields were found and after I finished the wizard my base view had some new fields. However, the VDPAdmin tool marked nearly ALL derived views as changed also, even though I didn't propagate the new fields in the Base View to any derived view.
This also leads me to NOT trust the VDPAdmin tool when it comes to SVN integration.
Finally, when the VDPAdmin tool does properly mark something as changed, I can't easily see what the change was until I do a check in. When I do a check in, I get the extra window that allows me to see what it is going to check in, and IF I've configured an external DIFF tool, then I can see what changed. If I haven't configured an external DIFF viewer, the built in one doesn't really highlight the changes...
To add to this, for some reason check-ins and check-outs are taking a long time (sometimes 30 minutes).
Finally, there is an option for conflict detection but it isn't really explained in the HTML documentation (the documentation when I click the help icons from within the tool). Instead I have to go find the full PDF and search for "enable conflict detection" to see what it does.
I don't mean to complain, but I do mean to show that ALL of these things combined get in my way as a developer... I just want to see what changed before I check something in and the VDPAdmin tool seems to get in my way.
This leads me to want to use a DIFFERENT tool than the VDPAdmin tool.
For the reasons above, I (and the developers at my company) are inclined to use different tools to see what actually changed. If I export my database to the repo format, then I can use ANY file diff tool that has the color coding that I like.
Furthermore, exporting to repo format and then using an external file diff tool is WAY faster than doing a check in and having to wait for the VDPAdmin tool.
I don't mean to complain, I am however trying to give you visibility into my thinking. The Denodo VQLServer is an AWESOME tool. The fact that I can pull data from different places and combine it is powerful.
But when it comes to a team doing development on a shared virtual database the VDPAdmin tool with the VCS integration still has room for improvement. We are struggling with slow check-ins, the orange boxes showing up on derived views when a base view changes (even though we didn't change the derived view) and the orange boxes NOT showing up when we would change something in the VQL.
We just installed the 2015 March 5.5 update, so that should fix the orange box not showing up issue... but we still aren't ecstatic to use the VDPAdmin tool when it comes to checking in/checking out code.
For now it seems that the export.bat -r option allows us to avoid the vdpadmin tool when doing comparisons... but since it uses a different dependencies algorithm we'll have to ignore the .dependencies files.