Usando male SVN - Mercurial è la risposta?

Sì.

Se si sostituisce "SVN" con "Perforce" nel proprio OP, si ha praticamente la situazione in cui mi sono trovato quando ho iniziato il mio lavoro attuale, anche fino alla copia manuale. Due anni dopo siamo su Mercurial e tutti sono d'accordo che è stato un grande cambiamento.

Abbiamo la possibilità di diramare e unire per caso di supporto , che è incredibilmente utile per il controllo qualità e la possibilità di creare qualsiasi numero di filiali 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 grande beneficio in termini di tranquillità che quando eseguiamo una distribuzione live, siamo quasi sicuri al 100% che funzionerà (problemi con ambiente / DB, che sono ovviamente fuori l'ambito del VCS).

Fondamentalmente, ciò che abbiamo guadagnato dal passaggio a mercurial è lo spazio per respirare. Non dobbiamo più preoccuparci del costo di una filiale o delle orribili sessioni di unione che inevitabilmente seguivano, tutto è molto più semplice. Usiamo anche FogBugz piuttosto pesantemente, quindi il tie-in di Kiln (il loro mercurial ospitato) è davvero utile.

Anche il commento sul sito hginit è azzeccato, come contorno per un flusso di lavoro di controllo della versione che funziona davvero (supponendo che lo aggiusti per il tuo particolare flusso di lavoro di QA della società).

L'unica pecca possibile nei controlli di versione mobili è che avrai bisogno di qualcuno che sia davvero una forza trainante dietro al cambiamento, che sia felice di leggere l'argomento e utilizzare veramente gli strumenti al meglio delle sue potenzialità, che a quanto pare voler fare.

Non sono d'accordo con i commenti sulla dimensione del team e sulla distribuzione del team in merito all'utilizzo o meno di DCVS. In realtà, si tratta della distribuzione di CODICE. Se si verificano più cicli di sviluppo in parallelo, sia casi di supporto su un sistema legacy, o un insieme di funzionalità o persino di nuovi sistemi (che con il suono che si fa), si trarrà vantaggio dall'uso di un DVCS.

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

link

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

In The End: Not Really About The Tools

In all of the time I’ve spent working with and integrating different source control systems, I’ve come to one conclusion: it’s not the tool, it’s how you use it. That’s a terribly hackneyed statement, but it seems especially true here. When used to properly manage source code changes – labeling for builds, branching by exception, etc. – even the lamest source control system (*cough*SourceSafe*cough*) will far outperform a Mercurial set-up with a bunch of haphazard commits and pushes.

No. La tecnologia risolve raramente questo tipo di problema.

Mercurial è più complesso di Subversion (sì, ramificazione e fusione sono migliori e forse più facili, ma il modello di Subversion è molto più semplice di quello di Mercurial). Se stai usando Subversion in un modo così audace, potresti finire usando Mercurial:

• a) Adeguatamente o meglio
• b) In modo inadeguato, ma migliore del tuo attuale utilizzo di Subversion
• c) Come inadeguatamente come ora
• d) Peggio di adesso

c) e d) sembrano i risultati più probabili. Annota perché pensi di finire a) o b).

Non posso parlare di come lavorano i grandi team, ma per i piccoli team molti di questi problemi SVN non sono in realtà problemi SVN ... Sono problemi di sviluppo. Se non stai seguendo i moderni standard di sviluppo (cosa più importante, facendo integrazione continua), allora il controllo delle versioni si trasforma nel disordine esatto che stai descrivendo ... Prima di saltare a un nuovo sistema, assicurati di eseguire una vera analisi delle cause alla radice del tuo problema ...

No. Gli strumenti non sostituiscono la metodologia.

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

SVN può fare ciò che ti serve e non c'è bisogno di cambiare cavalli a metà percorso per un dubbia pay-off.

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

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

1. Avvicinati a un "coach" per fornire una serie di workshop per il team. Probabilmente sarà una persona esterna (ironicamente, è spesso più facile per molti team fidarsi di un outsider piuttosto che fidarsi di qualcuno nel team). Deve essere qualcuno che conosce le sue cose dentro e fuori e può insegnare efficacemente queste abilità alle persone a tutti i livelli di comprensione e ideare un piano pragmatico per far uscire il nuovo VCS (*) dal flusso di lavoro del team.

2. Avvia un progetto "skunk-works" per testare e convalidare il nuovo VCS su un piccolo side-project. Scegli un paio di sviluppatori "alfa" che sono disposti a provare nuove cose e non ti preoccupare di fare un mucchio di esperimenti falliti. Quando la skunk-works è in grado di dimostrare CONCRETE miglioramenti irrefutabili nel flusso di lavoro, allora puoi provare a distribuirlo al resto del team e hai un paio di evangelisti che ti aiuteranno a farlo.

(*) di "nuovo VCS" Non intendo necessariamente mercuriale o git, può anche essere SVN (fatto bene).