mercurial per progetti OS e svn per progetti Enterprise?

Question

correggimi se sbaglio, ma non sono distribuiti SCM per progetti OS mentre gli SCM centralizzati sono migliori per progetti aziendali/privati?

causa con es. chiunque abbia a disposizione una copia esatta del repository con funzionalità di cronologia FULL, mentre con la centralizzazione si ottiene solo l'ultima copia di lavoro.

im più focalizzato su progetti privati, quindi mi chiedo se è meglio con SCM centralizzato o non importa?

Answer 1

È possibile use a DVCS (like mercurial) in large corporation.

I limiti di un DVCS rispetto ad un VCS sono essenzialmente:

• size (non si può all'infinito conservato tutto in un DVCS, significa che è necessario ripensare i dati di sviluppo as modules instead of a monolithic set of files che possono ancora essere trovati in grande progetti)
• gestione degli accessi a destra: non è così fine in un DVCS come può essere in VCS, essenzialmente perché molte parti esterne possono contribuire a un progetto, con diversi schemi di autenticazione utente. ownership è più difficile da gestire.
• workflow: un flusso di lavoro DVCS è più complesso anche se può emulate the one of a CVCS (quella centrale repo agisce come riferimento per tutti gli altri)

Detto, DVCS allows for a new way to publish dati (trazione/tiro), che può aiutare a "pre-consegna" tra team (quando una squadra desidera condividere lo sviluppo anche se sono ancora in corso e non ancora ufficialmente impegnata nel repository centrale): si diventa passive produced and an active consumer.

---

Tomislav Nakic-Alfirevic chiede nei commenti:

Potrebbe illustrare il secondo punto di confronto di un DVC con uno centralizzato?

La gestione degli accessi a destra è tricker, soprattutto se la grande azienda:

• deve condividere alcuni dei suoi repository con impresa esterna per condiviso out-sourced sviluppo
• permette alcuni dei suoi repository per essere clonato sul personal computer (quando si lavora in ambiente mobile su un altro sito, dove lo sviluppatore non ha sempre accesso alla rete aziendale)

In th ose cases, ovvero:

• l'autenticazione utente non è sempre facile da riconciliare (uno stesso utente può avere identità diversa a seconda di dove clona il repository). È possibile configurare un'autenticazione basata su SSH (gitosis, gitauth).
• i metadati associati al file sono limitate, attraverso Git tags for instance
  (il gruppo di un file per esempio potrebbe non esistere su un determinato computer in cui è clonato repository)
  (metadati da other tools are not transparently supported)
  (special characters in filenames can be problematic)
• i diritti di accesso sono spesso limitati a tutti i repository e non in modo nativo gestiti per ramo o per file (un server come gitolite per Git deve essere configurato per quello, al contrario di un CVS che ha sempre un server, il che significa che essere più chiuso per proporre un ACL a grana più fine)

Git per esempio is a bit too simple di rispondere direttamente grandi imprese corporation:

gente nuova a git (significato, ero suggerendo miglioramenti come questo quando ho iniziato troppo;)) spesso parlare di aggiunta di questa funzionalità o che caratteristica, senza rendersi conto che git è davvero molto semplice.
Ha file, directory, commit, tag e questo è il. potere
di E rispetto alle soluzioni centralizzate è il mancanza di identificativi di surrogati come ad esempio un percorso ramo, server assegnato il numero di sequenza, ecc

Sì, ci potrebbero essere più relazioni e metadati per rappresentare un sacco di cose.
Cronologia di file e unione, ridenominazione di directory, cherry picking, ripristino.
Ma tutto questo aggiunge complicazioni al modello di base, che ha già dimostrato di essere in grado di gestire queste cose - con avvertenze.
Ma il guadagno - la semplicità - vale bene questi avvertimenti.

Answer 2

No, sicuramente no. Questo suggerimento che DVCSes non sarebbe adatto per l'impresa è pertinentemente falso, un argomento FUD comune da parte di persone che per qualsiasi ragione hanno il desiderio di non abbandonare SVN.

In realtà, anche in contesti aziendali DVCSes offrono numerosi vantaggi:

• Possibilità di check-in di frequente senza rischiare che bloccano altre persone
• lavoro off-line
• alte prestazioni
• effettivo di ramificazione/fusione
• Modello di accesso pull

Per quanto riguarda quest'ultimo, è possibile dare agli sviluppatori esperti l'accesso diretto al repository principale, mentre per i membri nuovi o meno giovani il loro mentore preleva da loro e rivede le modifiche prima di inviarle.

Accesso alla discussione nella risposta sopra; in questo modo DVCSes ti dà più controllo sul tuo repository, mentre con SVN in genere l'unico modello reale è quello di dare a tutti i contributori l'accesso ad almeno parti del codice.

È possibile avere un controllo meno dettagliato sulle autorizzazioni per le sezioni con il codice, tuttavia è possibile fornire gruppi diversi (ad esempio il team di documentazione) il proprio clone del repository principale e unirlo periodicamente dopo la revisione. Oppure metti la documentazione in un repository completamente diverso.

Spesso è necessario disimparare le pratiche apprese con VCS centralizzati, tornare ai casi d'uso e che cosa si desidera fare e quindi considerare come un DVCS potrebbe potenziarlo.

Un ottimo articolo da leggere per ottenere informazioni sulle differenze tra i sistemi di controllo delle versioni è Making Sense of Revision-Control Systems.