Memorizzazione di correzioni di errori come modifiche locali piuttosto che nel ramo SVN

Question

Memorizzazione di correzioni di errori come modifiche locali piuttosto che nel ramo SVN

#1 da (4 voti)
#2 da (0 voti)

0

Stiamo distribuendo e aggiornando i siti Web a diversi clienti. Normalmente aspettiamo le ultime modifiche da stabilizzare, quindi tagmo la versione di subversion come release e installiamo che la versione al cliente. Quindi riceviamo richieste di supporto e talvolta siamo costretti a fare correzioni rapide tra una release e l'altra. Trovo fastidioso mantenere queste correzioni nei rami, e mi chiedo perché non li memorizziamo come "modifiche locali" in alcune cartelle "Release X.Y" (su build-machine)? Può funzionare, o sta ramificando l'unico modo?

I motivi di questa modifica sono:

sembra molto più facile usare WinMerge-utility per unire le più recenti correzioni di bug in alcune "Release X.Y" -folder, che usare "branch integration" di tortoise-svn. WinMerge ti offre un controllo molto più preciso su quali modifiche unire e quali no (su base file, non su base commit).
quando si mantengono correzioni di bug come "modifiche locali" si ha un confronto a tre: in "Controlla modifiche" puoi vedere tutte le correzioni di bug nella versione attuale e con WinMerge puoi vedere tutte le ultime modifiche di tronco ( se confronta "Release XY" con "trunk" -folder)
sembra anche troppo ossessivo tenere tutto in SVN. IMO SVN dovrebbe servire l'utente e non il contrario.
anche la reintegrazione del ramo non unisce mai solo quei file che sono stati effettivamente modificati. Porta via tutta una serie di file non necessari, il che rende difficile tenere traccia di qualsiasi cosa nel registro SVN.

branching svn web-development deployment

posta AareP 29.03.2011 - 12:39

fonte

2 risposte

Leggi altre domande sui tag branching svn web-development deployment

Domande sulle licenze software [duplicate] Gli sviluppatori di backend si preoccupano del loro codice nel frontend?

score 4 · Answer 1

Dopo un'attenta riflessione, abbiamo adottato il seguente schema.

Il ramo principale è sempre un ramo di sviluppo.
Una volta che viene rilasciata una release, per questa release viene creato un ramo di rilascio specifico. Qualsiasi hot fix viene eseguito su questo ramo.
Le correzioni apportate a un ramo di rilascio sono integrate nel master se ha senso. Alcune correzioni cambiano le cose che sono passate da tempo dal ramo dev. Se una correzione è piccola, puoi semplicemente copiarla e incollarla nella sorgente di sviluppo e usare diff per vedere che sei corretto; non hai sempre bisogno di un'unione formale.
Assolutamente nessuna modifica non tracciata al codice di rilascio è consentita. A meno che tu non possa costruirlo dal controllo del codice sorgente con un comando e distribuire con un altro, lo stai facendo male (vedi l'elenco di controllo di Spolsky ).

Questo era il giorno in cui usavamo SVN. Con git, i principi sono gli stessi, ma la ramificazione e soprattutto la fusione sono molto più indolori.

score 0 · Answer 2

Bene, qualsiasi approccio se fatto con attenzione funzionerà, ma devo ammettere che mi rende nervoso, questa modalità mista di usare SVN e unire manualmente probabilmente ti farà finire nei guai.

Ho due suggerimenti:

Assicurati di ricominciare a meregimentare con SVN - non dovrebbe essere così difficile (e puoi rendere WinMerge il tuo strumento di unione predefinito con Tortoise SVN) (TSVN - > Impostazioni - > Programma esterno - > MergeTools
Se vuoi mantenere le "correzioni" separate e gestirle in un secondo momento, puoi sempre apportare le modifiche al sito, quindi creare una patch - le applica quelle successive. (TSVN- > Crea patch)