TortoiseSVN 1.7 fonctionnera-t-il correctement sur un référentiel SVN 1.6?

Question

Je souhaite mettre à niveau mon installation TortoiseSVN vers la version 1.7. Nous avons un serveur VisualSVN fonctionnant avec un référentiel SVN 1.6.

Dois-je mettre à niveau le référentiel vers la version 1.7 avant de pouvoir mettre à jour mon client ou la compatibilité ascendante de TortoiseSVN?

Je sais que lors de la mise à niveau de TortoiseSVN 1.6 à 1.7, je dois convertir ma copie de travail au nouveau format, mais lors d'une validation, une logique permet-elle d'afficher la version du serveur et de s'y adapter?

Answer 1

Dans les notes de version

Les anciens clients et les serveurs d'interagir de façon transparente avec 1,7 serveurs et les clients

...

Subversion 1.7 les serveurs utilisent le même référentiel format comme de la Subversion 1.6. Par conséquent, il est possible, en toute transparence, de mise à niveau et de rétrograder entre 1.6.x et 1.7.les serveurs x sans changer le format de la sur disque dépôts

Il n'y a pas besoin de faire quoi que ce soit, votre copie de travail sera mis à jour, et sera toujours en mesure de parler à la 1.6 serveur

Answer 2

Oui, il le fera.

Vous pouvez rencontrer des problèmes si vous utilisez des versions différentes du client sur la même copie de travail (c'est à dire vérifié répertoire). Aussi, si vous utilisez un vieux client avec un nouveau serveur, vous ne pouvez pas être en mesure d'utiliser certaines des nouvelles fonctionnalités de serveur.

Cependant, de nouvelles SVN clients sont rétrocompatible avec l'ancien serveur, à l'exception de quelques nouvelles fonctionnalités. Donc, en utilisant TortoiseSVN 1.7 avec le Serveur 1.6 devrait fonctionner sans problèmes.

Voir la matrice de compatibilité sur le SVN site.

Answer 3

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

Answer 4

Anecdote time:

• Server Ver. 1.6.17
• client A Subversion 1.8.9 (victoire, 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é.