Usando SVN male - Mercurial è la risposta?

Al lavoro usiamo SVN, ma solo nel nome. Non ramifichiamo o fondiamo. Conserviamo due copie del repository, una che funge da ramo "tag" che viene copiato quando eseguiamo una distribuzione e conservato per correzioni di bug e funzionalità immediate di tipo "questo deve andare al più presto". Dobbiamo ricordare di copiare le modifiche apportate in una copia all'altra copia (il "trunk"). Abbiamo una dozzina di progetti all'interno di una singola cartella nel repository, invece di dividerli. In breve, l'unica cosa per cui utilizziamo SVN è la possibilità di impegnarci. Tutto il resto è fatto manualmente.

Ho valutato Mercurial; Ho usato Git in passato (sono l'unico nella squadra che ha usato un DVCS) e sto raccogliendo Mercurial rapidamente. Sto discutendo di presentare Mercurial al resto del team come un "modo migliore" di fare le cose perché la ramificazione è un gioco da ragazzi, la fusione è molto più semplice e possiamo impegnare le cose localmente sul contenuto del nostro cuore e spingerle solo al centro ramo quando sono pronti. Otterremmo tutti i vantaggi di SVN (e non stiamo ottenendo molti benefici in questo momento comunque poiché nessuno capisce davvero SVN) in più per le nuove funzionalità non dobbiamo avere tonnellate di file non controllati che fluttuano quindi se dobbiamo eseguire il rollback Siamo fottuti. Il flusso di lavoro sembra un po 'più semplice: dobbiamo solo ricordare che "Commit" è locale e "Push" è come il commit di SVN,

È un buon approccio da adottare? Tieni presente che il team è molto flessibile e si accompagnerà a tutto ciò che migliorerà la nostra qualità del lavoro e renderà più semplice il modo in cui facciamo le cose - il CIO mi ha persino chiesto quando ho detto che non stavamo usando SVN per il suo potenziale "È c'è qualcosa di meglio che possiamo usare? " quindi anche lui è a bordo.

Sì.

Se sostituisci "SVN" con "Perforce" nel tuo OP hai praticamente la situazione in cui mi sono trovato quando ho iniziato il mio lavoro attuale, anche per la copia con cambio manuale. Dopo due anni siamo su Mercurial e tutti concordano sul fatto che è stato un grande cambiamento.

Abbiamo la capacità di diramare e unire per caso di supporto , il che è incredibilmente utile per il controllo qualità e la capacità di creare un numero qualsiasi di rami e repository usa e getta ogni volta che lo riteniamo opportuno, che possiamo quindi creare e verificare nel nostro server CI, quindi distribuire in un ambiente di test cloud e verificare la funzionalità. Questo è stato di enorme beneficio in termini di tranquillità che quando eseguiamo una distribuzione live, siamo quasi sicuri al 100% che funzionerà (senza problemi di ambiente / DB, che ovviamente sono al di fuori dell'ambito del VCS).

Fondamentalmente, ciò che abbiamo guadagnato passando al mercuriale è respirare spazio. Non dobbiamo più preoccuparci del costo di un ramo, o delle orribili sessioni di unione che inevitabilmente seguivano, tutto è molto più semplice. Usiamo anche FogBugz abbastanza pesantemente, quindi il legame con Kiln (il loro mercurio ospitato) è davvero utile.

Anche il commento sul sito hginit è perfetto , come schema per un flusso di lavoro di controllo della versione che funziona effettivamente (supponendo che lo si adegui al flusso di lavoro di controllo qualità della propria azienda).

L'unico difetto possibile nel spostare i controlli della versione è che avrai bisogno di qualcuno che sia davvero una forza trainante dietro il cambiamento, che è felice di leggere sull'argomento e usare davvero gli strumenti al meglio delle sue potenzialità, che sembra voler fare.

Non sono d'accordo con i commenti sulla dimensione del team e sulla distribuzione del team in merito all'opportunità di utilizzare DCVS. In realtà, si tratta di distribuzione CODICE. Se si verificano più cicli di sviluppo in parallelo, supportando casi su un sistema legacy, o un sacco di funzionalità o persino nuovi sistemi (che a giudicare dal suo funzionamento), trarrai vantaggio dall'uso di un DVCS.

Uno strumento diverso probabilmente non risolverà il tuo problema, direi che dovresti leggere questo articolo, l'ho trovato molto utile:

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

Penso che il punto principale dell'articolo sia riassunto qui, ma per favore leggilo:

Alla fine: non proprio sugli strumenti

In tutto il tempo che ho trascorso lavorando e integrando diversi sistemi di controllo del codice sorgente, sono giunto a una conclusione: non è lo strumento, è il modo in cui lo usi. È un'affermazione terribilmente compromessa, ma qui sembra particolarmente vero. Se utilizzato per gestire correttamente le modifiche al codice sorgente - etichettatura per build, diramazioni per eccezione, ecc. - anche il più debole sistema di controllo del codice sorgente (* tosse * SourceSafe * tosse *) supererà di gran lunga un set-up Mercurial con un sacco di commit casuali e spinte.

No. La tecnologia raramente risolve questo tipo di problema.

Mercurial è più complesso di Subversion (sì, ramificare e fondere è migliore e forse più semplice, ma il modello di Subversion è molto più semplice di quello di Mercurial). Se stai usando Subversion in un modo così semplice, potresti finire con Mercurial:

• a) adeguatamente o meglio
• b) inadeguatamente, ma meglio del tuo attuale utilizzo di Subversion
• c) Non adeguatamente come ora
• d) Peggio di adesso

c) ed) sembrano gli esiti più probabili. Scrivi perché pensi che finirai in a) o b).

Non posso parlare di come funzionano i team di grandi dimensioni, ma per i team di piccole dimensioni molti di questi grandi problemi SVN non sono in realtà problemi SVN ... Sono problemi di sviluppo. Se non stai seguendo i moderni standard di sviluppo (soprattutto, facendo un'integrazione continua), il controllo delle versioni si trasforma nel disordine esatto che stai descrivendo ... Prima di passare a un nuovo sistema assicurati di eseguire un'analisi della causa principale vera sul tuo problema ...

No. Gli strumenti non sostituiscono la metodologia.

Se non usi Subversion come SCM , non puoi usare anche Mercurial (e accadrà molto probabilmente)

SVN può fare ciò di cui hai bisogno per fare e non è necessario cambiare i cavalli a metà flusso per un risultato discutibile.

Qualunque cosa tu faccia, dovrai superare un problema di fiducia. Qualcuno deve essere in grado di convincere tutti a cambiare il loro flusso di lavoro. Questo non è facile anche nelle migliori circostanze, anche se hai logica e fatti dalla tua parte. È una delle cose più difficili da fare in un'organizzazione. Se fallisci o diventa difficile, perdi la fiducia e sarà molto difficile riottenere quella fiducia.

Ci sono un paio di cose che so che le persone hanno provato con successo. Forse uno di loro lavorerà per la tua squadra:

1. Porta un "allenatore" per fornire una serie di seminari per il team. Questo probabilmente dovrà essere una persona esterna (ironia della sorte, spesso è più facile per molte squadre fidarsi di un estraneo piuttosto che fidarsi di qualcuno nella squadra). Deve essere qualcuno che conosce a fondo le sue cose e che può insegnare efficacemente queste abilità alle persone a tutti i livelli di comprensione e escogitare un piano pragmatico per implementare il nuovo VCS (*) nel flusso di lavoro del team.

2. Avvia un progetto "skunk-works" per testare e validare il nuovo VCS su un piccolo progetto laterale. Scegli un paio di sviluppatori "alfa" che sono disposti a provare nuove cose e non dispiace accumulare un mucchio di esperimenti senza successo. Quando skunk-works è in grado di dimostrare miglioramenti inconfutabili del CALCESTRUZZO nel flusso di lavoro, puoi quindi provare a distribuirlo al resto della squadra e hai un paio di evangelisti che ti aiuteranno a farlo.

(*) per "nuovo VCS" non intendo necessariamente mercurial o git, può anche essere SVN (fatto bene).