Organizzazione di progetti in SVN

Hai tre domande lì:

1. Ha più senso raggruppare per progetto, cioè svn\project1\whatever , poiché "progetto" è la categoria più significativa. Perché dovresti raggruppare progetti completamente indipendenti solo perché sono implementati in C #?
2. Non sono sicuro di aver capito la tua seconda domanda. Con SVN, i file nella tua copia di lavoro possono avere diversi stati possibili: archiviati, sporchi (ovvero hai modifiche locali non salvate), ignorati (cioè file locali non gestiti dal repository), ecc. Utilizza un'interfaccia utente come TortoiseSVN (se stai usando Windows) e ti mostrerà lo" stato "di ogni file. Oppure puoi usare anche la riga di comando, ma è meno user-friendly.
3. "Inoltre, come si sentono tutti a proposito di mettere i file SVN estratti su dischi condivisi?" Questa domanda mi fa pensare che non si capisca completamente lo scopo dell'utilizzo di uno strumento di gestione delle versioni di origine come SVN. Lo scopo del check-out dei file è che tu abbia una copia locale con cui lavorare. Se condividi questa copia, specialmente se fornisci l'accesso in scrittura ad essa, stai già battendo parte dello scopo dell'utilizzo di SVN per iniziare!

Si noti che SVN non può gestire con garbo i conflitti nei report XLS e DOC, perché sono file binari (si otterrà un conflitto se due persone tentano di modificare e impegnare lo stesso file). Unisci / diff in SVN è pensato per i file di testo, come il codice sorgente, non per i binari. Un modo per risolvere questo problema è bloccare i binari per la modifica. Questo può essere fatto usando il comando svn lock (o il corrispondente opzione da un'interfaccia utente come TortoiseSVN).

Potresti voler leggere una spiegazione di quando è necessario il blocco . È relativamente facile da capire.

Qual è il vantaggio di separare i file di origine in base alla lingua? Perché mettere tutte le risorse (codice, immagini, file di configurazione, ecc.) Nella stessa directory del progetto? Rimanerei con il layout SVN convenzionale e ho sottodirectory per trunk, rami e tag:

Projects\
    Project1\
        trunk\
        branches\
        tags\
    Project2\
        trunk\
        branches\
        tags\
    ...

All'interno di una directory di progetto come trunk, avrai tutti i file necessari per costruire il progetto. Se ha senso dividerli in sottodirectory, fallo, ma assicurati che ci sia qualche vantaggio per l'organizzazione. Ad esempio, potresti avere una directory per la grafica in modo da consentire al tuo team grafico di accedere a quei file ma non al codice sorgente, e i tuoi programmatori possono accedere al codice sorgente ma non possono cambiare la grafica. Oppure, potrebbe semplicemente semplificare la copia di tutti i file di immagine nel punto giusto del prodotto durante il processo di creazione. Se ha senso separare i file in base alla lingua, non c'è nulla di sbagliato nel farlo. Basta sapere perché lo stai facendo.

Dai un'occhiata a Controllo versione con Subversion per una grande quantità di informazioni utili. Ad esempio, c'è un capitolo sull'amministrazione di un repository che inizia considerando repository organization .

Sai, in SVN le cartelle più popolari per "cose" sono trunk, rami, tag .

Ora, come scegliere che tipo di "cose" utilizzare per lo schema sopra?

Il mio modo preferito per organizzare la struttura SVN può essere chiamato "versioning driven". Non che sia particolarmente "mio" modo, solo uno suggerito da colleghi più esperti. Comunque è uno che ha dimostrato di funzionare meglio per me.

Basato su versioning significa che le cose sono definite dalla convenienza di avere una sequenza di versioni dedicate per cose di questo tipo, come la versione 1.0, 2.0, 3.1 ecc. qualsiasi cosa tu voglia essere "all'interno" di quella sequenza di versioni, rende SVN singolo "cosa". Tutto ciò che troveresti conveniente da rilasciare con diversi "stream di versione" si rivolge a diverse "cose" SVN.

- This product release is composed from component1 version 1.23, component2 version 4.56 and component3 version 7.98. where can I get code for component1 used in this release?
- Code for component1 v1.23 is in SVN folder component1/tags/1.23

- There was patch 666 we did for component2 version 4.3.1 two years ago. Where I can get its code? I am particularly interested in releases 1.0 and 2.0
- That's easy. You can find patch code in SVN folder component2/branches/4.3.1.666 and releases in component2/tags/4.3.1.666.1.0, component2/tags/4.3.1.666.2.0

Come vedi, sopra non ha praticamente nulla da fare né con il progetto né con il tipo di file sorgente.

• Se ho bisogno di dire particolari "mix" C #, SQL, Matlab da rilasciare / versione nel suo insieme (componente 1 ver 1.0, 2.0, ...), questi andrebbero all'interno di una "cosa" - avendo lo stesso tronco, tag, rami.

• Se ho bisogno di un po 'di file C # da rilasciare / versionare separatamente da un altro gruppo di file C # (componente2 versione 4.56 e componente3 versione 7.98), questi andrebbero a separare "cose", ognuna con sottolivelli dedicati cartelle trunk, tag, rami.

Per quanto riguarda i progetti, le cartelle SVN per queste sono, di nuovo, guidate dalla versione. Se riesco a pensare alle versioni 1.0, 2.0, ecc del progetto, per me significa la necessità della propria "cosa" SVN - propria cartella "nome-progetto" con trunk, tag, sottocartelle di rami all'interno.