Mi sono trovato a fare la domanda: dovrei creare un repository per tutti i progetti su questo client? o dovrei creare un repository separato per ciascuno?Devo avere 1 o molti repository?
Quale di norma si decide?
Si prega di elencare i vantaggi e gli svantaggi di entrambi gli approcci che portano alla vostra decisione.
EDIT: Si prega di contrassegnare come duplicato per uno dei seguenti modi:
Should I store all projects in one repository or multiple?
Ho un grande repository per le stesse ragioni la risposta di Ken:
Io uso un unico repository per "tutto" perché rende muoversi roba tra i progetti molto più facile - a almeno con SVN.
Io lavoro in un negozio di sviluppo .NET e abbiamo due repository di Visual SourceSafe. Uno per le nostre applicazioni .NET 1.1 legacy e uno per le nostre nuove applicazioni .NET 2.0/3.0/3.5.
C'è solo una ragione per cui posso pensare di non inserirla in un unico repository. E questo è che se non si ha accesso per configurare il server su cui si trova il repository, è necessario limitare le parti del repository a diversi gruppi di persone.
Abbiamo un server gestito centralmente in cui possiamo creare repository in base alle esigenze, ma non è possibile modificare la configurazione. Abbiamo un repository di codice principale che è solo per uso interno, ma ne creiamo altri per collaborare con persone esterne all'organizzazione.
Ho un repository per ogni progetto, perché mantiene i numeri di versione indipendenti. Ho seguito il pensiero illustrato nella sezione di aiuto di TortoiseSVN 4.1.5, "Layout del repository":
L'indicizzazione per progetto ha senso se i progetti non sono strettamente correlati e ciascuno viene verificato singolarmente.
Sto usando SVN per i miei backup locali in questo caso, quindi ha senso per me.
Abbiamo un repository per TIPO di progetto e tipo di persona che lo accede. Ad esempio, tutti i nostri progetti .NET sono in un unico repository e tutte le nostre applicazioni legacy si trovano in un unico repository. In questo modo i nostri sviluppatori .NET non possono ingannare inavvertitamente i nostri sviluppatori legacy (e viceversa).
Ho usato un repository per tutti i progetti fino a quando non è diventato così grande che il commit del progetto è davvero rallentato - questo era con Subversion. Se i tuoi progetti contengono molti dati, in particolare dati binari, ti consiglio di utilizzare repository separati. Se si sta principalmente memorizzando il codice, è più semplice mantenere un singolo repository.
Ricorda che non è necessario controllare un intero repository. È possibile selezionare qualsiasi sottoalbero specificandolo come parte dell'URL passato a svn co. – KeithB
Io uso diversi repository - anche se ammetto che quando si tratta di organizzare il codice, ho un po 'di OCD, e mi piace che le cose siano molto organizzate e distinte.
Gestisco i repository SCM presso la nostra azienda e al momento ne abbiamo tre: uno per i progetti principali, uno per i pacchetti/librerie e uno per il codice di terze parti. Se dovessi farlo di nuovo, avrei creato anche un repository separato per i file multimediali (abbiamo molti file mp3/wav che devono essere in controllo di versione), ma purtroppo sono sotto il nostro repository principale.
Penso che l'unico argomento valido per l'utilizzo di più repository (oltre ad essere organizzato in modo ossessivo) è che rende più semplice gestire i diritti di accesso per ciascuno di questi repository, mentre a seconda del proprio ambiente SCM, potrebbe non essere così facile per più percorsi sotto un singolo repository.
Io uso git per quasi tutto. Quindi ho un repository per Project (sia esso/etc, progetti di codifica o file di configurazione utente).
se si utilizza un repository per tutto ciò rende più difficile impostare una build automatizzata o continua l'integrazione. Anche se non hai intenzione di farlo adesso, non è una cattiva idea impostarlo ora, questo ti dà anche il vantaggio di semplificare la gestione dei tuoi contenuti.
Una buona regola empirica è creare un repository per ogni gruppo distinto di soluzioni \ progetti.
Se si dispone di soluzioni che non condividono nulla, creare un repository per ciascuna. Un altro esempio potrebbe essere se si dispone di una versione .NET 1.1 della propria applicazione e si desideri creare una versione 2.0 del ramo di applicazione del codice e creare un repository separato per il nuovo codice, anche con .NET 3.0 e. NET 3.5.
Non vedo come sia più difficile creare build automatici con un singolo repository. Puoi sempre eseguire il checkout di una sottostruttura. – KeithB
forse parlando di ganci? –
utilizzando i Hook per l'integrazione continua, è possibile controllare un albero secondario, ma poi è necessario tenere traccia del sottostruttura. quindi diventa un problema mantenere su quali sotto alberi controllare cosa ecc. se si fa un po 'di organizzazione per iniziare e la manutenzione sarà molto più facile –
infatti, la ricerca dello stack non li ha visti con i termini che ho usato. –
Non possiamo unire queste domande, per quanto possiamo? Terrò questo aperto perché più risposte sono meglio di meno. I puntatori alle altre domande dovrebbero essere sufficienti. –
Ho cercato "Dovrei avere uno o più repository?" (la tua domanda) e il link nella modifica sopra è # 2 nella lista. Non penso che ci sia una fusione, e l'altra Q non si collega a questa. Nessun duplicato è migliore. – Bratch