Numero di revisione della sovversione su più progetti

StackOverflow https://stackoverflow.com/questions/15674

  •  08-06-2019
  •  | 
  •  

Domanda

Quando utilizzo Subversion (svn) per il controllo del codice sorgente con più progetti ho notato che il numero di revisione aumenta in tutte le directory dei miei progetti.Per illustrare il mio layout svn (usando nomi di progetto fittizi): 

    /NinjaProg/branches
              /tags
              /trunk
    /StealthApp/branches
               /tags
               /trunk
    /SnailApp/branches
             /tags
             /trunk

Quando eseguo un commit sul trunk del Programma Ninja, diciamo che ottengo che è stato aggiornato alla revisione 7.Il giorno dopo diciamo che faccio una piccola modifica all'applicazione Stealth e torna come revisione 8.

La domanda è questa: È pratica comune accettata, quando si mantengono più progetti con un server Subversion, aumentare il numero di revisioni dei progetti non correlati su tutti i progetti? Oppure sto sbagliando e dovrei creare repository individuali per ogni progetto?O è qualcosa di completamente diverso?

MODIFICARE: Ho ritardato nel segnalare una risposta perché era diventato chiaro che ci sono ragioni per entrambi gli approcci e, anche se questa domanda è arrivata per prima, vorrei indicare alcune altre domande che alla fine pongono la stessa domanda:

Devo archiviare tutti i progetti in un repository o in più repository?

Un repository SVN o molti?

È stato utile?

Soluzione

Sono sorpreso che nessuno abbia menzionato che questo è discusso in Controllo versione con Subversion, che è disponibile gratuitamente online, Qui.

Ho letto l'argomento qualche tempo fa e sembra davvero una questione di scelta personale, c'è un buon post sul blog sull'argomento Qui.MODIFICARE: Poiché il blog sembra essere inattivo, (versione archiviata qui), ecco alcune delle parole di Mark Phippard sull'argomento.

Questi sono alcuni dei vantaggi dell’approccio del repository unico.

  1. Amministrazione semplificata.Una serie di ganci da distribuire.Un repository di cui eseguire il backup.eccetera.
  2. Flessibilità di ramo/tag.Con il codice tutto in un unico repository è più semplice creare un ramo o un tag che coinvolga più progetti.
  3. Sposta facilmente il codice.Forse vuoi prendere una sezione di codice da un progetto e usarla in un altro, o trasformarla in una libreria per diversi progetti.È facile spostare il codice all'interno dello stesso repository e conservarne la cronologia durante il processo.

Ecco alcuni degli svantaggi dell'approccio a repository singolo e i vantaggi dell'approccio a repository multipli.

  1. Misurare.Potrebbe essere più semplice gestire molti repository più piccoli rispetto a uno grande.Ad esempio, se ritiri un progetto puoi semplicemente archiviare il repository su un supporto, rimuoverlo dal disco e liberare spazio di archiviazione.Forse hai bisogno di scaricare/caricare un repository per qualche motivo, ad esempio per sfruttare una nuova funzionalità di Subversion.Questo è più facile da fare e con un impatto minore se si tratta di un repository più piccolo.Anche se alla fine vorrai farlo su tutti i tuoi repository, avrà un impatto minore eseguirli uno alla volta, presupponendo che non vi sia un bisogno urgente di eseguirli tutti in una volta.
  2. Numero di revisione globale.Anche se questo non dovrebbe essere un problema, alcune persone lo percepiscono come tale e non amano vedere il numero di revisione avanzare nel repository e che i progetti inattivi abbiano grandi lacune nella cronologia delle revisioni.
  3. Controllo di accesso.Sebbene il meccanismo di autenticazione di Subversion ti consenta di limitare l'accesso secondo necessità a parti del repository, è comunque più semplice farlo a livello di repository.Se hai un progetto a cui possono accedere solo poche persone selezionate, è più semplice farlo con un unico repository per quel progetto.
  4. Flessibilità amministrativa.Se disponi di più repository, è più semplice implementare diversi script di hook in base alle esigenze del repository/progetti.Se desideri script di hook uniformi, allora un singolo repository potrebbe essere migliore, ma se ogni progetto desidera il proprio stile di email di commit, allora è più semplice avere tali progetti in repository separati

Se ci pensi davvero, i numeri di revisione in un repository di più progetti aumenteranno, ma non finirai.Tieni presente che puoi visualizzare una cronologia in una sottodirectory e vedere rapidamente tutti i numeri di revisione relativi a un progetto.

Altri suggerimenti

Penso che sia altamente raccomandato creare repository separati per ciascun progetto.Se non altro per evitare lo scenario di cui parli.

Con il controllo della versione, in particolare Subversion, puoi facilmente estrarre parti di un repository in un'altra copia di lavoro e quindi trasferirle nuovamente nei rispettivi repository.Ciò ti consente di mantenerli chiaramente separati e distinti offrendo allo stesso tempo una grande flessibilità.Una volta entrato un po' di più in SVN (suppongo che tu sia nuovo) puoi iniziare a utilizzare gli hook e potrei vedere dove ciò potrebbe diventare difficile con la tua configurazione.Se per te i permessi sono importanti, un singolo repository potrebbe rivelarsi più difficile del necessario.

Inoltre, se temi che ci vorrà molto tempo per configurare ciascun repository, cerca nella variabile SVNParentPath per il file di configurazione di Apache.(Ancora una volta, suppongo che tu stia utilizzando Apache.)

Ciò è dovuto al modo in cui funziona la sovversione.Ogni revisione è in realtà un'istantanea del repository identificato da quel numero di revisione.Se tutti i tuoi progetti condividono un repository, è inevitabile.In genere, secondo la mia esperienza, tuttavia, configureresti repository separati per progetti completamente indipendenti.Quindi la risposta breve è no, non stai facendo nulla di male, è una domanda comune riguardo a Subversion, ma ha senso se pensi a come memorizza le informazioni del repository.

Il numero di revisione dovrebbe in realtà essere solo un identificatore per una versione particolare.Che sia sequenziale o meno per un progetto non dovrebbe avere importanza.Detto questo, posso capire che non è proprio l'ideale.

La maggior parte dei progetti che ho riscontrato sono stati configurati in un unico repository e gli ID di revisione si comportano in questo modo.Non conosco alcuna opzione di configurazione SVN per modificare questo comportamento e, IMHO, il mantenimento di più repository sembra un sovraccarico non necessario.

Abbiamo solo un repository con tutto ciò che contiene, praticamente esattamente come il tuo esempio.

Non vedo nulla di sbagliato in questo: l'unico requisito per il numero di revisione è che lo sia

  • Unico
  • Atomico
  • Più grande di quanto fosse all'ultimo check-in

Per quanto mi riguarda, non importa se aumenta di 1 o 50 con ogni commit.

@grom:

Quindi ogni volta che inizio un nuovo progetto eseguo semplicemente:

svnadmin create /var/www/svn/myproject

Vedo che funziona bene se hai solo 1 o 2 sviluppatori, ma cosa succede se le persone che stanno creando nuovi progetti non hanno accesso alla shell sul server SVN per poter creare directory in /var/www ?

Si consiglia di utilizzare un repository separato per progetto.Nella mia directory Apache conf.d ho subversion.conf che contiene:

<Location /svn>
  DAV svn
  SVNParentPath /var/www/svn

  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /var/www/svn/password
  Require valid-user
</Location>

Quindi ogni volta che inizio un nuovo progetto eseguo semplicemente:

svnadmin create /var/www/svn/myproject

Hm, dove lavoro abbiamo tutti i nostri progetti nello stesso repository.Davvero non vedo il vantaggio di separarli, non crea solo molto lavoro extra, creando nuovi repository, garantendo l'accesso alle persone, ecc.?Immagino che repository separati abbiano senso se i progetti non sono completamente correlati e si hanno, ad esempio, clienti esterni che devono avere accesso al repository.

Nel mio posto di lavoro abbiamo due repository.Uno con accesso pubblico in lettura e uno per tutto il resto.Ne userei uno solo per tutto, ma abbiamo bisogno di diritti di accesso diversi per progetti pubblici/privati.

Detto questo, personalmente non vedo il problema con i numeri di revisione che aumentano ad ogni aggiornamento.I numeri di revisione potrebbero saltare i numeri primi e pari e fare comunque quello che dovrebbero fare.Semplifica il raggiungimento di una revisione specifica.

Se ti dà fastidio che i numeri di revisione cambino in base ad altri progetti, inserisci i progetti in repository separati.Questo è l'unico modo per rendere indipendenti i numeri di revisione.

Per me, il motivo principale per utilizzare repository diversi è fornire un controllo di accesso separato per gli utenti e/o utilizzare script di hook diversi.

Forse è meglio non creare necessariamente un repository per "progetto", ma piuttosto un repository per "soluzione" (per usare i termini di Visual Studio).Se hai un sacco di "progetti" in cartelle diverse ma sono correlati tra loro, inseriscili nello stesso repository.

Memorizzo un progetto per repository e come un precedente commentatore su questo questione della sovversione, contrassegno i progetti condivisi come esterni, in modo che siano nel controllo del codice sorgente solo una volta.

Sto appena iniziando ad aggiungere un server di build CI (CruiseControl.NET), quindi dovrò vedere come funziona, ma se i miei script di build sono corretti non dovrebbero essere un problema.

A parte l'apparenza, però, è davvero una questione di preferenze (secondo me).

Quando ci pensi davvero, i numeri di revisione in un multiplo repository del progetto diventeranno alti, ma non si eseguirà Cambio.Tenere presente che è possibile visualizzare una cronologia in una sottodirectory e Visualizza rapidamente tutti i numeri di revisione relativi a un progetto.

In realtà se stai costruendo codice Microsoft e usi i numeri di revisione svn come parte della stringa di versione, potresti rimanere senza.Il compilatore Microsoft genererà un errore se qualsiasi parte della stringa della versione è maggiore di 65535....Nel nostro caso abbiamo un enorme repository alla revisione 68876 e ci siamo scontrati con questo muro.

Un repository per progetto.

Il commento di Steven Murawski su CC.NET è interessante.Sarei interessato a sapere come funziona se è necessario specificare diversi repository di controllo del codice sorgente.

@Daniel Fone:I documenti SVN consigliano un progetto per repository, quindi questo è sicuramente il modo in cui i creatori intendevano che andasse.Dato che è possibile avere un server (Apache o svnserve) che mantiene più repository, non ho mai riscontrato problemi di sovraccarico eccessivo.Con Server VisualSVN, installare un server Apache e configurare più repository è un gioco da ragazzi.

Non sono sicuro che i documenti SVN raccomandino effettivamente un progetto per repository.Per lo più parlano dei vantaggi e degli svantaggi di ciascun percorso.Mi capita di utilizzare tre diversi repository, uno per 7 o 8 progetti tutti correlati, il che rende molto bello poter inviare copie compatibili di tutti i progetti semplicemente costruendo da una revisione (o verificando che siano compatibili guardando ai numeri di revisione su ciascuno).Il secondo archivio contiene un altro gruppo di progetti e documenti correlati, mentre il terzo è molto più piccolo.Ciò ci consente di trarre vantaggio dal fatto che i progetti correlati possono essere gestiti da un singolo numero di revisione, ma che i progetti non correlati non influiscono sul loro repository.

I numeri di revisione non hanno uso semantico.L'unica cosa è che sono in ordine sequenziale.Se scarichi il tuo progetto e lo importi in un altro repository, le tue versioni possono ottenere nuovi numeri di revisione.COSÌ MAI usa i numeri di revisione per contrassegnare le tue pubblicazioni o cose simili.Crea tag per le versioni (copie della revisione pertinente).

Avevo lo stesso problema nella mia azienda precedente, avevano circa 50 progetti in esecuzione in un repository ed era un incubo lavorare sugli stessi progetti a causa degli aggiornamenti svn che altri imprecavano....lol...

Una cosa che ho imparato che funziona sempre meglio, One project One Repo....non te ne pentirai mai.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top