Serve aiuto con la struttura delle directory nel porting codebase su SVN

Question

Serve aiuto con la struttura delle directory nel porting codebase su SVN

#1 da (6 voti)
#2 da (1 voti)

4

Attualmente abbiamo una struttura di directory simile a questa

+Inhouse App A
+Inhouse App B
+Core files for inhouse app B
+Inhouse App C
+Something that never came to fruition
+Forgotten Server Project A
+Forgotten Common Files A
+Authentication Server
+Update Server
+Main product Version 5.5
--+[DLL1]
--+[DLL2]
  ...
--+[DLLN-1]
--+[Controls]
-----+[Our Awesome Controls]
-----+[3rd party control 1]
-----+[3rd party control 2]
-----+[3rd party control 3]
--+[DLLN]
--+[Utils]
-----+[Util 1]
-----+[Util 2]
   ...
-----+[Util N-1]
-----+[Util N]
+Main product Version 6.1
+Main product Version 6.2
+Fingerprint SDK

Ovviamente, sto coprendo alcune brutture di questa bellezza. Ho una installazione di VisualSVN per sostituire Visual 'non deve essere chiamato' e arrivo al punto in cui si dice, trunk, branch e qualcos'altro. e da alcuni altri post qui e su SO, so vagamente a cosa servono.

La mia domanda è cosa devo fare per tradurre la struttura del file esistente nella struttura di controllo del codice sorgente. Abbiamo rinunciato alla speranza di fare qualsiasi importazione significativa.

Ho già provato questo, ma sento che mi manca un concetto chiave.

Per esempio, tutte queste cose dovrebbero essere nello stesso repository? Se non si trovano nello stesso repository, come troveranno i file condivisi tra i progetti?

version-control directory-structure

posta Peter Turner 27.09.2011 - 22:12

fonte

2 risposte

1

Non esiste una ragione intrinseca per cui non si possa restare fedeli alla struttura attuale della directory. Scarica tutto nel bagagliaio, e sei a posto. Non otterrai necessariamente tutti i vantaggi che potrebbero essere possibili se tu avessi rami separati per v5.5, 6.0 e 6.1, ma in base a ciò che stai descrivendo, dubito che sia persino possibile ottenere tali benefici in questo punto. Ottenere questi benefici richiede modifiche del flusso di lavoro non banali, e potrebbe essere più facile ottenere prima la trazione con VCS come concetto generale che include il tracciamento e introdurre succursali per versione più avanti se ha senso con il flusso di lavoro.

risposta data 28.09.2011 - 07:11

fonte

Leggi altre domande sui tag version-control directory-structure

Ordine dei parametri: dimensione, conteggio o viceversa Qualche buona ragione per aprire i file in modalità testo?

score 6 · Accepted Answer

Prima di tutto, la struttura di un repository Subversion è solo un albero di directory. L'uso delle directory 'trunk', 'branches' e 'tags' è solo una convenzione di comunità. Come ogni convenzione è meglio per te attenersi ad essa, ma non obbligatoria. Detto questo, utilizzo un repository UNICO per un'applicazione e all'interno di questo repository, la classica struttura 'trunk', 'branches' e 'tags'. Ma se l'applicazione è abbastanza grande o ha un gruppo di moduli hai due alternative:

A: (per versioni condivise tra i moduli)

trunk (modulo-A, modulo-B, modulo ...)

B: (le versioni andranno in modo indipendente per ciascun modulo)

modulo-A (tronco, rami, tag); modulo-B (tronco, rami, tag)

La seconda alternativa potrebbe essere implementata utilizzando un singolo repository o multipli, nel SVN Book (link sotto) si ha una descrizione di ciascuno e dei relativi vantaggi.

Se non hai familiarità con l'uso del "tronco" delle directory, "rami" e "tag", qui hai una breve descrizione, ma fai riferimento a SvN Book e cerca "Strategie per la distribuzione del repository" e "Layout del repository consigliato" .

trunk: "linea principale" di sviluppo
rami: copie divergenti delle linee di sviluppo
tag: nomi, istantanee stabili di una particolare linea di sviluppo

Come li uso? - La prima struttura del progetto è stata caricata nel trunk. - Ogni volta che arriva un nuovo requisito o progetto, copia il contenuto del tronco in un nuovo ramo (con un nome rappresentante). - Lavoriamo su quella filiale fino al completamento degli UAT (User Acceptance Testing). - Successivamente, reintegriamo il ramo con il tronco (unione). Nota: se più di un ramo verrà rilasciato per la produzione devi fare tutte le unioni prima e testare idealmente l'integrazione di tutte le modifiche, utilizzando il codice di accesso. - Infine creiamo un tag, per contrassegnare il rilascio di questa versione nell'ambiente di produzione. Nota: tutti i tag sono di sola lettura, nessuno del team può modificare un tag dopo la sua creazione. Questa semplice regola ti consente di accedere a una versione stabile nota del codice se si verificano alcuni problemi.

In breve (e qui ci sono i concetti chiave):

Leggi il libro SVN.
Comprendi le basi della sovversione
Acquisisci familiarità con tutte le diverse alternative progetti structres e scegli quello più adatto alle tue esigenze.
Familiarizza con tutti i diversi modelli di ramificazione , utilizza quello corrispondente in base al lavoro da svolgere (una correzione di bug, una richiesta di modifica, un progetto lungo, ecc. .).
Comprendi cosa sono tronco, rami e tag, specialmente l'ultimo.
Comprendi cos'è una copia di lavoro, un repository, una revisione, il concetto di copia economica
Ricorda di non fare la versione dei tuoi binari, solo le tue fonti. Ho fatto questo chiarimento a causa del tuo attuale layout, hai cose chiamate "DLLxxx", quindi presumo siano binari (file .dll).

Dopo l'implementazione, se hai problemi a far lavorare i tuoi partner con lo strumento, ecco un possibile motivo di questo comportamento: Perché gli sviluppatori non utilizzano un sistema di controllo versione (CVS, SVN, Git, Hg, ...)? , si prega di lasciare i tuoi commenti o esperienze su come ottenere un team sull'uso di uno strumento di gestione delle versioni.