<p>I know there are at least 10 different ways to structure project in version control. I'm curious what some methods being used are and which ones work for you.  I've worked with SVN, TFS, and currently/unfortunately VSS.  I've seen version control implemented very poorly and just OK, but never great.</p>

<p>Just to get the ball rolling, here is a review of things I've seen.</p>

<p>This example is SVN-based, but applies to most VCS's (not so much to distributed version control).</p>

<ol>
<li><p>branch the individual projects that are part of site
/division/web/projectName/vb/src/[trunk|branches|tags]</p></li>
<li><p>branch the whole site, in the case I've seen, the whole site except for core components was branched.
/division/[trunk|branches|tags]/web/projectName/vb/src/</p></li>
<li><p>Use main-line a default, only branch when necessary for <strong>huge</strong> changes.</p></li>
</ol>

[{'answer_id': 16839, 'author': 'mk.', 'author_id': 1797, 'author_profile': 'https://Stackoverflow.com/users/1797', 'pm_score': 3, 'selected': False, 'text': '<p>Example for SVN: </p>\n\n<p>trunk/</p>\n\n<p>branch/</p>\n\n<p>tags/</p>\n\n<p>The trunk should be kept at a point where you can always push a release from it. There should be no huge gaping bugs that you know about(of course there will be eventually but that is what you should strive for). </p>\n\n<p>Every time you need to make a new feature, do a design change, whatever, branch. Tag that branch at the start. Then when you are finished with the branch tag it at the end. This helps out with merging back into trunk. </p>\n\n<p>Every time you need to push a release, tag. This way if something goes horribly wrong you can rollback to the previous release. </p>\n\n<p>This setup keeps trunk as clean as possible and allows you to make quick bug fixes and push them out while keeping the majority of your development in branches. </p>\n\n<p><strong>Edit:</strong> For 3rd party stuff it depends. If I can avoid it I do not have it under source control. I keep it in a directory outside source control and include it from there. For things like jquery, I do leave it under source control. The reason is it simplifies my script for pushing. I can simply have it do an svn export and rsync. </p>\n'}, {'answer_id': 16876, 'author': 'Mike Deck', 'author_id': 1247, 'author_profile': 'https://Stackoverflow.com/users/1247', 'pm_score': 1, 'selected': False, 'text': "<p>I think the SCM policies and procedures a team adopts are going to be very dependent on the development process they are using.  If you've got a team of 50 with several people working on major changes simultaneously and releases only occurring every 6 months, it makes a lot of sense for everyone to have his own branch where he can work in isolation and only merge in changes from other people when he wants them.  On the other hand, if you're a team of 5 all sitting in the same room it makes sense to branch much less frequently.</p>\n\n<p>Assuming you're working on a small team where communication and collaboration is good and releases are frequent, it makes very little sense to ever branch IMO.  On one project we simply rolled the SVN revision number into the product version number for all our releases and we never even tagged.  In the rare event that there was a critical bug found in prod we would simply branch straight from the revision that was released.  But most of the time we simply fixed the bug in the branch and released from trunk at the end of the week as scheduled.  If your releases are frequent enough you'll almost never run into a bug that can't wait until the next official release.</p>\n\n<p>I've worked on other projects where we never could have gotten away with that, but due to the lightweight development process and low ceremony we were able to use a lightweight version control policy very effectively.</p>\n\n<p>I'll also mention that everything I've written is coming from an enterprise IT context where there's only a single production instance of a given code base.  If I was working on a product that was deployed at 100 different customer sites the branching and tagging practices would have to be a little more strenuous in order to manage all of the independent update cycles across all the instances.</p>\n"}, {'answer_id': 16883, 'author': 'Mike Deck', 'author_id': 1247, 'author_profile': 'https://Stackoverflow.com/users/1247', 'pm_score': 1, 'selected': False, 'text': "<blockquote>\n  <p>What about external dependencies such a the AJAXTookit or some other 3rd party extension that's used on several projects?</p>\n</blockquote>\n\n<p>Source control is for source code, not binaries.  Keep any 3rd party assemblies/jars in a separate repository.  If you're working in the Java world try something like Maven or Ivy.  For .Net projects a simple shared drive can work well as long as you have decent policies around how it's structured and updated.</p>\n"}, {'answer_id': 16911, 'author': 'Dale Ragan', 'author_id': 1117, 'author_profile': 'https://Stackoverflow.com/users/1117', 'pm_score': 3, 'selected': False, 'text': '<p>For my projects, I always use this structure.</p>\n\n<blockquote>\n  <ul>\n  <li>trunk\n  \n  <ul>\n  <li>config</li>\n  <li>docs</li>\n  <li>sql\n  \n  <ul>\n  <li>initial</li>\n  <li>updates</li>\n  </ul></li>\n  <li>src\n  \n  <ul>\n  <li>app</li>\n  <li>test</li>\n  </ul></li>\n  <li>thirdparty\n  \n  <ul>\n  <li>lib</li>\n  <li>tools</li>\n  </ul></li>\n  </ul></li>\n  <li>tags</li>\n  <li>branches</li>\n  </ul>\n</blockquote>\n\n<ul>\n<li>config - Used to store my application config templates.  During the build process, I take these templates and replace token placeholders with actual values depending on what configuration I am making the build.</li>\n<li>docs - Any application documentation gets placed in here.</li>\n<li>sql - I break my sql scripts into two directories.  One for the initial database setup for when you are starting fresh and another place for my update scripts which get ran based on the version number of the database.</li>\n<li>src - The application source files.  In here I break source files based on application and tests.</li>\n<li>thirdparty - This is where I put my third party libraries that I reference inside of my application and not available in the GAC.  I split these up based on lib and tools.  The lib directory holds the libraries that need to be included with the actual application.  The tools directory holds the libraries that my application references, but are only used for running unit tests and compiling the application.</li>\n</ul>\n\n<p>My solution file gets placed right under the trunk directory along with my build files.</p>\n'}, {'answer_id': 16915, 'author': 'Boris Terzic', 'author_id': 1996, 'author_profile': 'https://Stackoverflow.com/users/1996', 'pm_score': 3, 'selected': False, 'text': "<p>We practice highly componentised development using Java, we have about 250 modules in trunk that have independent life cycles. Dependencies are managed through Maven (that's a best practice right there), every iteration (bi-weekly) actively developed modules get tagged with a new version. 3 digit version numbers with strict semantics (major.minor.build - major changes means backwards incompatible, minor changes mean backwards compatible and build number changes mean backwards and forwards compatible). Our ultimate software product is an assembly that pulls in dozens of individual modules, again as Maven dependencies.</p>\n\n<p>We branch modules/assemblies when we need to make a bug fix or enhancement for a released version and we can not deliver the HEAD version. Having tagged all versions makes this easy to do but branches still incur a significant administrative overhead (specifically keeping branches in sync with certain HEAD changesets) that are partly caused by our tools, Subversion is sub-optimal for managing branches.</p>\n\n<p>We find that a fairly flat and above all <strong>predictable</strong> tree structure in the repository is crucial. It has allowed us to build release tools that take away a lot of the pain and danger from a manual release process (updated release notes, project compiles, unit tests run through, tag is made, no SNAPSHOT dependencies, etc). Avoid putting too much categorization or other logic in your tree structure. </p>\n\n<p>We roughly do something like the following:</p>\n\n<pre><code>svnrepo/\n  trunk/\n    modules/\n      m1/ --&gt; will result in jar file\n      m2/\n      ...\n    assemblies/\n      a1/\n      ...\n  tags/\n    modules/\n      m1/\n        1.0.0/\n        1.0.1/\n        1.1.0/\n       m2/\n      ...\n    assemblies/\n      a1/\n        iteration-55/\n        ...\n  branches/\n    m1/\n      1.0/\n      ...\n</code></pre>\n\n<p>For external dependencies, I can not overemphasize something like Maven: manage your dependencies as references to versioned, uniquely identified binary artifacts in a repository. </p>\n\n<p>For intenal module/project structure: stick to a standard. Uniformity is key. Again, Maven can help here since it dictates a structure. Many structures are fine, as long as you stick to them.</p>\n"}, {'answer_id': 16948, 'author': 'denis phillips', 'author_id': 748, 'author_profile': 'https://Stackoverflow.com/users/748', 'pm_score': 2, 'selected': False, 'text': '<p>I can appreciate the logic of not putting binaries in the repository but I think there is a huge advantage too. If you want to be able to pull a specific revision out from the past (usually an older tag) I like being able to have everything I need come from the svn checkout. Of course this doesn\'t include Visual Studio or the .NET framework but having the right version of nant, nunit, log4net, etc. makes it really easy to go from checkout to build. This way getting started is as easy as "svn co project" followed by "nant build".</p>\n\n<p>One thing we do is put ThirdParty binaries in a separate tree and use svn:external to bring it the version we need. To make life easy, we\'ll have a folder for each version that has been used. For example, we might bring in the ThirdParty/Castle/v1.0.3 folder to the current project. This way everything need to build/test the product is inside or below the project root. The tradeoff in disk space is well worth it in our experience.</p>\n'}, {'answer_id': 17363, 'author': 'Monroecheeseman', 'author_id': 1351, 'author_profile': 'https://Stackoverflow.com/users/1351', 'pm_score': 0, 'selected': False, 'text': '<p>We migrated from the bad world of VSS with one giant repository (over 4G) before switching to SVN.  I really struggled with how to set up the new repository for our company.  Our company is very "old" school.  It\'s difficult to get change I\'m one of the younger developers and I\'m 45!  I am part of a corporate development team that works on programs for a number of departments in our company.  Anyway I set up our directories like this</p>\n\n<pre><code>+ devroot\n    +--Dept1\n        +--Dept1Proj1\n        +--Dept2Proj2\n    +--Dept2\n        +--Dept2Proj1\n    +--Tools\n        +--Purchase3rdPartyTools\n        +--NLog\n        +--CustomBuiltLibrary\n</code></pre>\n\n<p>I wanted to include the ability to branch, but quite honestly that\'s just too much at this point.  Couple things we still struggle with using this scheme.</p>\n\n<ul>\n<li>It\'s hard to fix production problems if you are working on a major product upgrade (ie because we don\'t do branching)</li>\n<li>It\'s hard to manage the concept of promoting from "Dev" to "Prod".  (Don\'t even ask about promoting to QA)</li>\n</ul>\n'}, {'answer_id': 73144, 'author': 'Mariano', 'author_id': 12514, 'author_profile': 'https://Stackoverflow.com/users/12514', 'pm_score': 2, 'selected': False, 'text': '<p>As we have all the artifacts and construction in the same tree we have something like:</p>\n\n<ul>\n<li><p>Trunk</p>\n\n<ul>\n<li>Planning&amp;Tracking</li>\n<li>Req</li>\n<li>Design</li>\n<li>Construction\n\n<ul>\n<li>Bin</li>\n<li>Database</li>\n<li>Lib</li>\n<li>Source</li>\n</ul></li>\n</ul></li>\n<li><p>Deploy</p></li>\n<li>QA</li>\n<li>MA</li>\n</ul>\n'}, {'answer_id': 8929709, 'author': 'altern', 'author_id': 50962, 'author_profile': 'https://Stackoverflow.com/users/50962', 'pm_score': 2, 'selected': False, 'text': '<p>I prefer fine-grained, very organized, self contained, structured repositories. There is a <a href="http://altern.kiev.ua/images/scm/branches_naming_A3.en.jpg" rel="nofollow noreferrer">diagram</a> illustrating general (ideal) approach of repository maintenance process. For example, my initial structure of repository (every project repository should have) is:</p>\n\n<pre><code>/project\n    /trunk\n    /tags\n        /builds\n            /PA\n            /A\n            /B\n        /releases\n            /AR\n            /BR\n            /RC\n            /ST\n    /branches\n        /experimental\n        /maintenance\n            /versions\n            /platforms\n        /releases\n</code></pre>\n\n<p><code>PA</code> means <strong>pre-alpha</strong>\n<code>A</code>  means <strong>alpha</strong>\n<code>B</code>  means <strong>beta</strong>\n<code>AR</code> means <strong>alpha-release</strong>\n<code>BR</code> means <strong>beta-release</strong>\n<code>RC</code> means <strong>release candidate</strong>\n<code>ST</code> means <strong>stable</strong></p>\n\n<p>There are differences between <em>builds</em> and <em>releases</em>. </p>\n\n<ul>\n<li>Tags under <em>builds</em> folder have version number corresponding to a pattern <strong><code>N.x.K</code></strong>, where <code>N</code> and <code>K</code> are integers. Examples: <code>1.x.0</code>, <code>5.x.1</code>, <code>10.x.33</code></li>\n<li>Tags under <em>releases</em> folder have version number corresponding to a pattern <strong><code>N.M.K</code></strong>, where <code>N</code>, <code>M</code> and <code>K</code> are integers. Examples: <code>1.0.0</code>, <code>5.3.1</code>, <code>10.22.33</code>.</li>\n</ul>\n\n<p>Recently I have developed training dedicated to Software Configuration Management where I describe version numbering approach and why exactly this repository structure is the best. Here are <a href="http://www.slideshare.net/altern/tag/training" rel="nofollow noreferrer">presentation slides</a>.</p>\n\n<p>There is also my <a href="https://stackoverflow.com/questions/1761513/multiple-svn-repositories-or-single-company-repository/1762051#1762051">answer</a> on the <a href="https://stackoverflow.com/questions/1761513/multiple-svn-repositories-or-single-company-repository/1762051">question</a> about \'Multiple SVN Repositories vs single company repository\'. It might be helpful as long as you address this aspect of repository structuring in your question.</p>\n'}]
['https://Stackoverflow.com/questions/16829', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/2017/']