Quali sono gli effetti a lungo termine della riorganizzazione di un repository di subversion

Question

Il repository di subversion al lavoro è stato impostato senza molta pianificazione in merito alla sua struttura. Non ci sono tag espliciti, tronco o rami configurati, anche se alcuni metadati di tagging è presente attraverso l'uso di subclipse: tag

Attualmente il repository è nel formato:

/CoreCodeA

/CoreCodeB

/Project1

/Project2

Recentemente un nuovo sviluppatore è iniziato il "versione 2" della nostra applicazione interna che ha posto sotto diversa cartella:

/new/NewCoreA

/new/NewCoreB

/new/Project3

/nuovi

Questi progetti/project4 tutti hanno dipendenze su varie parti del codice Core e su progetti simili (ad esempio, diversi progetti potrebbero dipendere dallo stesso tema). Queste dipendenze sono referenziate all'interno del contenuto di alcuni file di proprietà del progetto basati su testo.

Ho giocato con il comando svndumpfilter, convogliando l'output tramite sed e riorganizzandolo in due repository separati ("vecchio" e "nuovo"). È abbastanza facile da fare, e ora ho due repository distinti con trunk, tag e branch set (le informazioni di tag secondclipse possono essere riascoltate in un secondo momento).

La mia preoccupazione è che, armeggiando con la struttura di sovversione su ogni commit, io stia rompendo le build che in precedenza funzionavano, specialmente date le dipendenze da altri progetti. D'altra parte, ho bisogno di avere tag e rami in questo codebase prima piuttosto che dopo. Ma anche io non voglio forzare gli sviluppatori a ricontrollare i loro progetti se cambio idea qualche mese dopo la linea.

Credo che le mie scelte per ogni repository sono:

1. Mark il repository con un tag "pre-ristrutturazione", riorganizzare il repository come voglio, tag con "post-ristrutturazione
   • . Bene: non si romperà storico costruisce
   • Bad: Effettivamente disconnette lavoro futuro dal lavoro passato, non facile capacità di fare cerotto rilascia XX1
2. Ristrutturare l'intero repository, rompendo precedente costruisce
   • Buono: Storia continuità del codice è mantenuta
   • Bad: Precedente generazioni sono rotti, sarà sicuramente richiedono x.x.1 cerotto rilascia, se mai necessario di nuovo
3. Ristrutturare l'intero archivio e modificare i file di proprietà di progetto in ogni fase
   • Buono: La continuità del codice è mantenuto e progetti dovrebbe basarsi
   • Bad: Modifica del contenuto effettivo dei file è molto più fragile di quanto semplicemente cambiando i metadati sulla loro posizione

Le prime due scelte sono facili eno ugh to do - ma mi piacerebbe un mondo reale 20-20 senno di poi da altri sviluppatori su quello che hanno fatto in una situazione simile, e cosa è andato storto o giusto.

Answer 1

Il layout del repository (modifica) riguarda più la tua organizzazione di sviluppo che qualsiasi altra cosa tecnica. Senza sapere quale sia la quantità di codice, il numero di modifiche necessarie nel codice dopo la ristrutturazione e il numero di persone che lavorano sul codice, è abbastanza difficile raccomandare qualcosa di specifico, ma comincerei a coinvolgere tutte le persone interessate con questo e dedicando 1-2 giorni alla revisione del repository - code freeze, sono consentite solo correzioni per rendere il codice costruibile. Alla fine, tutti saranno molto più felici. Cercando di fare questo sotto copertura probabilmente ti lascerai con uno sviluppatore malvagio che sta ancora facendo le sue proprie filiali in qualche angolo buio del tuo server SVN.

E non mi preoccuperei più di tanto dell'accesso al layout del codice storico. Puoi sempre taggare il layout corrente sotto qualcosa di simile a/oldlayoutdonottouchthis senza alcun risultato e lasciarlo lì per correggere le vecchie versioni. Per trucchi del genere, SVN è uno strumento davvero eccezionale.

P.S. Non ho mai usato subclipse, ma sembra che i tag subclipse siano molto diversi dai tag SVN by-the-book. Sembrano essere più tag tag CVS. Assicurati di non avere confusione lì.

Answer 2

Non vorrei toccare la storia. All'epoca non andava bene e dovrai pagare il prezzo se vuoi tornare di nuovo lì.

Ovviamente, potresti "sapere" che rivisiterai spesso il passato, quindi potrebbe essere logico ottenere con # 3 e inserire l'intero pronti contro termine con le nuove versioni .1 di tutti i punti importanti.

Answer 3

Esiste un modo per ottenere i file delle proprietà di build in modo che riflettano i percorsi relativi anziché i percorsi codificati?

Supponendo che il tuo compito riguardi l'organizzazione delle cartelle principali in tag, rami e trunk, penserei che le sottocartelle/file (almeno in una certa misura) manterranno la loro posizione relativa (s)?

Se fossi in te, vorrei prendere in considerazione fissare i miei file di proprietà di diventare più generico e indipendente di percorsi assoluti ..

Spero che questo aiuti .. Cheers!