1

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.

BlueChippy
  • 5,935
  • 16
  • 81
  • 131
  • 1
    svn:externals always smell bad. always. especially after http://nuget.codeplex.com/workitem/215 – thekbb Jan 18 '13 at 03:25
  • Could you explain WHY they smell bad? They seem very useful to me - but then I have no experience of them! – BlueChippy Jan 20 '13 at 04:29

1 Answers1

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.

maxim1000
  • 6,297
  • 1
  • 23
  • 19
  • (For 250 points I need LOTS of help!!! lol) Where do you put documentation, scripts, SQL, MSProj plans etc.? How do you organise things on your HDD? Single "Development" folder, one folder per "product"? I need to not only start using this, but also document it for people who haven't even heard of source control!! – BlueChippy Feb 14 '13 at 04:21
  • See my additions. But frankly I believe this would have better chances for many responses in form of several questions. May be you wouldn't even need to give a bounty then. – maxim1000 Feb 14 '13 at 06:10
  • Thanks again: I tried separate questions - but got separate and differing answers! lol I may be over-thinking all of this...practice always makes thing clearer...but advice from people like yourself is very gratefully accepted! – BlueChippy Feb 14 '13 at 07:17
  • Sorry! One more: How do I get a branch of "shared code" into my "ProductA"...is that SVN:Externals? – BlueChippy Feb 14 '13 at 07:22
  • nope, simply `svn copy rep_url/shared_code rep_url/ProductA/shared_code` – maxim1000 Feb 14 '13 at 08:48
  • (I know this is turning into a discussion!) Can that be merged back into the Shared/Trunk folder? – BlueChippy Feb 14 '13 at 09:00
  • Sure, it can be done through command-line or TortoiseSVN (it shows differently already merged and not yet merged revisions). – maxim1000 Feb 14 '13 at 09:54