¿Cómo cambiar el nombre de los paquetes de Java sin romper el historial de Subversion?

Question

La compañía para la que trabajo está comenzando y cambiaron su nombre en el proceso. Así que todavía usamos el nombre del paquete com.oldname porque tenemos miedo de romper el historial de cambios de archivos, o los vínculos de ascendencia entre versiones, o lo que sea que podamos romper (no creo que use los términos correctos, pero se obtiene el concepto)

Utilizamos: Eclipse, TortoiseSVN, Subversion

encontré somewhere que debería hacerlo en muchas medidas para evitar la incoherencia entre el contenido de las carpetas .svn y nombres de los paquetes de archivos de Java:

• Primera utilice TortoiseSVN para cambiar el nombre del directorio, actualizando los directorios .svn.
• A continuación, cambie manualmente el nombre del directorio al nombre original.
• Para usar finalmente Eclipse para cambiar el nombre de los paquetes (refactor) al nuevo nombre, actualizando los archivos java.

Eso me parece bueno, pero necesito saber si la ascendencia y la historia y todo lo demás seguirá siendo coherente y funcionará bien.

No tengo las llaves de ese servidor, es por eso que no hago copias de seguridad apresuradas y pruebo una o dos cosas. Me gustaría encontrar una buena razón para no hacerlo, o una forma de hacerlo que funcione.

Gracias por su ayuda,

M. Joanis

---

paquete cambiar el nombre de la prueba

Procedimiento:

1. Crear un nuevo paquete de com.oldname.test .renametest.subpackage.

2. Agregar una nueva clase bajo renametest llamada RenameTest0.java y que contiene:

   class RenameTest0 { 
       public RenameTest0() { 
        showMessage(); 
        new RenameTest1(); 
       } 
       public static void showMessage() { 
        System.out.println("RenameTest0!"); 
       } 
       public static void main(String[] args) { 
        new RenameTest0(); 
       } 
   }

3. Agregar una nueva clase bajo renametest.subpackage que contiene:

   class RenameTest1 { 
       public RenameTest1() { 
        showMessage(); 
        RenameTest0.showMessage(); 
       } 
       public static void showMessage() { 
        System.out.println("RenameTest1!"); 
       } 
   }

4. prueba que RenameTest0 funciona muy bien.

5. Commit.
6. Cambia los mensajes de ambas clases.
7. Commit.
8. Nuevamente, cambie el mensaje de una clase y comprométase (solo creando un poco de historial).
9. Aplicar el procedimiento propuesto anteriormente (los tres pasos en el mensaje original) para cambiar el nombre del paquete renametest a testrename.
10. Commit.
11. Prueba de ejecución.
12. Modifica los mensajes nuevamente y prueba.
13. Commit.
14. Intente retroceder a la versión cuando ambos mensajes se hayan cambiado simultáneamente la primera vez.
15. Si todo funcionó bien hasta este punto, se ve bien, ¿no?

Resultado de la prueba:

• Nota sobre el paso 9: tenía que hacerlo en orden inverso (Eclipse cambiar el nombre de TortoiseSVN cambiar el nombre.), De lo contrario se está complicando, como TSVN crear un nuevo carpeta/paquete y marca el antiguo para eliminación ... Así que no puede cambiar el nombre de Eclipse a menos que coloque el paquete anterior en otro lugar mientras tanto para evitar perder carpetas .svn, etc. etc. No se veía como un buen idea de ir más lejos con este método. (Nota para mí: ¡no olvide marcar la casilla para cambiar el nombre del paquete recursivo!)
• Nota sobre el paso 14: ¡Funcionó! Podemos ver versiones anteriores; todo lo que tenemos que hacer es decir que no se rompa la copia/movimiento y está bien. Una vez revertido a una versión antes del cambio de nombre, , los nombres de los paquetes no vuelven al buen nombre a través de, probablemente eso lo haría refactorizar nuevamente.
• Nota final: Me sorprendió tener que realizar los pasos críticos en orden inverso. Para hacer eso justo en el medio de este primer paquete, renombrar "try", tuve que revertir algunas modificaciones TSVN y manuales, arrojando una pequeña duda sobre la naturaleza repetible de los resultados exactos de este procedimiento. Tendré que hacer una segunda prueba para confirmar su validez. En resumen: se ve bien, pero necesita más pruebas.

Answer 1

Quizás no sea práctico para sus necesidades exactas, pero TortoiseSVN tiene una función muy útil para cambiar el nombre. Puede hacer esto:

1. Utilice la característica de refactorización de IDE para cambiar el nombre de las cosas.
2. Inicie el diálogo "Comprobar modificaciones" desde TortoiseSVN.
3. Para cada elemento renombrado, verá dos entradas: un elemento faltante "fuente.java" y un elemento "target.java" no versionado. Resalta ambos y elige "Reparar mover" desde el menú contextual.

Repair moves/renames

Answer 2

Sí, funcionará. Puede instalar la versión de línea de comando de svn y escribir un archivo por lotes que hará las cosas svn. Automatizar las cosas del eclipse sería un poco más laborioso, y probablemente no valga la pena a menos que ya esté familiarizado con la API de eclipse.

Pruébelo con un paquete antes de hacer todo solo para asegurarse de que está haciendo todos los pasos correctos.

Answer 3

¿Estás seguro de que mantener el historial NO funciona si estás utilizando el método de refactorización incluido en Eclipse?

Con NetNeans que cambian regularmente los nombres de paquetes y el plug-in 'svn' subyacente en silencio movimiento el contenido (lo que ahorra la historia) en el nuevo directorio (después de que la refactorización normales sucederá).

so: ¿Has probado desde dentro de eclipse si el historial se mantiene con el complemento de subversión? (Por ejemplo, en una copia de registro de salida fresca para evitar el fracaso)

Al menos se podría utilizar NetBeans para realizar esta tarea de una sola vez ...

Answer 4

Usted puede hacer esto, y no es tan difícil - su mejor opción para obtener un historial limpio de SVN es hacerlo en 2 pasos (puede convertirse en una confirmación), aunque para obtener buenos resultados, recomiendo usar el cliente CLI.

1. Uso svn mv para mover las carpetas/paquetes
2. entro en Eclipse, o utilice grep desde la CLI para fijar los paquetes en los archivos para que coincida con el nuevo nombre

A continuación, puede comprometerse como un conjunto de cambios, y el historial en el nivel de archivo debe coincidir.

Si está utilizando Maven o una herramienta de empaquetado, recomendamos que ejecute un comunicado antes de hacer algo como esto - también vale la pena cortar una etiqueta inmediatamente antes de esto en caso de que necesite volver a la vieja estructura

Answer 5

¿Ha considerado usar el Subclipse plugin? Puede resolver sus problemas, de acuerdo con How do I use Eclipse Refactoring Tools and stay in sync with SVN through Subclipse?

Answer 6

he descubierto que el plugin Subclipse da el mensaje de error "ya está bajo control de versiones" en la comisión de una clase que se ha movido a un nuevo paquete (es decir, no bajo control de origen aún) y el padre de este paquete también es nuevo.

Cuando esto sucede, puedo confirmar los cambios usando TortoiseSVN. Después de eso, solo necesito actualizar el proyecto en Eclipse.

Después de mover una clase a un paquete nuevo cuyo principal ya está bajo control de fuente, subclipse puede confirmar este cambio sin problemas.

Answer 7

En lugar de cambiar el nombre de los paquetes que usted puede hacer esto:

1. crear la nueva estructura del paquete en su proyecto. Una vez realizado el proyecto debe ser algo como esto:

    com - 
         |- myOLDcompname - 
         |    |- feature1 - 
         |       |- classA.java 
         |       |- classB.java 
         |- myNEWcompname - 
             |- feature1 
   

2. añadir las nuevas carpetas bajo control de versiones SVN así que puede realizar un seguimiento de ellos

3. mueven sus clases Java a partir de los paquetes viejos a los nuevos. Eclipse debe actualizar todas las importaciones de clases y las declaraciones de paquetes en consecuencia. Lo más importante es que los paquetes viejos y nuevos están en vcs, este paso debe mantener el historial de las clases.
4. cuando haya terminado, elimine las carpetas antiguas
5. commit!