9

Off the clock I'm going to try and come up with a strategy for version control for my company; we currently use SVN but there's no structure to it - we basically only have a trunk and only commit to that. Recently the development manager started a second repository that acts as our "tag", but it has to be manually merged with the "trunk" since it's not part of the same repository but a totally separate one. In effect there is just one folder, called "Dev" (there's actually different "Dev" folders at different dates but just "Dev" is the main one) and under that is everything else; all the other projects. It's not organized by project at all, it has no concept of branches/tag/trunk or anything. The person who set it up initially (long gone, of course) seemed to not know how to set SVN up at all, and since then nobody has bothered to learn how to do things properly for fear of breaking something. We don't use any kind of CI (or automated testing, unfortunately).

First, should we have it separated by project? For instance, we have: Two ASP.NET web sites (not Web Applications, Web Sites), a Web Service, a deployment folder for all the table scripts and stored procedures, two command-line clients for external projects that get called by the WebSites and a shared folder that has common business objects and the like. Should each of these be their own project with a branches/tag/trunk setup, or should it be like this:

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

and have all the branches and everything have a copy of the entire Dev folder? That approach might be easier to swallow since we often have situations where we need to make changes in the shared code library and at least one (usually both) of the web sites as well.

Second, we do regular releases ("pushes" in our parlance) to our dev server and live server. From what I've read the best way to handle this would be that all development goes into trunk/, branches are "temporary" and used for adding a new feature that might affect trunk, and tags are for releases? So, we push every month let's say, and I'm working on a brand new module. I would branch trunk, and use that branch for my code, writing and testing it and whatever. When the module is done, I'd merge it back into trunk (and maybe delete the branch), and when we are ready to deploy we would tag it ("May2011" let's say). If we have a bug fix after it goes live, it would be fixed in the May2011 tag and merged into trunk (so trunk gets the fix as well), and then May2011 would be pushed out again with the fix? Is this the intention of tagging?

Improve this question
4
  • 5
    Outside the box strategy: switch to git.
    – Rein Henrichs
    May 12, 2011 at 16:21
  • If that was an option, I would do it (or Mercurial, since we're a Windows shop). I think I'd face even more resistance trying to move to a totally new source control system than trying to at least get a proper environment set up with SVN.
    – Wayne Molina
    May 12, 2011 at 16:27
  • 3
    Although I'm excited about DVCS, Subversion is a good tool. CVS or another solution without folder versioning would be worse.
    – Matthew Rodatus
    May 12, 2011 at 16:40
  • 2
    @Wayne M - You may find it's actually the other way around. It might be easier to get people to sign up to a more sensible environment structure if doing so gets them all of the advantages of using a DVCS. As a transition, you may want to consider getting peopel to try out cheap local branching/repo access using gitsvn or hgsubversion. Once they're hooked and used to the tools there may well be a group wide desire to move to a DVCS for the primary repo(s).
    – Mark Booth
    May 13, 2011 at 11:00

3 Answers 3

Reset to default
5

If you want a unified build process, then be sure to put branches/tags/trunk at the root, like this:

branches/
tags/
trunk/
  dev/
    ...

If you don't need a unified build process, then you can put branches/tags/trunks within each project if you want. However, it might be difficult to migrate to a unified build after having put them within each project. A unified build has advantages, such as eliminating the need to publish shared components among projects -- they're all part of the build.

Personally, I like a unified build process. Furthermore, I don't think you should have a "dev" project. You should have projects directly under trunk, and then branch trunk into a dev branch. Use tags for releases. For example, I would do it like this:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/
Improve this answer
2
  • 1
    A unified build has advantages, such as eliminating the need to publish shared components among projects -- they're all part of the build.
    – Matthew Rodatus
    May 12, 2011 at 16:30
  • 2
    If you need multiple unified builds, then create directories under trunk for each. But, I wouldn't name one "dev" -- that's better accomplished with a branch. For example, you might have two primary dev organizations -- one which works on device drivers and one which works on the company web site. You'd probably want two separate unified builds.
    – Matthew Rodatus
    May 12, 2011 at 16:32
2
  1. As far as code structure within svn goes this is really personal choice.

I would suggest that if the projects are related or share code then they want a common trunk. If they are independent then they want separate trunks or even separate repositories. If you ever need to provide a third party with a copy of the svn history for a project then it is much easier if it is in a separate repository.

So in your case it sounds like the layout you sketched above would be reasonable, as you have shared code and you would want branches/tags to include that shared code.

  1. Your description of tag and branch use sounds eminently sensible and is how I would expect svn to be used. That is indeed the intention of tagging as I understand it. BTW in svn tags and branches are actually the same thing, but the terminology is applied as you have applied it.

Personally I would also add the caveat that anything committed to trunk must build, must be atomic and shouldn't break any unit tests. Branches are for unfinished work in progress. I would expect the trunk to be a potential release candidate at any point.

Improve this answer
1
  • Are you saying that only tested, production-ready code should be in trunk? I think any code that is committed should build and probably pass tests, and trunk code should of course pass tests. But it seems like the purpose of SVN is to be able to follow development history, and that's easier if it's not split across multiple branches. Perhaps there should be a branch that you merge trunk into when trunk is in a tested, production-ready state?
    – Mr. Jefferson
    May 12, 2011 at 20:48
1

The following is the best way to lay out a Subversion repository

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

This way you can check out individual projects by themselves.

If you want to check out all 3 projects and do a unified build with some monolithic build script/system then investigate using a master module with svn:externals mapping all the other projects into the master trunk.

This is more complicated at first glance but it is the most maintainable and idiomatic way to solve this problem with Subversion.

Improve this answer
1
  • 2
    I strongly disagree. The repository does more than just store code; it communicates organizational structure and the relationship between components; it is a vital, albeit implicit, communications channel. If you break each project out separately then you are introducing artificial and unnecessary barriers to communication.
    – William Payne
    May 25, 2012 at 19:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.