I grandi depositi mercuriali soffrono di una "corsa spietata"?

Naviga le tue risposte
9

Leggendo alcuni "Perché un DVCS è meglio" risponde a diverse domande su Programmers.SE tutti sembrano dire che, in generale, DVCS è meglio perché non si ha una gara di commit in grandi progetti, IE commit, out data di aggiornamento, commit, data non aggiornata, commit, non aggiornato, ecc.

Il DVCS limita questo concetto al concetto di spinta. Tuttavia, in progetti molto grandi non ci sarebbe una "corsa di spinta", specialmente alla fine della giornata? So che in Git questo è un po 'rimediato dalla costante ramificazione di tutto, ma in Mercurial non ti rammenti, crei una nuova testa.

Problema che vedo

  1. L'utente tenta di spingere
  2. Non aggiornato (mercurial non ti consente di spingere se il tuo repository locale non è aggiornato), quindi estrai e unisci le modifiche locali
  3. L'utente tenta di eseguire nuovamente il push, ma mentre si univano, un'altra persona ha fatto push, quindi non sono più aggiornati
  4. Apri e unisci di nuovo
  5. Ancora non aggiornato
  6. Ripeti

Suona familiare?

Questo è un problema reale con repository mercuriali molto grandi e popolari? Che ne dici di una società quando tutti fanno la loro ultima spinta del giorno?

    
posta TheLQ 05.06.2011 - 23:54
fonte

2 risposte

8

Per quanto ne so, la maggior parte dei grandi progetti open source che usano DVCS usano "richieste pull" invece di push, cioè un utente richiede che il progetto arrivi dal proprio ramo, e il prject può scegliere di intraprendere queste richieste di pull in qualsiasi ordine, se non del tutto. Questo elimina il bisogno di "spingere la corsa", come lo hai chiamato.

In altre società non posso garantire per il processo, ma dove lavoro questo non è un problema.

Vedi, quando stai lavorando su un caso stai lavorando su un ramo dell'intero repository, quindi le tue richieste push vanno a una versione remota del trunk principale. Quando vuoi integrare il tuo (finito) cambio nel bagagliaio, carica il tronco, tira, unisci, spingi.

Occasionalmente ( molto di tanto in tanto) due persone proveranno a farlo nello stesso momento (normalmente a causa di alcuni problemi di comunicazione). In questo caso chi "perde" dovrà solo ri-tirare, unire, spingere. Dal momento che non ci sono rush alle 17:00 da impegnare in un repository centrale, il problema che hai delineato non è proprio lì.

Questa è la bellezza di DVCS: la ramificazione è indolore, quindi tutti possono lavorare sul proprio ramo.

Modifica

Oh, ho appena notato il tuo commento "In mercurial you do not branch ...": Sì, lo sai. Non è necessario, ma dal momento che è così semplice e i vantaggi di farlo superano il fatto di non farlo molto, si tende a ramificare i repository molto spesso.

    
risposta data 06.06.2011 - 00:00
fonte
1

No, non c'è una gara push perché il lavoro è finito nelle sezioni tematiche . Un master di unione gestisce la (relativamente inferiore) complessità della combinazione dei rami in un ramo di integrazione . Questo di solito è fatto continuamente. Per maggiori informazioni sui flussi di lavoro di controllo delle versioni distribuite, la prima fonte sarebbe la bocca del cavallo: man gitworkflows , online qui . I flussi di lavoro Mercurial fanno usano la ramificazione nonostante il tuo reclamo e le tecniche sono simili.

    
risposta data 06.06.2011 - 00:02
fonte

Leggi altre domande sui tag

Raccomandazioni per l'unione di linee implicite contro quelle esplicite Algoritmi di visione del computer (come è possibile?)