Utilizzo di Subversion come repository di controllo origine standard per un'impresa di sviluppo di grandi dimensioni

Question

Sto cercando esperienze e best practice precedenti nell'istituzione di una grande azienda di sviluppo per utilizzare Subversion come repository di controllo del codice sorgente.

Per grande qui, intendo centinaia di sviluppatori/utenti!

Answer 1

L'unica azienda in cui ho lavorato con Subversion per centinaia di utenti non aveva i propri server. Invece era un servizio gestito da Collabnet.

Answer 2

• Seleziona la struttura della directory corretta dall'inizio - è una cagna da cambiare in seguito.
  • tendo a pensare che il "migliore" è organizzato dal progetto, con un tronco/tag/ramo sotto ogni progetto
• Ogni persona non ha bisogno di tutti i progetti estratto. Guarda solo quello che ti serve
• Trova un modo per condividere gli strumenti tra gli sviluppatori. Piccole cose come un programma diff di SQL che cattura i proc su server e li diffonde è inestimabile.
• Cerca di non lasciare che un progetto sia troppo grande. Cercando di aggiornare o impegnarsi in una cartella con 1GB è fastidiosamente lungo per calcolare
• figura fuori qualche strategia di aggiornamento per il server di sovversione
• Backup repository naturalmente - con la storia completa delle revisioni
• Trac è utile per collegare direttamente le persone a changelongs e diffs
• Divertiti. Esegui ricerche di parole chiave sul repository nel fine settimana e mostra quante volte le persone pronunciano parole maledette nel codice. Run a code swarm

Answer 3

Ho visto centinaia di sviluppatori utilizzare CVS per centinaia di progetti, quindi svn dovrebbe farlo bene. L'unico problema di cui ero a conoscenza riguardava lo spazio su disco utilizzato per le directory di lavoro e i relativi backup.

Answer 4

Ho lavorato a un team che ha implementato l'hosting Subversion interno in 3 aree geografiche e centinaia di sviluppatori e oltre 100 progetti. Alcune informazioni chiave

1. Utilizzare Ap_mod_svn anziché svnserve. È quindi possibile collegare l'autenticazione "subversion" a LDAP (o autenticazione ActiveDirectory) a quei team che non devono ricordare un altro login e password.

2. Creare più repository sullo stesso server anziché un unico repository con sottocartelle diverse per ogni progetto. In questo modo la gestione degli utenti e il controllo degli accessi è semplificato. Anche il compito di chiudere e archiviare i repository sul progetto di finitura è semplificato.

3. Abbiamo sviluppato semplici cgi-script Python per gestire utenti, permessi e script svn-hook per notifiche e-mail e feed RSS. Gli script hanno aiutato ad accelerare l'accettazione di svn da parte dei team di progetto.

4. È possibile inserire un proxy inverso ed esporre selettivamente i pochi progetti tramite l'accesso "https" dall'esterno della rete aziendale. In questo modo i team di fornitori/appaltatori esterni possono ottenere l'accesso controllato ai progetti.

Nel complesso, ci siamo trasferiti tutti i team di progetto in circa un anno per i nuovi sistemi (tra cui la migrazione dei dati dai sistemi già esistenti, come CVS e Visual SourceSafe).

Answer 5

Sono assolutamente d'accordo con Nitin Bhide. Le mie aggiunte:

se utilizzati per cvs alcuni flussi di lavoro in SVN sono molto diverse, ad esempio rami vendor, che sono inesistenti in CVS, perché appena cancellato tutti i file nella cartella vendor e copiare il nuova versione all'interno. Questo non funzionerà più in SVN.

Inoltre, se si è abituati a eclissi, molte cose in sovversivo come in subclipse sono diverse. Si dovrebbe formare gli utenti di abituarsi a numeri di revisione a livello mondiale come il più difficile da afferrare punto per gli utenti CVS

Importante è anche una strategia di migrazione per evitare di tempo di stallo per la developerteams se la loro migrazione repository non è riuscita