Ignorando tutti i pregiudizi verso l'uno o l'altro VCS, il layout delle directory dev dovrebbe essere conforme a ciò che funziona meglio per te mentre lavori. Quindi esegui il controllo della versione su quello.
Uno schema (pigro) è solo per ospitare il VCS al livello più alto (/ dev) e lasciare che tutto faccia parte di un grande repository. Non mi piace, ed è probabilmente una cattiva idea comunque. Lega troppe cose insieme (e yay, questo è il modo in cui il mio ufficio usa TFS).
Un'idea migliore è quella di dividere lungo le linee di progetto o le linee concettuali. Una divisione concettuale nel tuo caso sarebbe quella di mettere tutti i progetti di bash in un repository. Un'altra idea simile è quella di mettere tutti i progetti relativi a un obiettivo più grande in un repository insieme. Una divisione del progetto sarebbe quella di mettere ogni singolo progetto come un proprio repository. Mi piace che il progetto divida meglio me stesso, poiché penso che questo ti dia la maggior granularità nel mantenere il repository, e mantiene pulita la cronologia mostrando solo un progetto. Ovviamente alcuni VCS favoriranno divisioni diverse e offriranno supporto diverso per loro.
In SVN in particolare, è molto comune avere qualcosa del tipo:
/ProjectX (RepoRoot)
|
|--/trunk
| |--/ProjectX
|--/branch
| |--/ProjectX_401changes
| |--/ProjectX_refactoring
| |--/ProjectX_failedExperiment
|--/tag
| |--/ProjectX_Release20120101
| |--/ProjectX_Release20120411
Anche in questo caso, la maggior parte dei programmi VCS avrà le proprie idee su come effettivamente appare, ma quasi tutti offrono qualcosa come questa divisione concettuale. La chiave è che non solo il codice viene sottoposto a versioni tramite modifiche, ma anche stati di rilascio. Il codice può essere la linea principale di sviluppo (Trunk), una derivazione per aggiungere nuove funzionalità complesse o per sperimentare (una Branch), o uno stato buono noto che dovresti essere in grado di tornare facilmente a (un Tag).
In genere si ospiterà il repository "centrale" su un'altra macchina, ma si può anche semplicemente usare un'altra cartella sul proprio computer (ma preferibilmente su un altro hard disk almeno). Se disponi di più repository, probabilmente rispecchierai approssimativamente il tuo pattern di lavoro, ma con la struttura SVN sopra in ciascuna cartella Repo. Si noti che in realtà, il repository remoto viene spesso chiamato "bare" o qualcosa di simile perché in realtà non ha una copia dei file reali esposti, ma nasconde tutto all'interno della cartella .svn (o .git, .bzr, ecc. ).
Infine, usare qualsiasi VCS significa apprendere gli strumenti. È possibile utilizzare uno strumento grafico, se disponibile, e tendono a rendere l'uso di VCS molto più piacevole. Tuttavia, gli strumenti da riga di comando sono in genere abbastanza semplici e ti aiuteranno a capire che cosa sta effettivamente facendo VCS.
In genere hai bisogno di 3 comandi di base per il lavoro quotidiano: download (ottieni modifiche da repository), upload (inserisci modifiche nel repository) e stato (quali modifiche ho). In SVN, questi sono:
svn update (download)
svn commit (upload)
svn status (status)
Gli altri comandi sono meno usati, quindi non dovrai avere familiarità con loro. In genere, quelli aggiuntivi necessari per iniziare sono: aggiungi, crea repo e crea copie locali. In SVN:
svn checkout (create local repo)
svn add (add files to the repo)
svn create (create a repository, ie on the server)
Altri VCS avranno alcuni comandi extra che devi sapere. Git, Mercurial, Bazaar e altri sistemi distribuiti di solito hanno una distinzione tra commit locale e commit remoto. Nella maggior parte di essi (git e bazaar come ricordo, almeno) il comando di commit locale è commit e il comando per inviare le modifiche al sistema remoto è push abbastanza intuitivo. Pull viene utilizzato per ottenere le modifiche anziché update .
