2008-09-25 3 views
7

Questo post è simile a this previously asked question. Voglio davvero configurare il mio repository SVN in formato TTB, ma quando si crea un progetto in Visual Studio 2008 (ASP.NET/VB.NET) , la struttura creata tende ad essere incompatibile quando si considera il file di soluzione, i file di progetto, le cartelle per progetti, più progetti all'interno di soluzioni, ecc. Qualcuno ha uno script o una procedura per prendere un progetto ASP.NET appena creato e spostarlo su un TTB formattare il più indolore possibile?Struttura di progetti in controllo versione - specifica .NET


Vorrei essere più specifico. Supponiamo che abbia un progetto che sto creando chiamato StackOverflowIsAwesome. Posso metterlo nella mia struttura di cartelle locali (diciamo che è c: \ working). Quando lo creo, VS crea c: \ working \ StackOverflowIsAwesome e un intero gruppo di sottocartelle (bin, app_data, ecc.). Ma io voglio la mia struttura repository a guardare come ...

 
StackOverflowIsAwesome 
    /trunk 
     /bin 
     /app_data 
    /tags 
    /branches 

Quindi, c'è un modo pulito di fare questo in modo coerente o devo ricorrere a continuo movimento/modificare i file e le cartelle per fare questo lavoro?

risposta

0

Se il vostro TTB è comune piuttosto che per progetto, non ci sono problemi con esso. O mi sta sfuggendo qualcosa?

1

Siamo andati con un approccio molto semplicistico:

Struttura del file:

  • cartella della soluzione (contiene file di soluzione, costruire gli script, forse di più?)
    • cartella di progetto
    • Cartella progetto 2
    • Riferimenti (contiene un elemento condiviso ssemblies per la soluzione).

Poi basta controllare il contenuto dell'intera cartella della soluzione nella nostra repository. Usiamo un repository per ogni soluzione. Non sono sicuro se questo sia il modo ottimale per organizzare la soluzione, ma funziona per noi.

Inoltre, ci dirammo al livello più alto, non per progetto.

+0

Facciamo esattamente la stessa cosa con gruppi di progetto di dimensioni della soluzione. Abbiamo anche alcuni oggetti di progetto singolo più piccoli (come le librerie comuni). è un TTB per progetto per questi (il file della soluzione può essere incluso nella directory del progetto per i singoli se lo si desidera). – VanSkalen

0

È possibile guardare questo previous post o questo project. Il progetto crea una struttura ad albero di sviluppo .NET (richiede .NET 3.5).

0

Quando si gestiscono più progetti che costituiscono una soluzione di Visual Studio, è difficile decidere come strutturare correttamente le cose.

Un aspetto critico che è necessario fare con la struttura è che è facile recuperare tutti i file per una particolare versione. È importante renderlo il più semplice possibile. In caso di sovversione, copiare una cartella radice sui rami del tag è più semplice, ricordando di ripetere la stessa operazione per i progetti X.

Anche la possibilità di lavorare per lunghi periodi al di fuori del bagagliaio principale è importante. Dovrai considerare anche quello.

Potreste scoprire che il vostro software ha un numero di componenti che si raggruppano in modo naturale.Si potrebbe fare qualcosa del genere

/tag 

/core_library 
    /branch 
    /main 

/business_logic 
    /branch 
    /main 

/report_library 
    /branch 
    /main 

/my_ui 
    /branch 
    /main 

Non c'è una risposta facile. Ciò che fai in realtà dipende dal tuo progetto specifico. Se tutto sta ancora uscendo da un pasticcio di rabbia allora forse è necessario esaminare come è progettato il tuo progetto e vedere se è possibile modificarlo per migliorare la comprensione.

-1

lo faccio in questo modo:

  1. creare il progetto in VS
  2. Importa tutto nella cartella del progetto di pronti contro termine/ProjectName/trunk
  3. Aggiungere i repository/rami e pronti contro termine/tags cartelle

Questo mi dà una struttura repository come:

projectname 
    /trunk 
     /bin 
     /obj 
     /Properties 
     projectname.sln 
    /tags 
    /branches 

E posso solo lasciare tutti i file nei loro posti predefiniti nel file system.

1

Un altro modo:

StackOverflowIsAwesome 
    /trunk 
    /database 
    /datafiles 
    /documents 
    /build 
    /installer 
    /lib 
     /External_DAL (external that points to shared library) 
    /utilities 
    /vendor 
    /src 
     /StackOverFlowIsAwesome 
     /StackOverFlowIsAwesome.csprj 
     /bin 
     /... 
     /StackOverFlowIsAwesomeTests 
     /StackOverFlowIsAwesomeTests.csprj 
     /bin 
     /... 
    /branches 
    /tags 

Questo sarebbe per ogni progetto. Dato che stiamo usando uno script di build, non abbiamo bisogno di memorizzare il nostro file di soluzione in SVN.

0

Per i progetti più grandi di solito utilizzare questo formato qui:

/Project 
    /trunk 
     /lib/    # Binary imports here (not in svn) 

     /src    # Solution file here 
      /Libraries  # Library assemblies here 
      /StackOverflowIsAwesome.Common 

      /Products  # Delivered products here 
      /StackOverflowIsAwesome.Site 

      /Projects  # internal assemblies here 
      /StackOverflowIsAwesome.Tests 
    /branches 
     /1.x 
    /tags 
     /StackOverflowIsAwesome-1.0 

A seconda del progetto vero e proprio file non sorgenti (documenti, etc.) hanno una directory sotto la radice tronco e risorse di sviluppo in più sono sotto src .

I progetti indipendenti sottostanti sono sotto la propria radice/progetto, ma nello stesso repository.