Não te sei dizer a melhor técnica para versionamento, mas podes fazer objecto a objecto ou por documento inteiro.
Para fazeres versionamento no Qlikview, objecto a objecto, podes criar uma pasta ao lado do documento QVW, com o nome do documento seguido de '_prj'.
A cada "save" o Qlikview guarda uma versão das configurações em html e txt de todos os objectos dentro desta pasta. Depois de guardares um documento, basta sincronisar esta pasta para um sistema de controlo de versões (qualquer serve desde que permita qualquer tipo de documento).
Ao usar este processo encontrei algumas limitações/problemas:
1 - O versionamento de Reports tem de ser feito aparte, e os reports não são carregados quando existe pasta _prj.
2 - Os códigos de cores de alguns objectos não são guardados corretamente.
3 - Os objectos têem uma numeração "iterativa", que depende do documento "as is" , logo quanto existem várias pessoas a trabalhar sobre o mesmo documento, pode ser complicado juntar desenvolvimentos em paralelo devido à duplicação dos números de objectos. Uma hipótese, é cada designer alterar os Id's dos objectos de forma a não haver duplicação.
Devido a estas questões, o processo torna-se complexo de gerir, e em equipas pequenas, de 2 ou 3 pessoas, o melhor é dividir o trabalho por "tab's" tanto a nível de Script como de design, e de cada vez que um desenvolvimento é terminado, fazer cópia dos objectos e Script, para um documento final. Aí o Qlikview gera sempre novos id's de Objectos, e ficamos no fim com um documento consolidado.
Acho que os únicos detalhes a acrescentar são: a pasta deve ter o sufixo -prj ao iinvés de _prj e funciona apenas a partir da versão 10.
Agora, pensando mais em uma discussão que em uma resposta. Poderia se utilizar este recurso combinado com alguma ferramenta de controle de versões para permitir um controle mais eficiente.
Já agora, outro recurso para versionamento da componente de script, é usar includes de ficheiros de texto. Desta forma, ao sincronisar estes ficheiros, e em equipas grandes com divisão de funções entre programadores e designers, a evolução das aplicações ao nivel do script vai ser mais controlada. Além disso, se houver varios "includes", a cada novo desenvolvimento estes objectos podem ser bloqueados 1 a 1, checked in e cheked out. Ao passar para produção o script pode ser copiado para as tabs de script(acho qe deixar o script perdido em txt's pode ser uma falha de segurança, a não ser que se queira reutilizar script em diferentes qvw.), ou apenas carregado para o servidor, desde que a estrutura de pastas no servidor se mantenha.
Em relação à sua pergunta, Erich, acho que haverá sempre um problema com o versionamento usando o método "-prj". Basta um engano, que vamos ter problemas nos id's de objectos quando se consolidar objetos, e se estivermos a trabalhar com reports, então aí, a confusão é ainda maior (acredite, já passei por isso...).
Em minha opinião, a melhor forma é ter multiplos ficheiros que vão evoluindo ao mesmo tempo, e um final que consolida todo o documento por cópia (infelizmente manual...). Assim com a ferramenta de controle, pode-se ir usando os processos de check in, check out e bloqueio, para que os documentos "componentes" evoluam em paralelo.
