DVCS (Mercurial) non fa per me?

Question

Lavoro in un'azienda in cui creiamo molte piccole applicazioni specifiche del cliente. Siamo pochi sviluppatori ma la maggior parte delle volte esiste un solo sviluppatore per progetto.

Customer1 
    ProjectX 
     App 
     Tests 
    ProjectY 
     App 
     Tests 
Customer2 
    Project2 
Products 
    Product1 
Common 

Oggi tutto è archiviato in un unico repository.

Il processo è semplice.

1. Uno sviluppatore assume un nuovo progetto per un cliente
2. Creare una nuova cartella per il progetto
3. codice nel nuovo progetto
4. Fare un po 'di manutenzione in un altro progetto
5. Arrivo aggiornamenti di manutenzione proiettare
6. più lavoro in nuovo progetto
7. Arrivo nuovo progetto
8. Consegna al cliente

Non c'è tag né branching. Le versioni precedenti vengono verificate in base alla data.

Questo processo ha servito bene per molti anni, ma ci sono alcuni punti di dolore con lo strumento corrente (CVS)

• lento. Il checkout richiede minuti anche se nulla è cambiato. La cronologia è memorizzata sul server, quindi le differenze richiedono troppo tempo
• Aggiunta di nuovi progetti. Se hai lavorato con CVS, sai che è come: aggiungi cartella, aggiungi file in cartella, aggiungi cartella successiva ...
• Impossibile annullare gli errori evidenti (controllare i file binari, ecc.)
• Nessun supporto per la ridenominazione che rende refactoring necessario ancora più doloroso.

Ho usato Mercurial privatamente per un po 'di tempo e vorrei estenderlo a tutti gli sviluppatori.

Potrei aver sbagliato tutto ma ci sono alcune cose che non capisco come implementare nella nostra organizzazione.

I commit del CVS sono solo nella cartella corrente ma in mercuriale sono ampi. Nel nostro caso significa che il commit dei lavori di manutenzione in una cartella commetterà anche cose non finite in un'altra cartella. (suppongo che potremmo fare hg ci ./** in cartelle modificati, ma che non è consentito il merge, almeno questo è ciò che la documentazione dice If you are committing the result of a merge, do not provide any filenames or -I/-X filters.)

La pratica comune in Mercurial è quello di avere un repository per progetto.

Un repository per progetto è OK per noi, ma crea alcune altre questioni come:

Come gestire più repository sul server centrale?
Se uno sviluppatore crea un nuovo progetto, alla fine ha bisogno di spingere le sue modifiche. Solo facendo

hg push http://localhost:8000/Customer1/NewProject

blocca il hg-server web con un dump dello stack brutto e si blocca il cliente.

Il modo in cui ho capito è che lo sviluppatore bisogno di accedere al server shell per aggiungere il nuovo repository in un file di configurazione e riavviare hgweb

L'alternativa è quella di utilizzare SSH o una quota (ci sono benefici dell'uso SSH invece di una condivisione di file?)

cd Customer\NewProject 
hg init 
hg clone --noupdate --pull . //mercurialshare\Customer\Project 
echo "[paths]" >.hg\hgrc 
echo "default=//mercurialshare\Customer\Project" >>.hg\hgrc 

hg push 

Works, ma è un po 'complicato per per alcuni sviluppatori

tutti gli sviluppatori devono avere tutti i progetti.
(Non proprio tutti, ma molti progetti sono legati quindi hanno bisogno di essere presenti ed è più facile da avere solo tutti)

Con molti progetti esistenti e quelli nuovi aggiunti ogni settimana abbiamo bisogno di un modo per tirare tutti i progetti in un unico vai e clona anche quelli nuovi.

Stavo pensando che subrepos potrebbero risolvere il tiro "globale", ma la seguente linea nella documentazione è un bloccante

"Quando commettiamo, Mercurial tenterà di creare un'istantanea coerente dello stato di tutta la project e suoi sottostanti Fa questo tentando prima di eseguire il commit in tutti i subrepos modificati e quindi registrando lo stato di tutti i subrepos. "

Torna al problema del repository singolo dei commit globali.

(provato un paio di varianti di hg ci .hgsub .hgsubstate <subrepo> ma .hgsubstate sembrano essere aggiornati solo su commit complete. Gli altri utenti non vedranno cambiamenti di progetto, senza un esplicito hg pull --update nella cartella del progetto)

mio pensiero attuale è di avere un file batch nella radice che trascina tutti i progetti

Qualche altra idea su come usare mercurial nella nostra organizzazione?

Modifica

Grazie per la risposta. Attualmente sto valutando come un repository per progetto funzionerà per noi. Ho messo un file batch al livello più alto

FOR /F %%x IN (repolist.txt) DO (
    If EXIST .\%%x\.hg (
     ECHO Pull %%x 
     hg pull --update --repository .\%%x 
    ) ELSE (
     ECHO Clone %%x 
     mkdir .\%%x 
     hg clone --pull %1\%%x .\%%x 
    ) 
) 

Answer 1

Ha il diritto di dire che Mercurial è progettato per un progetto per repo. È anche molto più bello quando lavori così perché la storia di diversi progetti viene tenuta separata.

Cercare di avere più progetti in un repository DVCS provoca solo dolore.

Personalmente preferisco servire progetti via SSH piuttosto che HTTP. Uno dei motivi è la capacità di ...

# hg init blah 
# hg clone blah ssh://server/blah 

Se stai servendo tramite HTTP questo non funziona (come hai scoperto).Sono sorpreso che causi un duro incidente però: -/

Il metodo di sub-repos di ottenere tutti i progetti non è esattamente come lo descrivi. Non è che torni ai commit globali (i progetti possono essere sviluppati individualmente), ma che il super-progetto memorizza la versione dei sottoprogetti da cui dipende. Questo è esattamente ciò che si desidera se si dispone (ad esempio) di una libreria come sottoprogetto, ma la versione dipende da una versione specifica. In effetti, un link sub-repo è un segnalibro in un altro repository in una versione specifica.

Non proprio quello che stai cercando però.

Forse, le cose comuni dovrebbero essere un sub-repo dei progetti che ne hanno bisogno. Ogni progetto potrebbe quindi essere congelato su una versione diversa dello stesso codice e non hai problemi. Ciò richiederebbe un po 'di riflessione.

Altrimenti l'idea di script è probabilmente la più semplice.