2010-03-21 8 views
16

La società per cui lavoro sta iniziando e hanno cambiato il loro nome nel processo. Quindi usiamo ancora il nome del pacchetto com.oldname perché abbiamo paura di infrangere la cronologia delle modifiche ai file, o dei legami ancestrali tra le versioni o qualsiasi cosa potremmo interrompere (non credo di usare i termini giusti, ma ottieni il concetto).Come rinominare i pacchetti Java senza interrompere la cronologia di Subversion?

Usiamo: Eclipse, TortoiseSVN, Subversion

ho scoperto somewhere che avrei dovuto farlo in molte misure per prevenire l'incoerenza tra i contenuti delle cartelle .svn e dei pacchetti in file java:

  • First utilizzare TortoiseSVN per rinominare la directory, aggiornando le directory .svn.
  • Quindi, rinominare manualmente la directory con il nome originale.
  • Per utilizzare infine Eclipse per rinominare i pacchetti (refactor) sul nuovo nome, aggiornando i file java.

Questo mi sembra buono, ma ho bisogno di sapere se l'ascendenza, la storia e tutto il resto saranno ancora coerenti e funzionanti.

Non ho le chiavi per quel server, è per questo che non faccio rapidamente il backup delle cose e provo una o due cose. Mi piacerebbe venire con una buona ragione per non farlo, o un modo di farlo che funziona.

Grazie per il vostro aiuto,

M. Joanis


pacchetto rinominare prova

Procedura:

  1. Creare un nuovo pacchetto com.oldname.test .renametest.subpackage.
  2. aggiungere una nuova classe sotto renametest chiamato RenameTest0.java e contenente:

    class RenameTest0 { 
        public RenameTest0() { 
         showMessage(); 
         new RenameTest1(); 
        } 
        public static void showMessage() { 
         System.out.println("RenameTest0!"); 
        } 
        public static void main(String[] args) { 
         new RenameTest0(); 
        } 
    }
  3. aggiungere una nuova classe sotto renametest.subpackage contenente:

    class RenameTest1 { 
        public RenameTest1() { 
         showMessage(); 
         RenameTest0.showMessage(); 
        } 
        public static void showMessage() { 
         System.out.println("RenameTest1!"); 
        } 
    }
  4. prova che RenameTest0 funziona benissimo.

  5. Conferma.
  6. Modificare i messaggi di entrambe le classi.
  7. Conferma.
  8. Ancora, cambia il messaggio di una classe e commetti (solo creando un po 'di storia).
  9. Applicare la procedura proposta sopra (i tre passaggi nel messaggio originale) per rinominare il pacchetto renametest in testrename.
  10. Conferma.
  11. Test eseguito.
  12. Modificare di nuovo i messaggi e testare.
  13. Conferma.
  14. Provare a ripristinare la versione quando entrambi i messaggi sono stati modificati contemporaneamente la prima volta.
  15. Se tutto ha funzionato bene fino a questo punto, sembra buono, no?

Risultato della prova:

  • Nota sul punto 9: doveva farlo in ordine inverso (Eclipse rinominare POI TortoiseSVN rinominare.), Altrimenti si stava facendo complicata, come TSVN creare una nuova cartella/pacchetto e contrassegna il vecchio per la cancellazione ... Quindi non è possibile rinominare per Eclipse a meno che non si metta il vecchio pacchetto da qualche altra parte nel frattempo per evitare di perdere cartelle .svn, ecc. ecc. Non sembrava un buon idea di andare oltre con questo metodo. (Nota: non dimenticare di spuntare la casella per la ridenominazione del pacchetto ricorsivo!)
  • Nota sul passaggio 14: Funzionato! Possiamo vedere le versioni precedenti; tutto quello che dobbiamo fare è dire di non interrompere la copia/lo spostamento e va bene. Una volta ripristinata una versione prima della rinomina, i nomi dei pacchetti non sono tornati al buon nome anche se, probabilmente il refactoring lo farebbe di nuovo.
  • Nota finale: sono stato sorpreso di dover fare i passaggi critici in ordine inverso. Per farlo giusto nel mezzo di questo primo pacchetto rinominare try, ho dovuto ripristinare alcune modifiche TSVN e manuali, gettando un piccolo dubbio sulla natura ripetibile dei risultati esatti di questa procedura. Dovrò fare un secondo test per confermare la sua validità. Per riassumere: sembra buono, ma necessita di ulteriori test.
+5

Un buon motivo per non farlo sarebbe che sarebbe una buona quantità di lavoro (compresi i test) senza alcun beneficio. Se pensi che qualcuno inizi a produrre librerie nello spazio com.oldname che entrerà in collisione con il tuo potrebbe valerne la pena, ma l'intera idea dei prefissi di dominio era quella di garantire unicità, non di soddisfare le persone del marketing. – msw

+0

Devo ammettere che è un ottimo punto ... – Joanis

+0

@Don Kirby e @Karussell: cercherò di eseguire un test oggi o domani e fornirò un feedback in merito. – Joanis

risposta

8

Forse non è pratico per le tue esatte esigenze ma TortoiseSVN ha una caratteristica utile in materia di rinomina. È possibile effettuare questa operazione:

  1. Utilizzare la funzione di refactoring dell'IDE per rinominare le cose.
  2. Avvia il dialogo "Verifica modifiche" da TortoiseSVN.
  3. Per ogni articolo rinominato, verranno visualizzate due voci: un elemento "source.java" mancante e un elemento "target.java" non assegnato. Evidenzia entrambi e scegli "Ripara spostamento" dal menu di scelta rapida.

Repair moves/renames

+0

Questo link è rotto – naumcho

+0

Ma questo non funzionerebbe se si ha anche un plugin SVN Eclipse installato come Subclipse, giusto? – User

0

Sì, funzionerà. È possibile installare la versione da riga di comando di svn e scrivere un file batch che eseguirà la roba svn. Automatizzare la roba di Eclipse sarebbe un po 'più di lavoro, e probabilmente non ne vale la pena a meno che tu non abbia già familiarità con l'API di eclipse.

Provalo con un pacchetto prima di fare tutto solo per assicurarti di fare tutti i passaggi giusti.

2

Sei sicuro che la cronologia non funziona se stai utilizzando il metodo di refactoring incluso in eclipse?

Con NetNeans mi cambiano regolarmente nomi dei pacchetti e il sottostante 'plug-svn' silenziosamente mossa il contenuto (che salva la storia) nella nuova directory (dopo che il refactoring normale accadrà).

così: l'hai provato da dentro eclissi se la cronologia è conservata con il plug-in subversion? (Ad esempio in una copia del check-out fresca per evitare il fallimento)

Almeno si potrebbe usare NetBeans per eseguire questa operazione una sola volta ...

+0

+1: anche la domanda era per Eclipse, questo mi aiuta molto. il plugin netbeans funziona bene per me.(basta essere aggiornato per aggiornare il rappresentante con il PLUGIN e non con un altro client svn prima di fare il refactor) – Loda

0

È possibile fare questo, e non è così difficile - la cosa migliore da fare per ottenere una cronologia SVN pulita è di farlo in 2 passaggi (può diventare un commit) - sebbene per buoni risultati raccomando di usare il client CLI.

  1. Usa svn mv per spostare le cartelle/pacchetti
  2. andare in Eclipse, o utilizzare grep dalla CLI per fissare i pacchetti nei file che corrisponda al nuovo nome

Poi si può commettere come set di modifiche e la cronologia a livello di file deve corrispondere.

Se stai usando Maven o uno strumento di imballaggio, consiglia di eseguire un rilascio prima di fare qualcosa di simile - anche vale la pena il taglio di un tag immediatamente prima di questo nel caso in cui è necessario tornare alla vecchia struttura

0

ho scoperto che il plugin subclipse dà il messaggio di errore "è già sotto controllo di versione" quando commettere una classe che è stato spostato ad un nuovo pacchetto (cioè non sotto il controllo di origine ancora) e il genitore di questo pacchetto è anche nuovo.

Quando ciò accade, posso eseguire il commit delle modifiche utilizzando TortoiseSVN. Dopodiché ho solo bisogno di aggiornare il progetto in Eclipse.

Dopo aver spostato una classe in un nuovo pacchetto il cui genitore è già sotto il controllo del codice sorgente, subclipse può confermare questa modifica senza problemi.

0

Invece di rinominare i pacchetti si potrebbe fare questo:

  1. creare la nuova struttura del pacchetto nel progetto. Una volta fatto il progetto dovrebbe essere simile a questo:

     com - 
          |- myOLDcompname - 
          |    |- feature1 - 
          |       |- classA.java 
          |       |- classB.java 
          |- myNEWcompname - 
              |- feature1 
    
  2. aggiungere le nuove cartelle sotto controllo di versione in modo da svn può rintracciarli

  3. muovere le classi Java da vecchi pacchetti a quelli nuovi. Eclipse dovrebbe aggiornare di conseguenza tutte le importazioni delle classi e le dichiarazioni dei pacchetti. Soprattutto perché vecchi e nuovi pacchetti sono sotto vcs questo passaggio dovrebbe mantenere la cronologia delle classi.
  4. al termine eliminare le vecchie cartelle
  5. commit!
Problemi correlati