2010-04-05 18 views
7

Proveniamo da uno sfondo di sovversione in cui abbiamo un responsabile QA che conferisce diritti al repository centrale dopo aver verificato che tutte le attività di controllo qualità sono state eseguite.hg controllo accessi all'archivio centrale

Io e un paio di colleghi stiamo iniziando a usare mercurial, e vogliamo avere un repository condiviso che contenga le nostre modifiche QC-ed. Ognuno degli sviluppatori hg clona il repository e trasferisce le sue modifiche al repository condiviso. Ho letto il tutorial di avvio di HG e ho sfogliato il libro dei bean rossi, ma non sono riuscito a capire come controllare chi è autorizzato a trasferire le modifiche al repository condiviso.

Come si tradurrà il nostro modello esistente di controllo QA-manager in un repository "centrale" mercuriale?

+0

Come stai servendo i repository? –

+1

http://mercurial.selenic.com/wiki/PublishingRepositories#Allowing_Push –

risposta

0

serverfault.com ha uno question rilevante e collegamenti alla pagina Wiki Mercurial Publishing Repositories. Il primo mostra come configurare l'accesso per-repository quando si utilizza hgweb sul server. Ho la sensazione che tu stia usando ssh che la pagina wiki etichetta come "privata" e sono quindi incline a credere che dovresti ricorrere al controllo degli accessi al file system, ovvero rendere tutti i file nel repository appartengano al gruppo "committenti", danno ai membri del gruppo accesso in scrittura e tutti gli altri leggono/solo.

+0

ssh funziona bene con le direttive di controllo degli accessi _IF_ ognuno ha il proprio account ssh. È solo se tutti condividono un account ssh che è necessario ottenere informazioni sull'accesso con chiave selezionato tramite qualcosa come hg-ssh o (yuck) mercurial-server. –

2

Il commento di HenriW che chiede come stai servendo i repository è esattamente la domanda giusta. Il modo in cui configuri l'autenticazione dipende interamente da come stai servendo il tuo repository (HTTP via Apache, HTTP tramite hg-serve, ssh, ecc.). Il meccanismo di trasporto fornisce l'autenticazione e quindi usi mercuriali che con i comandi del collegamento di Mr. Cat (inutili di per sé) per gestire il controllo degli accessi.

Dal momento che non hai menzionato come stai servendo il repository, probabilmente è stato un po 'facile da configurare (ti saresti ricordato di menzionare la seccatura per un'installazione di apache o ssh :). Quindi brutto questi due:

Se si utilizza hg, servire, quindi non si dispone di impostazione di autenticazione. È necessario utilizzare apache, lighttp o nginx davanti a hgweb o hgwebdir per fornire l'autenticazione. Fino a quando non fai le opzioni allow_ * e deny_ * sono rigorosamente tutti o nessuno.

Se stai usando ssh quindi si sta già ricevendo il tuo SSH autenticazione Fromm (e probabilmente il sistema operativo), in modo da poter utilizzare l'allow_ * e * deny_ direttive (e controlli di accesso del file system se si desidera piace).

Problemi correlati