Est-ce que TortoiseSVN 1.7 fonctionne correctement avec un repository SVN 1.6?

Je voudrais mettre à jour mon installation TortoiseSVN à la version 1.7. Nous avons un serveur VisualSVN exécuté avec un référentiel SVN 1.6.

Dois-je mettre à jour le référentiel à 1.7 avant de pouvoir mettre à jour mon client ou TortoiseSVN est-il compatible avec les versions antérieures?

Je sais que lors de la mise à niveau de TortoiseSVN 1.6 vers 1.7, je dois convertir ma copie de travail au nouveau format, mais lors d’une validation, est-il logique de voir la version du serveur et de l’adapter correctement?

    Dans les notes de publication

    Les anciens clients et serveurs interagissent de manière transparente avec les serveurs et les clients 1.7

    Les serveurs Subversion 1.7 utilisent le même format de référentiel que Subversion 1.6. Par conséquent, il est possible de mettre à niveau et de mettre à niveau en toute transparence entre les serveurs 1.6.x et 1.7.x sans modifier le format des référentiels sur disque.

    Il n’y a pas besoin de faire quoi que ce soit, votre copie de travail sera mise à jour et sera toujours capable de communiquer avec le serveur 1.6

    Oui, il sera.

    Vous pouvez rencontrer des problèmes si vous utilisez différentes versions du client sur la même copie de travail (c’est-à-dire le répertoire extrait). De même, si vous utilisez un ancien client avec un nouveau serveur, vous ne pourrez peut-être pas utiliser certaines des nouvelles fonctionnalités du serveur.

    Cependant, les nouveaux clients SVN sont compatibles avec l’ancien serveur, à l’exception de certaines nouvelles fonctionnalités. Donc, utiliser TortoiseSVN 1.7 avec Server 1.6 devrait fonctionner sans problèmes.

    Voir la masortingce de compatibilité sur le site SVN.

    Cela fonctionne très bien avec le serveur 1.6 (1.6.17 dans mon cas).

    Heure de l’anecdote:

    • Serveur Ver. 1.6.17
    • client A Subversion 1.8.9 (gagner, tortue)
    • client B version 1.6.17 (r1128011) (linux)

    sur le client B:

    - create branch_x with lots of files - commit - svn mv branch_x branch_xnew - log shows A branch_xnew, then thousands of D for each file in branch_x - commit - fails saying that branch_x is out of date. - out of desperation, revert --depth inifity... same - more desperation, checkout a clean working copy, svn mv, commit, fails "branch_x is out of date". 

    sur le client A: svn mv, commit, done. svn up sur le client B ne montre aucun conflit. terminé.