Comment renommer des paquets Java sans casser l'histoire de Subversion?

La société, je travaille pour est en cours de démarrage et ils ont changé leur nom dans ce processus. Nous avons donc toujours utiliser le nom du package com.oldname parce que nous avons peur de casser le fichier de l'historique des modifications, ou l'ascendance des liens entre les versions, ou ce qu'on pourrait casser (je ne pense pas que j'utilise les bons termes, mais vous obtenez le concept).

Nous utilisons: Eclipse, TortoiseSVN, Subversion

J'ai trouvé quelque part que je devrais le faire en plusieurs étapes pour éviter l'incohérence entre le contenu de .svn dossiers et les noms de package dans les fichiers java:

• De la première utilisation de TortoiseSVN pour renommer le répertoire, la mise à jour de la .svn répertoires.
• Puis, renommer manuellement le répertoire au nom d'origine.
• Pour enfin utiliser Eclipse pour renommer les paquets (refactor) sauvegarder le nouveau nom, la mise à jour les fichiers java.

Qui semble bon pour moi, mais j'ai besoin de savoir si la généalogie et de l'histoire et tout le reste sera toujours cohérent et fonctionne bien.

Je n'ai pas les clés de ce serveur, c'est pourquoi je n'ai pas hâte de sauvegarde et d'essayer une ou deux choses. Je voudrais trouver une bonne raison de ne pas le faire, ou une façon de faire qui fonctionne.

Merci pour votre aide,

M. Joanis

---

Paquet de renommer test

Procédure:

1. Créer un nouveau package com.oldname.test.renametest.sous-paquetage.
2. Ajouter une nouvelle classe de sous renametest appelé RenameTest0.java et contenant:

   classe RenameTest0 { 
   public RenameTest0() { 
   showMessage(); 
   nouveau RenameTest1(); 
   } 
   public static void showMessage() { 
   Système..println("RenameTest0!"); 
   } 
   public static void main(String[] args) { 
   nouveau RenameTest0(); 
   } 
   }

3. Ajouter une nouvelle classe de sous renametest.sous-paquetage contenant:

   classe RenameTest1 { 
   public RenameTest1() { 
   showMessage(); 
   RenameTest0.showMessage(); 
   } 
   public static void showMessage() { 
   Système..println("RenameTest1!"); 
   } 
   }

4. Test RenameTest0 fonctionne très bien.
5. Commettre.
6. Modifier les messages des deux classes.
7. Commettre.
8. Encore une fois, changer le message d'une de la classe et de s'engager (juste de créer un peu d'histoire).
9. Appliquer la procédure proposée ci-dessus (les trois étapes dans le message d'origine) pour renommer paquet renametest à testrename.
10. Commettre.
11. Essai.
12. Modifier à nouveau les messages et de test.
13. Commettre.
14. Essayez de revenir à la version lorsque les deux messages ont été changé en même temps la première fois.
15. Si tout a bien fonctionné à ce point, il semble bon, non?

Résultat du test:

• Note sur l'étape 9: Eu à le faire dans ordre inverse (Eclipse renommer PUIS TortoiseSVN renommer.), sinon cela se complique, comme TSVN créer un nouveau dossier/le paquet et les marques de l'ancien pour la suppression... Donc vous ne pouvez pas renommer pour Eclipse, sauf si vous placez l'ancien paquet quelque part dans le temps pour éviter de perdre .svn dossiers, etc. etc. Ne ressemblait pas du tout une bonne idée d'aller plus loin avec cette méthode. (Note à moi-même: ne pas oublier de cocher la case pour récursive paquet de renommer!)
• Note sur l'étape 14: Travaillé! Nous pouvons voir les versions précédentes; tout ce que nous avons à faire est de dire de ne pas le casser sur copier/déplacer et c'est ok. Une fois revenue à une version avant de le renommer, les noms de package ne sont pas de retour pour le nom siprobablement que la refactorisation de nouveau le ferait.
• La note de fin: j'ai été surpris d'avoir à faire la critique étapes dans l'ordre inverse. Pour faire droit au milieu de ce premier paquet de renommer essayer, j'ai dû revenir sur certains TSVN et les modifications manuelles, en jetant un peu de doute sur la nature reproductible de l'exactitude des résultats de cette procédure. Je vais devoir faire un deuxième test pour confirmer sa validité. Pour résumer: il semble bien, mais a besoin de plus de tests.

source d'informationauteur Joanis