Subversion Repository Layout

About Mark Phippard

Engineering manager for several teams at CollabNet, including CloudForge, Subversion, Subversion Edge, Git and our Desktops and Integrations. Project owner for the Subclipse project, which provides Subversion support in Eclipse. Also a full committer for the Subversion project. Product owner for GitEye, Subversion Edge and the CollabNet Desktops and Integrations.

  13 comments for “Subversion Repository Layout

  1. May 1, 2007 at 10:09 pm

    is there any trunk strategies as we were used in other version control system(clearcase).

  2. May 2, 2007 at 4:34 am

    We have a discussion forum that is well suited to ask questions of this nature:
    The forum is frequented by other users that have migrated from ClearCase to Subversion or are considering it.

  3. Deepali Parikh
    November 1, 2007 at 9:03 pm

    Can we use 2 different layouts in one subversion repository. And at later stage can we change the repository layout and still can be able to maintain the history?

  4. November 2, 2007 at 5:54 am

    Yes and yes. It is basically a file system. You can organize stuff in any way that meets your needs. If you want to change it, you can use svn move to move things in the repository and all history stays attached.

  5. Tim
    October 7, 2008 at 4:33 pm

    We have a growing project in subversion that we want to split into many projects each with its own repository, retaining existing history. Is there a how-to for this? TIA.

  6. October 8, 2008 at 7:08 am

    Subversion has the svndumpfilter tool. If you Google for it you can find some how-to’s that people have written. There are limitations in this tool if you have done any copies between these projects. If you run into that, then Google for svndumpfilter2 and svndumpfilter3 which are scripts that enhance the process. There is also a Perl module in CPAN if you want to script your own solution.

  7. May 2, 2009 at 11:01 am

    Can you please elaborate more what a deep directory tree structure would look like? Would you just have a /trunk/a/b/c/d/e/f.doc and then if you make a branch copy just that file to /branch/a/b/c/d/e/f.doc?

  8. Mark Phippard
    May 4, 2009 at 11:57 am

    I’d encourage you to always branch the root of the project, whether it is /trunk or /trunk/ProjectA or /ProjectA/trunk.

  9. Parminder Kaur
    June 22, 2009 at 2:49 am

    Myself is working as a research fellow in the area of software engineering. I make use of Subversion to keep track of changes in my work. while dealing with .doc files, i am facing problems. Please suggest the ways to associate .doc files with subversion.

  10. Blair Davies
    October 22, 2009 at 12:54 pm

    One thing I’m having a hard time getting my head around is the notion of working copies vs current copies vs the repository itself.
    What I want to setup is a central code tree that has my ‘gold code’ (current copies) that we compile and build from (ex: c:production). Then each of the developers has their own working copies of some files (ex: c:mydev). When they commit their changes they are merged into the ‘gold code’ and deleted from their working directory if they are finished.
    I thought the repository would then be c:production. But that doesn’t seem to be the case.
    Can you explain this to me?

  11. Bill Richards
    December 7, 2009 at 3:03 am

    The repository itself is the thing that retains all versions of each file checked in, and the attached history for each item.
    The current version is the latest version within the repository.
    The working version is the code checked out locally on a developer’s machine.
    Code check outs are on a per-user basis, and you can check your code out to anywhere you like, so long as you have write permissions and access to the repository.
    For example:
    // all files for project1
    // all files for project2
    Any developer with access to this repository (Solution1) can check these projects out to whatever local storage they like …
    C:working version
    Checking code in from the local working copy results in a new version number in subversion.
    Your build server (if linked to SVN) will pick up the current version and build the solution.
    You can check your code out to multiple locations if you like, but this is all under the user’s control, not SVN.
    Subversion will not dictate where your doe is checked out to.

  12. February 2, 2010 at 9:57 am

    What is the recommended strategy for storing configuration files and other files that change reguarly and nonlinearly on subversion?

Leave a Reply

Your email address will not be published. Required fields are marked *