Structure of Projects in Version Control

Question

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

Answer 1

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.

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.

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.

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.

Answer 2

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

+ devroot
    +--Dept1
        +--Dept1Proj1
        +--Dept2Proj2
    +--Dept2
        +--Dept2Proj1
    +--Tools
        +--Purchase3rdPartyTools
        +--NLog
        +--CustomBuiltLibrary

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.

• It's hard to fix production problems if you are working on a major product upgrade (ie because we don't do branching)
• It's hard to manage the concept of promoting from "Dev" to "Prod". (Don't even ask about promoting to QA)

Answer 3

As we have all the artifacts and construction in the same tree we have something like:

• Trunk

  • Planning&Tracking
  • Req
  • Design
  • Construction
    • Bin
    • Database
    • Lib
    • Source

• Deploy

• QA
• MA