SVN Repository Structure – Why is this better?

I’ve been told that most development shops have the following structure or at least close to this:

  • Main Repository
    • Project folders underneath
    • Each Project folder has a trunk, branches, and tags folder

so:

  • How do I know which files in a directory arn't in my SVN repository?
  • Is there a way to validate the presence of Javadoc and/or inline code comments?
  • SVN ignore files
  • SVN show usernames instead of user ids
  • svn commit to trigger google analytics annotation?
  • Changing the username for a Subversion commit over svn+ssh
  • ReponsitoryMain
        Project1
            branches
            trunk
            tags
        Project2
            ...
    

    So why is this better or best? What happens or what heartaches have you come across if you did it another way?

  • How to structure a repository that consists of several libraries and applications
  • In SVN you can Check Out (to block others) can you do this in GIT?
  • Exporting Only changed files from subversion maintaining directory structure
  • Unable to open repository error on Windows XP
  • How to skip first N commits when converting svn repo to Git using reposurgeon?
  • Rabbitvsc in Nautilus both git and svn
  • 10 Solutions collect form web for “SVN Repository Structure – Why is this better?”

    This way of organizing the repository:

    ReponsitoryMain
        Project1
            branches
            trunk
            tags
        Project2
        ...
    

    is best when your projects aren’t that connected/dependent on each other. The other way around makes it easier to version your entire project suite. So if you often release/package Project1 and Project2 together, it’s best to have them share the same branch.

    If, on the other hand, your project are very decoupled and have totally different teams working on them, then you wouldn’t need to check them all out together most of the time, and so you could use the above method.

    Most people do this because it’s recommended by the Subversion book.

    Here’s a good explanation from the director of the CollabNet Subversion project:

    http://blogs.collab.net/subversion/2007/04/subversion_repo/

    The repository structure depends on your needs. If your projects are fully separated (no dependencies between them) then this “simple” repository structure is fine.
    If you have dependencies in your project (eg some global “tool-libraries”, shared code) you should use a different structure like:

    trunk
       prj_a
       prj_b
    tags
       <YOUR_TAGNAME>
           prj_a
           prj_b
    branches
       <YOUR_BRANCHNAME>
         prj_a
         prj_b
    

    or anything else which makes more sense to your process.

    In the simple structure with local trunk/tags/branches it is not possible (at least in a clean way) to tag multiple projects, if you have dependencies between them.

    Also the often proposed “Multi-repository” approach will not fill this gap as then you are doomed with multiple revisions or tags in multiple repositories.

    The main problem is that SVN has NO support for shared ressources and tagging/branching them.

    If you think about your Repository structure, you should ask yourself in what process you want to share your code libraries.

    Ok, I’m going to be a little more preachy and come down firmly on the side of having a trunk,tags & branches for each project.

    The main alternative is to have a single trunk,tags & branches with all projects underneath.
    However, this leads to a number of problems, one of which is significant and I’ll detail here:

    Primarily it paves the way to the untouchable library, where everyone’s scared to touch a particular library because any change may break something subtle in some random project. The cause of this is that because there’s no separation between projects, anyone can effectively change the code in your project without you being able to either detect or control it.

    What happens is that one day you check out your project and it builds, the next day you check it out and it fails, but you’ve made no changes to your project. What’s happened is that someone has changed a library that you depended on. In a large structure with many dependencies, it’s unrealistic for a developer to test their library changes against every project, especially if they have to make breaking changes. What you need in your project is a reference to a specific version of the library. That way, the library only gets updated when you change the reference to the latest version.

    This kind of reference has 3 effects: 1 your project is isolated from random intermediate development changes to the library. 2 you get a revision in your project that tells you that “I’m now using this version of the library”. 3. You get to control when you make the changes to your project to account for any breaking changes in the library.

    There are other issues which I can go through if this isn’t enough.

    We keep a separate repository for each project.

    While this doesn’t allow you to copy and keep the version history files from one project to another, it enables you to archive a whole repository when a project is over.

    That’s what we have.
    It works and that’s good enough for now (because we never know what the future will bring)
    We don’t have any compelling reasons to spend some valuable time (and money) to find a possibly more optimal structure.

    M.

    At my shop, we have something like this:

    RepositoryMain
      Trunk
        proj 1
        proj 2
        ..
      Dev
        Team1
          proj 1
          proj 2
        Team2
          proj 1
          proj 2
        ...
    

    I don’t know how this stacks up to most places but it seems to work pretty good

    All the development teams can work separately on their own projects, merging from trunk to their project when they are beginning development/enhancement, and then merging back to trunk once they are finished.

    Trunk branches and tags are all act the same way. How you use them is up to you.

    I’ve been using this structure for years and have yet to find a time that the structure didn’t adapt to what I needed to do.

    In systems like CVS, you didn’t keep separate “directories”. You just tagged and branched.

    However, SVN is modelled more on the idea of snapshots, and therefore “copies” of stuff are done very efficiently. Rather than tagging or otherwise marking special (or alternate) versions of a project, it’s easier (and more efficient) to make a named copy of it.

    Thanks for the Discussion here, I went through this
    and project-structure-for-product-with-different-versions

    link2

    link3

    link4

    I could see terminologies are confusing.
    Projects, Applications, to correctly correlate

    Would like to repeat the above things with somewhat clear exp
    Lets say we do solution for a customer ABC
    Solution is TIcket/HelpDesk Application for ABC’s Clients Queries

    Lets say applicationName is OneDeskApplication. This Application consists
    of
    WebUI,Shared Libraries, Build Tools

    can we design the SVN like this

    XSoftware.com/ABC – Repository
    /
    trunk/
    OneDeskWebUI
    OneDeskService
    OneDeskDBScript
    OneDeskBatchApp
    branches/
    Branch_Product_Support_1_0_0_0/
    OneDeskWebUI
    OneDeskService
    OneDeskDBScript
    OneDeskBatchApp
    tags/
    OneDeskDocs
    OneDeskMasterBuild

    Git Baby is a git and github fan, let's start git clone.