SVN è fuori moda? [chiuso]

Sono passati solo diversi anni da quando sono passato da Visual Source Safe a SVN. E SVN per me è ancora un po '"WOW! Posso fare così tante cose! SVN è così bello!"

Ma molte persone intorno a me continuano a dire "SVN? Davvero? Meh ..."

E ce ne sono così tanti che sono preoccupato. Devo spostare la mia squadra in Git / Mercurial o in qualche altra cosa di fantasia? So di sembrare ridicolo e la risposta ovvia sarebbe "rimanere con ciò che funziona per TE". SVN funziona per me ... Ma ogni volta che creo un nuovo progetto nel mio repository continuo a chiedermi: potrebbe essere questo il momento di trasferirmi?

Quindi ... SVN è davvero così male? Mi manca un'enorme opportunità rimanendo fedele?

Dipende interamente dall'uso.

Se hai una squadra di persone in una stanza e svolgono la maggior parte del loro lavoro lì, se hai un processo di compilazione e distribuzione che ti piace già e se non stai cercando di condividere il tuo codice con le persone ampiamente (come faresti con un progetto open source), quindi non dovresti sudarlo.

Sono passato forse un anno fa da Subversion a git. Git perfettamente adeguato anche per quel caso d'uso prevalentemente locale, ma dove brilla davvero è lo sviluppo distribuito. Utilizzato localmente, è bello avere github come backup remoto e una bella interfaccia web per il codice, e mi rende facile far partecipare gli appaltatori. Ma non ne sto ricavando molto in questo momento che non stavo ottenendo da Subversion.

Non essere spazzato via nel flusso costante di hypes. Hai qualcosa che funziona, continua a usarlo fino a quando non c'è un requisito aziendale che è meglio soddisfatto con qualcos'altro (no, un nuovo brillante sistema di controllo del codice sorgente o un linguaggio di programmazione ogni pochi mesi, ogni volta che viene pubblicizzato qualcosa di "nuovo e migliorato", NON va per soddisfare le tue esigenze aziendali meglio di quella che stai utilizzando ora).

Se SVN lavora per la tua organizzazione, non c'è quindi motivo di investire i soldi / il tempo / lo sforzo necessari per passare a qualcos'altro, per quanto alcune persone lo vogliano perché è nuovo e brillante.

E no, non è (come pensa JBK) una decisione che dovrebbe spettare al "team", è una decisione che spetta al management dopo aver consultato tutte le parti interessate (che include almeno i vostri amministratori di sistema). È una decisione aziendale spendere soldi per cambiare il tuo stack tecnologico, non una decisione tecnica.

Credo che non si dovrebbero mai prendere decisioni per ignoranza. Se non sai cosa ti perdi, dovresti provare a uscire abbastanza a lungo fino a quando non lo fai, quindi puoi prendere una decisione informata. Il salto verso il controllo distribuito non può davvero essere compreso senza provarlo e lasciar andare alcune vecchie abitudini mentre lo fai. La maggior parte del potere di DVCS è che puoi creare tutti i rami che vuoi, per qualunque motivo tu voglia. Se lo provi per un mese e non hai creato almeno 5 filiali o giù di lì, non l'hai testato alle sue condizioni. Questo è l'errore della maggior parte delle persone che non "ottengono" git. Dopodiché, se torni a svn, almeno conoscerai i motivi per te.

Non ho usato Git, ma ho usato Mercurial e non vedo davvero quale sia il grosso problema. Sembra molto simile a SVN, tranne per il fatto che le cose di base come il check-in e il check-out sono più complicate (richiede due passaggi anziché uno). In cambio, dovrebbe rendere molte cose più avanzate che in realtà non ho mai avuto bisogno di fare molto più semplici. La mia reazione alle affermazioni che DVCS è in qualche modo intrinsecamente superiore è fondamentalmente "OK, certo, prenderò la tua parola per questo", e poi proseguo con SVN, che funziona bene per me.

La risposta ovvia qui è lasciare che la squadra decida e discuti su quale sia l'opzione migliore per tutti in modo che non sia qualcuno che chiama i colpi nel vuoto. Potrebbero esserci varie opinioni e preoccupazioni da affrontare, ma preferirei cercare una risposta di consenso piuttosto che cercare di essere dittatoriale su cosa usare.