domande di struttura eversione

Question

Appena trasferita alla sovversione ... da Visual Studio. I love it già! Qualcuno può spiegare brevemente

1. Repository
2. Filiali
4. Trunk

Devo creare un nuovo repository per ogni progetto? O un nuovo tronco?

Grazie

Answer 1

Non è necessario un archivio separato, ma è possibile, se si desidera. Mi raccomando di leggere il libro a http://svnbook.red-bean.com/ . Afferra la versione pdf o qualsiasi altra cosa. Non ci vuole troppo tempo, e spiega alcune cose piuttosto bene. L'ho letto, e ha scoperto che io sono contento di averlo fatto.

Answer 2

Ricordate che la sovversione è solo un file system di fantasia che supporta il controllo delle versioni. Pensate a un repository come "root drive" come "C: /".

Ogni progetto riceve una directory trunk, tag e rami. Tutti della vostra giornata per giornata di lavoro accade nel bagagliaio. codice sperimentale è fatto in un ramo e poi fuse nuovamente dentro il bagagliaio in un secondo momento. I tag sono per quando si rilascia il software. Questi sono non per essere modificato. Quando si rilascia il software, è possibile creare un tag con un nome univoco in base a ciò che è attualmente nel bagagliaio.

Non posso dire se o non avete bisogno di un repository separato per ogni progetto, ci sono pro e contro. Questo blog di distacco loro dettagli:

  

  
1. Amministrazione semplificata. Una serie di ganci per distribuire. Un repository   per il backup. ecc.
  
2. Branch / tag flessibilità. Con il codice tutto in un unico repository rende   più facile creare un ramo o tag   che coinvolge più progetti.
  
3. codice di muoversi facilmente. Forse si vuole prendere una sezione di codice da   un progetto e utilizzarlo in un altro, o   trasformarlo in una libreria per diversi   progetti. E 'facile da spostare il codice   all'interno dello stesso repository e mantenere   la storia del codice nella   processo.
  

     

Ecco alcuni degli svantaggi al   approccio unico repository, vantaggi   l'approccio repository multipla.

     

  
1. Dimensioni. Potrebbe essere più facile da affrontare molti repository più piccole   uno grande. Ad esempio, se si   andare in pensione un progetto si può semplicemente archiviare   il repository per i media e rimuoverlo   dal disco e liberare l'archiviazione.   Forse avete bisogno di scaricare / caricare un   repository per qualche motivo, tale da   usufruire di un nuovo Subversion   caratteristica. Questo è più facile da fare e con   minore impatto se si tratta di un minore   repository. Anche se alla fine   voglia di farlo a tutti i tuoi   repository, si avrà un impatto minore   fare uno alla volta, assumendo   Non v'è un urgente bisogno di fare   tutti in una volta.
  
2. numero di revisione globale. Anche se questo non dovrebbe essere un problema,   alcune persone percepiscono che sia uno e   non mi piace vedere il numero di revisione   avanzare sul repository e per   progetti inattivi di avere grandi lacune   nella loro storia di revisione.
  
3. Controllo accessi. Mentre il meccanismo authz di Subversion permette   di limitare l'accesso come necessario per   parti del repository, è ancora   più facile da fare questo al repository   livello. Se si dispone di un progetto che solo   a selezionare alcuni individui dovrebbero   accesso, questo è più facile a che fare con un   unico repository per quel progetto.
  
4. flessibilità amministrativa. Se si dispone di più repository, quindi   è più facile da implementare diversi   script di aggancio in base alle esigenze del   repository / progetti. Se vuoi   script di aggancio uniformi, poi una singola   repository potrebbe essere migliore, ma se   ogni progetto vuole proprio commit   stile e-mail, allora è più facile avere   quei progetti in separata   repository
  

Answer 3

Sono d'accordo, leggere il svnbook . E 'una grande risorsa.

  

Devo creare un nuovo repository per ogni progetto? O un nuovo tronco?

Kevin ha coperto i repository multipli trade-off / singoli abbastanza bene. Quando abbiamo iniziato con svn, abbiamo utilizzato un unico repository per tutti i nostri progetti di sviluppo. Ha funzionato bene e aveva tutti i vantaggi menzionati. Tuttavia, come il repository ottenuto più grande ha ottenuto più difficile da gestire a causa delle dimensioni del file dump e le questioni derivanti durante il backup. E 'diventato anche un problema che i progetti non potevano essere facilmente archiviati fuori dal repository - è certamente possibile, ma richiede di dumping e tirando fuori i progetti dal repository. Non sono questioni non si può andare in giro, ma è qualcosa da tenere a mente.

  

  
1. Repository
  
2. Filiali
  
  
4. Trunk
  

Filiali, tag e il tronco sono solo copie dei file contenuti nel repository. Esso consente di separare e segno di spunta i tuoi file in qualsiasi momento ti senti adeguato (di solito a un rilascio o un ramo di caratteristica).

Una cosa importante da tenere a mente su rami, i tag e il tronco è che semplicemente le convenzioni in SVN. Non v'è alcuna differenza funzionale tra le tre località, sono solo un modello di utilizzo accettato e possono essere modificate o organizzati in modo diverso se si ha una buona ragione. Non sto raccomandando che a organizzare in modo diverso, ma troverete che svn è molto flessibile, perché non c'è davvero una struttura organizzativa forzata diversa convenzione.

A seconda di quanti progetti si decide di avere nel vostro repository, si può organizzare in modo diverso.

Si possono avere le sottodirectory con progetti sotto di essa:

\repo
  \branches
    \...
  \tags
    \...
  \trunk
    \..

o si può avere progetti contengono le sottodirectory:

\repo
  \Project1
    \branches
    \tags
    \trunk
  \Project2
    \branches
    \tags
    \trunk

Non ci sono compromessi che sono coperti nel svnbook. Il primo metodo è di solito utilizzato se si dispone di un solo progetto per ogni repository e la seconda se v'è più di un progetto nel repository.

La cosa bella è che si può solo iniziare a utilizzare svn e poi capire ciò che si preferisce. Si dovrebbe avere una sorta di organizzazione, ma, con copie a buon mercato, si può sempre ri-organizzare le cartelle come la vostra situazione o modifiche del flusso di lavoro.

Answer 4

Una cosa importante da ricordare con SVN, rispetto ad altri sistemi di controllo versione come CVS o Git, SVN è che in realtà non hanno un concetto o di ramificazione o tagging. Per quanto riguarda la SVN è interessato è tutto solo un mucchio di cartelle e file. Così, mentre vedrete un sacco di persone che utilizzano il / tag / setup rami tronco, questo non è richiesto e si è in grado di deviare da questo se lo desiderano.

In linea generale 'tronco' è dove si mantiene il vostro sviluppo attivo in corso. Quindi questo è dove si fa tutti i commit. O se non si checkout tronco o utilizzare i tag / rami invece è interamente a voi.

Filiali, come io li ho usato, sono di solito per quando si ha bisogno di fare grandi cambiamenti alla vostra applicazione, ma non li vogliono in tronco perché si vuole essere in grado di continuare a sviluppare contro il tronco senza distribuzione delle altre modifiche. In questo caso si può avere qualcosa di simile

\repo
  \trunk
  \branches
    \version_two

In questo caso è possibile sviluppare sia in tronco e version_two separatamente e, supponendo che il sito dal vivo è un checkout del tronco, non è necessario preoccuparsi di 'accidentalmente' rompere il vostro sito in diretta con le altre modifiche. E quando tali modifiche vengono fatte e pronte basta unire di nuovo nel tronco ogni volta che vuoi.

I tag possono essere utilizzati in modo simile alle filiali, in che invece di check-out tronco e usando solo 'svn up' per aggiornare il repository voi invece di più variabili, ognuno dei quali rappresenta un rilascio. Così il vostro repo può sembrare qualcosa di simile

/repo
  /trunk
  /branch
    /version_one
    /version_two
  /tags
    /1.0.0
    /1.0.1
    /1.1.0

In questo caso l'idea generale è che quando si è pronti a fare un deploy si fa un

svn copy

Per copiare tronco verso un tag (in questo caso il prossimo potrebbe essere 1.1.1, 1.2.0, 2.0.0, ecc). Come è il nome tag è interamente a voi e anche se, ancora una volta, dipende dal vostro progetto e le esigenze. Con questo percorso invece di fare un regolare 'svn up' si dovrebbe fare uno switch svn. Quindi, è necessario distribuire con

svn switch https://svn.yourrepo.com/repo/tags/1.1.0

L'interruttore farà automaticamente gli aggiornamenti, aggiunge ed elimina sui file appropriati.

Quando si tratta di un pronti contro termine per molti progetti o pronti contro termine separate per ciascuno di essi sono un sostenitore di un repo per progetto. Esso fornisce i benefici aggiuntivi di gestione facilmente accesso ad esso. Ma soprattutto significa che ogni progetto ha un separato impegnarsi storia e registri separati. Questo m

Answer 5

Leggendo i tag che vedo iniziare a utilizzare VisualSVN al posto del vecchio sistema VSS. (La tua domanda dice che smesso di usare Visual Studio .. che rende VisualSVN una strana scelta).

Una delle principali differenze tra SourceSafe e VSS è che si può scegliere diversi strumenti per accedere allo stesso repository (e si può passare ogni volta che ti piace come tutti condividono la stessa workingcopy).

per esempio:.

• TortoiseSVN per l'integrazione Explorer.
• I normali client subversion per gli script.
• VisualSVN come Visual Studio frontend per TortoiseSVN
• AnkhSVN come reale SCC (VAPI) pacchetto in Visual Studio.