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

eclipse svn

Question

La empresa para la que estoy trabajando se está iniciando y cambiaron su nombre en el proceso. Así que todavía usamos el nombre del paquete com.oldname porque tememos romper el historial de cambios de archivos, o los enlaces de ascendencia entre versiones, o lo que sea que podamos romper (no creo que use los términos correctos, pero entiendes el concepto ).

Utilizamos: Eclipse, TortoiseSVN, Subversion

En somewhere encontré que debería hacerlo en muchos pasos para evitar la incoherencia entre el contenido de las carpetas .svn y los nombres de paquetes en archivos java:

• Primero use TortoiseSVN para cambiar el nombre del directorio, actualizando los directorios .svn.
• Luego, cambie manualmente el nombre del directorio al nombre original.
• Para finalmente usar Eclipse para cambiar el nombre de los paquetes (refactor) al nuevo nombre, actualizando los archivos java.

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

No tengo las claves de ese servidor, por eso no hago copias de seguridad apresuradamente e intento una o dos cosas. Me gustaría encontrar una buena razón para no hacerlo, o una manera de hacerlo que funcione.

Gracias por tu ayuda,

M. Joanis

Prueba de cambio de nombre del paquete

Procedimiento:

1. Cree un nuevo paquete com.oldname.test.renametest.subpackage.

2. Agregue una nueva clase bajo renametest llamada RenameTest0.java y que contenga:

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

3. Agregue una nueva clase en renametest.subpackage que contiene:

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

4. Prueba de que RenameTest0 funciona bien.

5. Cometer.
6. Cambia los mensajes de ambas clases.
7. Cometer.
8. Nuevamente, cambie el mensaje de una clase y confirme (solo creando algo de historial).
9. Aplique el procedimiento propuesto anteriormente (los tres pasos en el mensaje original) para cambiar el nombre del paquete renametest a testrename.
10. Cometer.
11. Prueba de funcionamiento.
12. Vuelve a modificar los mensajes y prueba.
13. Cometer.
14. Intente volver a la versión cuando ambos mensajes se hayan cambiado simultáneamente la primera vez.
15. Si todo funcionó bien a este punto, se ve bien, ¿no?

Resultado de la prueba:

• Nota sobre el paso 9: tuve que hacerlo en orden inverso (cambio de nombre de Eclipse THEN TortoiseSVN.), De lo contrario, se estaba complicando, ya que TSVN crea una nueva carpeta / paquete y marca la anterior para su eliminación ... Así que no puede cambie el nombre de Eclipse a menos que ponga el paquete anterior en algún otro lugar mientras tanto para evitar perder las carpetas .svn, etc. No parecía una buena idea ir más allá con este método. (Nota para mí: ¡no olvide marcar la casilla de verificación 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 interrumpa en copiar / mover y está bien. Una vez que se ha revertido a una versión anterior al cambio de nombre, los nombres de los paquetes no vuelven al buen nombre , sin embargo , probablemente la refactorización nuevamente lo haría.
• Nota final: Me sorprendió tener que hacer los pasos críticos en orden inverso. Para hacerlo justo en el medio de este primer intento de cambio de nombre del paquete, tuve que revertir algunas modificaciones manuales y de TSVN, dejando 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

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

Con NetNeans, cambio regularmente los nombres de los paquetes y el ''svn plugin'' subyacente moverá silenciosamente el contenido (lo que guarda el historial) al nuevo directorio (después de lo cual ocurrirá la refactorización normal).

así que: ¿Lo ha intentado desde dentro de eclipse si el historial se mantiene con el complemento de subversión? (por ejemplo, en una copia de salida nueva para evitar fallos)

Al menos podrías usar NetBeans para hacer esta tarea única ...

Answer 2

¿Has considerado usar el plugin Subclipse ? Puede resolver sus problemas, de acuerdo con ¿Cómo uso las herramientas de refactorización de Eclipse y me mantengo sincronizado con SVN a través de Subclipse?

Answer 3

Descubrí que el complemento de subclipse muestra el mensaje de error "ya está bajo control de versión" cuando se confirma una clase que se ha movido a un paquete nuevo (es decir, aún no está bajo control de código fuente) y el elemento primario de este paquete también es nuevo .

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

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

Answer 4

En lugar de renombrar los paquetes, puedes hacer esto:

1. Crea la nueva estructura del paquete en tu proyecto. Una vez hecho esto, tu proyecto debería verse así:

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

2. agregue las nuevas carpetas bajo el control de versiones para que svn pueda rastrearlas

3. mueve tus clases de java de paquetes viejos a nuevos. Eclipse debería actualizar todas las clases importadas y las declaraciones de paquetes en consecuencia. Lo más importante es que debido a que los paquetes antiguos y nuevos están bajo vcs, este paso debe mantener el historial de las clases.
4. cuando haya terminado de borrar las carpetas antiguas
5. ¡cometer!

Answer 5

Puede hacer esto, y no es tan difícil, su mejor apuesta para obtener un historial SVN limpio es hacerlo en 2 pasos (puede convertirse en un solo compromiso), aunque para obtener buenos resultados, recomiendo usar el cliente CLI.

1. Use svn mv para mover las carpetas / paquetes
2. Ingrese a Eclipse o use grep de la CLI para arreglar los paquetes en los archivos para que coincidan con el nuevo nombre

Luego puede confirmar como un conjunto de cambios, y el historial a nivel de archivo debe coincidir.

Si está utilizando Maven o una herramienta de empaquetado, le recomendamos que ejecute una versión 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 estructura anterior.

Answer 6

Sí, funcionará. Podría instalar la versión de línea de comandos de svn y escribir un archivo por lotes que haga las cosas svn. Automatizar las cosas del eclipse sería un poco más de trabajo, 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 para asegurarse de que está haciendo todos los pasos correctamente.

Answer 7

Tal vez no sea práctico para sus necesidades exactas, pero TortoiseSVN tiene una útil función para cambiar el nombre. Podrías hacer esto:

1. Utilice la función de refactorización de su IDE para cambiar el nombre de las cosas.
2. Inicie el diálogo "Verificar modificaciones" de TortoiseSVN.
3. Para cada elemento renombrado, verá dos entradas: un elemento faltante "source.java" y un elemento no versionado "target.java". Resalte ambos y elija "Reparar movimiento" en el menú contextual.

Reparar movimientos / renombrar