Question

I have read FAR too many posts on SO and I am now in analysis paralysis!

I work with Visual Studio 2010 and I have many small projects, many of which reference library/shared projects.

I don’t really mind about having to check/re-build dependent projects if I make changes to shared code…I’ll be putting TeamCity in place ASAP to assist with this, but for the moment, I just amend the code next time I work on a project. Many projects are “write once and forget”, so they’ll never need updating.

The team is very small at the moment (ME!) but new devs are expected early this year, but it will still be a very small in-house team, with fast project cycles if that makes any difference.

At the moment I have a very flat folder structure on disk, so ALL of my sln files are in a “development” folder on disk. Then there is a folder per VS project. This makes sharing pretty simple, and also leaves me with a single packages folder for nuget.

I am about to import everything into SVN (VisualSVN) and I’d like to start adding things like database scripts, docs, UAT tests, etc. etc.

• Do I keep my flat structure and have a single trunk/branch/tag at
  root level?
• Do I expand the structure to an SVN folder-per-solution
  and then have trunk/src, trunk/docs and manage things like nuget
packages with svn:eternals?
• Do I hybrid this and have an SVN folder-per-solution but with docs in the VS solution?

NOTE: I am putting in SVN so I can bring in some Java development but keep source code managed in a single way. We will also share with a DB team, who want to put docs/sql sripts etc in there. I intend a separate repository each for DB and Java – but would like a “similar” folder structure for each of them.

NOTE2: I have some SVN user experience, but no Admin experience. The new devs have no experience at all (they are coming from an AS/400 background) so the simpler the solution the better! I’ve looked at repo per project and svn:extenals and whilst it is a great solution, it will require me to manage and maintain all the time (as well as do my own work! lol)

ANY advice from people who have “Been there, done that-GTTS” is very gratefully received.

---

OK, I now have the following local solution structure:

ALL my sln/suo files are in the same folder.
ALL of my project folders/files are subfolders

This makes sharing projects easy enough…but looks very messy and is hard to find anything 🙁

Should I be using svn:externals to manage “reference” projects, so I can branch/tag them?
Should I only reference built DLL’s – and all the management that comes with doing that?
Should I let VS2010 manage my folders, and not care that I have lots of “nuget” folders etc.?

VERY VERY confused now…any decent answers? 🙁

---

NOTE: Will be adding TeamCity (or something similar) to the mix ASAP to provide CI capabilities. Any serious (and FREE) recommendations for CI also appreciated.

Answer 1

Here is a structure I use at work and for personal projects:

SVN structure:

• root
  • shared_code
  • productA
    • trunk
      • branch_of_shared_code
      • productA projects
      • productA solution
    • branches
      • branch1
        • branch_of_shared_code
        • productA projects
        • productA solution
    • tags
      • …
  • productB
    • …

Periodically (when exactly depends on your needs) all changes from the main branch of shared code are merged into product’s branches of the shared code. Changes to the shared code are either made in product’s branch and then merged back, or in the main branch and then merge to products.

Product sources content:

Everything needed to build the complete package is considered as source. E.g. if you have DB scripts – they are part of sources. Tests – too. For documentation I usually add a separate project into the solution which contains all sources for building documentation and produces result in the output directory. Then a project creating installer will include it into the generated distributive.

Planning:

This may be debatable, but I prefer to store tasks list next to sources and branch/merge them together. If a task is completed in a branch, it’s not completed in trunk until merge. More general planning may or may not be appropriate for storing next to the sources.

On disk:

First of all I believe in working with repository in such a way that it’s OK to not store working copies for every product, but check them out on demand. Of course, checking out/deleting working copy for every change is impractical, so I have a directory for every product which I’m working frequently at this time, inside of it I check out branches I work on (trunk and some others). The rest of products need not to be checked out if you don’t expect their development soon.