Esistono casi aziendali che hanno fatto spostare un'azienda da un DVCS a un CVCS (indipendentemente dal fatto che fossero originariamente su un CVCS)?
Oltre ad avere una mente chiusa e rifiutando del tutto il cambio di paradigma (per il caso particolare di aziende che provengono da un CVCS) non riesco a pensare a nessuna causa che possa accadere.
Doppio biscotto al cioccolato per chiunque abbia una prova empirica.
Faccio Mercurial consulting e la mia esperienza è che le grandi aziende dedicano molto tempo in anticipo per indagare sui pro e contro di DVCS. Quindi, quando finalmente fanno il salto, hanno già utilizzato DVCS per uno o due progetti pilota e quindi sono abbastanza sicuri che funzionerà per il resto del gruppo.
Tuttavia, conosco un esempio in cui Mercurial è stato testato in produzione ma poi abbandonato. Era un client che progettava hardware e che comporta un numero enorme di file binari che non si comprimono o si fondono molto bene. Stiamo parlando di oltre 10.000 file, ognuno con una dimensione di almeno 10 MB. Quindi un pagamento ha una dimensione superiore a 100 GB.
Prima di contattarci, il cliente spende un sacco di sforzi per scrivere un'estensione per Mercurial che esternalizzi l'archiviazione di questi file. L'idea era che i file venivano scaricati su richiesta quando si effettuava un checkout, non quando si eseguiva un hg clone . Quella era la cronologia di ogni file che verrebbe memorizzata su un server di archiviazione centrale e i client scaricheranno solo ciò di cui hanno veramente bisogno. Molto simile a Subversion, ma con i vantaggi di DVCS per tutti gli altri file di progetto. (Mercurial ora viene fornito con l'estensione file di grandi dimensioni che implementa questa idea.)
Tuttavia, nonostante i loro sforzi, non sono stati in grado di far funzionare la loro estensione in modo efficiente e il team dell'hardware alla fine si è allontanato da Mercurial e ha iniziato a valutare sistemi più tradizionali come Perforce. Non conosco tutti i dettagli e credo che avremmo dovuto essere in grado di farlo funzionare, specialmente utilizzando gli file di grandi dimensioni ora disponibili estensione . Certo, l'estensione non sarà perfetta per 10.000 file come è ora (l'overhead per file è troppo grande), ma è qualcosa che può essere risolto un problema alla volta mediante il batching di query e lo stream-lining.
Quindi il mio consiglio è:
Assicurati di eseguire test approfonditi prima di implementare un DVCS. Trova un piccolo gruppo di sviluppatori che pensano che DVCS sia bello e fagli pubblicare un progetto o due.
Contatta qualcuno che sa cosa funziona bene e cosa funziona meno bene. In alto, siamo stati chiamati solo molto tardi nel processo ea quel punto il cliente si era impegnato a fare scelte non ottimali. C'è un numero di opzioni di supporto per Mercurial e ti incoraggerò a utilizzarli.
I due non sono alternative esclusive.
Gli strumenti CVCS offrono forti funzioni di autorizzazione.
Alcuni hanno il proprio meccanismo di autenticazione incorporato ( SVN con svnserve , RTC e il suo registro utente , Perforce e il suo P4Admin ): possono avere il proprio database utente interno, dedicato ai loro strumenti.
Gli strumenti DVCS no. Vedi " Possiamo finalmente passare a DVCS in Corporate Software? ".
Nessun meccanismo di autenticazione e autorizzazione integrato.
DVCS: nessuna autenticazione :
Mentre CVCS può interfacciarsi con fonti di autenticazione esterne (come un LDAP), DVCS non ha altra scelta che interfacciarsi con fonti di autenticazione esterne, usando solo processi esterni ( openssh , httpd , .. dal momento che possiedono un server leggero interno non ha un'autenticazione contraria a un SVN svnserve ).
DVCS: nessuna autorizzazione :
Se si ha accesso al percorso del repository (attraverso file, ssh o http), allora si dispone dei privilegi tutti (lettura, scrittura, eliminazione, ... su qualsiasi ramo).
Se hai bisogno di un controllo di accesso a grana più fine, devi aggiungere un ulteriore livello allo strumento (RhodeCode for Mercurial o Gitolite for Git).
Questi vincoli significano che un DVCS ha solitamente diversi casi d'uso rispetto a un CVCS all'interno di una grande azienda.
Ad esempio, ho implementato entrambi , con DVCS utilizzato per consentire alle aziende di terze parti di collaborare su un code-base condiviso limitato con la società.
Considerare un DVCS consente di clonare un repository all con la sua cronologia completa , il che significava che dovevamo elaborare un meccanismo di importazione-esportazione che ci consentisse di esportare e pubblicare nel DVCS solo alcune parti del repository CVCS (grande), in modo che le terze parti possano accedere solo a ciò di cui hanno bisogno per lavorare.