Quale si consiglia per un progetto commerciale con gli sviluppatori che devono avere accesso solo a una determinata parte del repository?SVN o Git per repository con controllo di accesso gerarchico
sviluppo IDE è Eclipse
e il linguaggio di programmazione è il C/C++
Le caratteristiche principali del requisito è: accesso gerarchico autorevole e ACL per repository
Git, in combinazione con un server "centrale" gestito con Gitolite, è in grado di fornire tutto il controllo a grana fine di cui hai bisogno (per utente/per gruppo, con accesso a tutto o solo parte del repository, anche a solo alcune filiali).
Detto questo, se i tuoi sviluppatori hanno più familiarità con un CVCS come SVN, potrebbe essere più saggio utilizzare tale conoscenza almeno per avviare il progetto (e usa il metodo di autenticazione nella configurazione del tuo server Apache): a CVCS can be quite different from a DVCS.
(in più puoi ancora convertire un repository SVN in uno Git)
Git è molto più modulare e flessibile di SVN. Se alcuni sviluppatori hanno solo bisogno di accedere a una parte del repository, puoi renderlo un sottomodulo (cioè un repository indipendente che viene aggregato dal tuo repository principale). È molto più facile concedere l'accesso a un repository diverso rispetto a una singola directory all'interno di un filesystem.
È prassi comune che API o plug-in siano separati dal repository principale. Per ulteriori informazioni, dai un'occhiata a there.
Ultimo punto, software come Gitolite (quello che utilizzo per i miei progetti) e Gitosis (quello che usiamo al lavoro) rendono molto facile l'amministrazione dei repository git.
Sono d'accordo con te, quello che ho trovato più facile è che è possibile avere più repository Git e semplicemente spingerli al main Git Repository, è più facile ottenere il controllo di accesso gerarchico e avere anche il controllo di qualità in questo modo, in qualche modo come il progetto di FreeBSD ma usano CVS – kay
È necessario utilizzare SVN. Motivi:
- Per un progetto commerciale, più sviluppatori hanno familiarità con SVN. E SVN ha potenti strumenti GUI. Immagino che non vuoi sentire lamentele su "git è difficile da usare". (Mi piacciono sia git che svn)
- Git mantiene localmente troppe informazioni sulla versione, questo non è ciò che si vuole per un progetto commerciale in generale.
Perché esattamente non dovrebbe un progetto commerciale memorizzare le informazioni sulla versione localmente? Consente agli sviluppatori di lavorare in modo efficiente localmente, quindi di inviare al server centrale dell'azienda al momento opportuno. Se i tuoi sviluppatori non seguono i criteri aziendali, allora possono usare 'svnsync' e poi fare qualsiasi azione nefasta di cui tu abbia paura. –
Non farmi la domanda. Non importa ciò che replay, la verità è che alcune persone la pensano così nel mondo. –
Non c'è assolutamente alcun motivo per nascondere rami o alberi, il concetto dietro l'accesso gerarchico alle fonti è molto più facile da ottenere con Git e più repository, in un modo che non include quelle parti che lo sviluppatore non dovrebbe conoscere o lavorare su , ad esempio, uno sviluppatore della GUI non dovrebbe occuparsi di Digital Signal Processor e quindi il codice DSP non è disponibile per lui, semplicemente togliendolo dal suo repository Git o sostituendo i file oggetto anziché le fonti, – kay
Utilizzando Apache o svnserve come assistente, grana fine Per-directory access control è disponibile. Path-Based Authorization concede agli utenti o ai gruppi l'accesso definito al tuo repository. Lo stesso vale per websvn, se anche un'interfaccia web dovrebbe essere disponibile.
È possibile ottenere la stessa cosa con SVN , ma da molto tempo utente SVN, ho trovato Git molto più facile da raggiungere, dal momento che posso stabilire anche archivi gerarchici, vedo che è possibile su SVN ma con molto più dolore – kay
@kay: ciò che è * "molto più dolore "*? Impostare * gitolite * o * authz * non sarà una grande differenza. Riguardo ** strategie di fusione ** DVCS come * GIT * hanno vantaggi, ma non riguardano la gestione degli accessi. – zellus
sì, il problema è che non si ottiene il punto, è sep, non solo contrarazione di accesso, con Git è possibile avere repository di repository e commettere (spingendo) i repository verso l'alto (questo non è disponibile in SVN – kay
Tuttavia ho scelto Git, con Git è più semplice ottenere qualsiasi modello, il suo sistema di controllo della versione distribuito consente di ottenere un controllo di accesso gerarchico molto più semplice, è chiaro che dobbiamo permettere agli sviluppatori di lavorare sui loro progetti particolari, quindi perché non hanno una copia del ramo o del modulo del repository su cui stanno lavorando, comunque devono sapere a cosa stanno lavorando per svilupparlo, quindi hanno bisogno di quella parte, quello che ho trovato molto interessante riguardo a Git è che possiamo raggiungere questa struttura gerarchica attraverso stabilendo diversi repository Git quindi unisci i loro risultati in uno upstream, – kay
Accetto con SVN è anche possibile ottenere tali compiti con molta più sofferenza, naturalmente, personalmente ho utilizzato SVN, ma ho trovato Git più semplice e veloce con opzioni illimitate e il supporto di Eclipse come EGit e JGit sono abbastanza accettabili per andare d'accordo con Git, senza necessità di te sviluppatori ingannevoli su come lavorare con Git sottostante, altri concetti sono gli stessi di SVN in realtà dal modo in cui è il controllo di versione – kay