I do it almost the same, but LLBLGen would go into an "External" folder togheter with other externals... Yes, I know it exists an external-reference thingy in svn, but I stil have the source/binaries in the same repository..

I also have an "Code" folder, and into that I have the WebRoot project and the other class libraries for the project, to separate it of the others. but Code, Database (which for me contains the scripts to rebuild the database, not an snapshot ugh..), Prebuilt (same as your libs), Docs and ThirdParty is in the trunk folder.

How about dependancies and subversion..? Say I have a usercontrol that's shared across several sites and I want to reuse the shared codebase in several projects as opposed to using the binary. I'd like to have a situation where I can just check out a project along with _all_ dependancies as projects within the same solution. I think VS can handle that in terms of portable project files but I've yet to find a source control system that can. I believe svn allows symlinking within the repo so that might do it....

re the branch/tag thing I've used svn for that and it works just great - svn handles most of the code merge really well when you bring branches together.

Tom, i'm unsure of the best way of doing what you would like using subversion.  One thing to keep in mind with using a shared codebase in the way that you are talking about - consider what happens when you have Project A that uses CodebaseA.  Project A is completed and locked down with Version 1. It's now dependant on CodebaseA Version 1.  

Project B also uses CodeBaseA.  You work on that, and this requires doing some breaking changes to CodeBaseA, which steps up to Version 2.  Suddenly Project A is broken, because it is automatically linked to a newer CodebaseA.  

The way to avoid this of course is with labelling - ensuring that ProjectA and CodebaseA receive the same ProjectAVersion1 label, so that you can go back to that point in time.  Just thought I'd mention that, although you probably already know.

Anyhow, this might be useful to you for reusing usercontrols:

http://weblogs.asp.net/scottgu/archive/2005/08/28/423888.aspx

This was another fantastic article on this subject:

http://webproject.scottgu.com/CSharp/UserControls/UserControls.aspx  

However, it looks like it is no longer available.  You can read it in google cache, or you can try bugging him to put it back online.

--

Stephen - one way that I store references to dlls is by adding them to a class library project called ExternalReferences in my solution, with a build action of Embedded Resource. I then simply reference that project in my other projects and have access to the dlls that way.

Thought I'd add one more link on the shared usercontrol thing:

http://blogs.msdn.com/webdevtools/archive/2006/07/01/652986.aspx

You can tell I've spent a lot of time fiddling with this issue.  :)

Hi Stephen,

I've posted about this same issue and have been using a method that works well for our large web projects. Take a look

http://brigl.blogspot.com/2006/11/net-development-trees-part-i.html

http://brigl.blogspot.com/2006/11/net-development-trees-part-ii.html

Hi Stephen,

I'm not sure why you would need to put working changes into branches.  Perhaps I am misunderstanding your terminology.

I would only use branches in situations where I needed parallel development on the same code base.  For example, after releasing v1.0 we decide to release a patch v1.01 while simultaneously developing v2.0.  I would create a branch for v1.01, and the trunk would be active work for v2.0.  Eventually, we hope to merge the branched code back in.

Does this approach make sense?

Hi ppl, thanks for the feedback! - I've been doing a little digging myself and I think I've found a half decent solution:

The Subversion client Tortiose allows you to auto import a sub-project into an existing source controlled project - this solves the dependancy problem. Essentially you set the svnexternals property on a folder and it'll import the specified module into your sourcecontrolled copy when you do an update. However.... it'll also propogate any changes you make to the dependancy back into the repository - so there's some kind of ACL required. This half solves Dylans problem above. The other half of that problem can be solved using something like CruiseControl to handle dependancy integration issue...

The aim here is have a project in svn I can check out and with one action have ALL the dependancies checked out _as source code_

Anyhow, I think i have a solution now, thanks everyone - interesting discussion!

This is how I structured SVN in our development department:

- Product Root

- trunk

    - bin (product deliverables)

    - src (product source code)

    - lib  (external referenced libraries/frameworks)

    - autoBuild.build

- branches

- tags

- docs (Product documentation & issue tracker log)

However, I'm confused in regards to NUnit & NHibernate, what should be within the repository and what level?

Cheers,