Vous ne pouvez pas utiliser Jenkins et Subversion 1.7 ?Toute solution?

Question

J'ai eu des problèmes avec la nouvelle mise à jour de Subversion 1.7 par rapport à l'utilisation de Jenkins.

Voici le problème, quelques personnes dans notre entreprise passent à la nouvelle subversion 1.7, elles ne peuvent donc pas revenir à l'ancienne structure de dossiers de subversion 1.6 (à moins qu'elles ne commettent tout, effacent leur dossier, désinstallent la nouvelle subversion 1.7 avec toutes leurs nouvelles fonctionnalités intéressantes, installez l'ancien et ennuyeux 1.6 et réexportez tout, je sais).

Donc, compte tenu du fait que je souhaite aller de l'avant et utiliser la nouvelle fonctionnalité de Subversion 1.7, comme avoir des externes qui peuvent facilement utiliser le numéro de révision..., j'ai maintenant un problème avec jenkins.

L'option que j'ai pour Jenkins est d'utiliser les plugins pour SVNKIT 1.3.7 ou peut être mis à jour vers 1.3.9.Si nous regardons la page de téléchargement de SVNKIT ( http://svnkit.com/download.php ) ils disent que les versions 1.3.7 et 1.3.9 sont incompatibles avec Subversion 1.7.Cela devrait être corrigé vers mars 2012.Mon serveur doit être opérationnel dès que possible, je ne peux donc pas attendre 1 mois entier.

Alors, quelle serait votre suggestion pour que mon utilisateur utilise Subversion 1.7 et que je puisse toujours utiliser Jenkins.

Pour info, j'ai essayé ce qui suit :

• Changer le protocole utilisé sur le serveur, utiliser le protocole SSLv3 fait fonctionner Subversion mais échoue à Jenkins, et utiliser TLSv1 et SSLv3 fait fonctionner Jenkins mais échoue à certaines opérations de Subversion, donc aucun résultat positif.
• En modifiant l'option de protocole dans jenkins pour utiliser SSLv3, cela a été mentionné dans quelques FAQ que par défaut, jenkins utilise le protocole TLSv1, toujours aucun résultat positif.(Donnez-moi toujours l'erreur Impossible d'accéder https://svn.myrepos.com/svn/teamlib/package/ThePackages/trunk :SVN :OPTIONS /svn/teamlib/package/ThePackages/trunk a échoué (afficher les détails) (Peut-être devez-vous saisir vos informations d'identification ?))
• En créant un nouveau référentiel sur un autre serveur utilisant TLSv1 et SSLv3, ce référentiel ne contiendrait qu'un lien externe vers le véritable référentiel de base (exemple le nouveau référentiel https://svn2.myrepos.com/svn/teamlib/testpackage/trunk cela ne contient qu'un externe au svn sur l'autre serveur en utilisant uniquement SSLv3 https://svn.myrepos.com/svn/teamlib/package/ThePackages/trunk ).

Le dernier en date est le plus proche d'un succès puisque Jenkins travaille bien pour tout construire mais semble incapable d'exporter des éléments externes.(Je peux cependant faire l'exportation manuellement mais j'aurais besoin que cela soit fait par Jenkins).

Alors, une idée ?

Answer 1

Je ne suis pas sûr de comprendre votre architecture.Vos développeurs peuvent continuer à utiliser la version 1.7 sur leurs machines de développement (clients) même si le référentiel exécute Subversion 1.6.x.À ma connaissance, le support externe amélioré a été introduit avant la version 1.7, par ex.nous utilisons des externes rattachés dans 1.6.x.À mon avis, la compatibilité avec Jenkins l'emporte sur tous les avantages liés à l'exécution de la version 1.7 sur le serveur.

Nous exploitons un serveur SVN central exécutant Subversion 1.6.x (qui prend en charge les révisions externes liées) et certains développeurs ont mis à niveau vers les clients Subversion 1.7 sur leurs machines de développement.Étant donné que le serveur SVN exécute 1.6.x, Jenkins peut effectuer une extraction à partir de notre référentiel central (y compris une extraction externe).Je recommanderais de conserver la version 1.6.x sur votre référentiel jusqu'à ce que Jenkins/SvnKit prenne en charge la version 1.7.

Le Notes de version de Subversion 1.7 disons que le format du référentiel n'a pas changé, vous devriez donc pouvoir rétrograder votre référentiel si vous l'avez déjà mis à niveau :

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 rétrograder de manière transparente entre les serveurs 1.6.x et 1.7.x sans modifier le format des référentiels sur les disques.(Ce n'est pas correct en général pour une paire de serveurs 1.x et 1.y, mais se trouve à la maintenance pour 1.6 et 1.7.) Si les nouvelles fonctionnalités 1.7 ont été activées sur le serveur (dans les fichiers de configuration des crochets ou du serveur), ils Il faudra bien sûr être désactivé avant de revenir à un serveur 1.6.

Answer 2

Vous devrez attendre que le plugin Subversion pour Jenkins soit mis à jour pour prendre en charge Subversion 1.7.Je ne sais pas quand ce sera le cas.Le développement du plugin Hudson Subversion pour la mise à niveau est actuellement en cours et devrait être disponible dans la prochaine version du plugin.