I'm fairly new to SVN and I would be interested in hearing about how other people would organize projects in SVN.

We have projects that have different types of source files: C#, SQL, and Matlab. In addition to these types of files, we have Excel and Word file reports that we do not intend to put into SVN.

So let's say we have a projects directory:


Now for the SVN repository, would it make sense to categorize things by source file type (C#, SQL, Matlab) then project:


Or would it make more sense to categorize things by project first then source file type:


Or maybe there's a better way to do this?

Also, what is the best way to indicate in the Projects folders (not SVN) that a project contains files saved in SVN? Like, if I went into a the project folder for Project1 (Projects\Project1) and only saw Excel and Word reports, what would be the best way to indicate that there are other files checked into an SVN repository?

Also, how does everyone feel about putting checked out SVN files on shared drives? So for instance, let's say Projects\Project1 contains the following files:

Script.sql (This is a checked out SVN files in the Projects folder, which is a shared network drive)

In this situation, it would be very easy to see when there are SVN files used with a project, BUT having the checked out SVN file on a shared drive would make collaboration much more difficult. Is this others do to?

  • 1
    I don't understand your last question about "checked out" files on a shared drive. Why would you do that? Are you sure you understand the purpose of SVN? :)
    – Andres F.
    Commented Feb 3, 2012 at 15:14
  • @AndresF., I completely agree with you, this is an idea my coworker is suggesting. His reasoning is that with checked out SVN files on the shared drive, there's not another location for people to find files associated to a project. That's just another level of complexity that will make life a lot more difficult for the non-technical people on our team. It does certainly defeat the purpose of SVN in my ways, but it makes things a little easier. I came here to see if anyone else agreed with his idea or if there is a better alternative.
    – sooprise
    Commented Feb 3, 2012 at 15:35
  • 1
    An SVN repo can be configured to be browsed using Internet Explorer, so non-technical people can still see your reports (they can even bookmark the URLs!). If you want them to be able to edit the reports, you will have to train them to use something like TortoiseSVN, which is not too hard: it integrates directly with Windows Explorer.
    – Andres F.
    Commented Feb 3, 2012 at 15:41
  • 2
    SVN can't solve conflicts in binary files; its merging capabilities are meant for text-based files such as source code! This doesn't mean you cannot check-in binaries such as Word documents or JPEGs -- in fact this is extremely common. It just means you cannot merge binaries. One way to make sure you don't get conflicts is locking your binary files (your reports) by using the svn lock command. Don't give up on SVN yet, the use case you're describing is not at all uncommon.
    – Andres F.
    Commented Feb 3, 2012 at 18:00
  • 1
    @sooprise: You are going to have to deal with merge conflicts when many people are editing a single file, no matter what format it is. In your shared directory example: I open the file, then you open the file and save a change, then I save a change. Your edits are lost. The advantage of version control is that even if I commit my changes without incorporating any of your's, you can always step back to the previous revision and correctly merge the data. As for push-back, some times you have to tell people this is the way it is going to be and explain why this is better. Commented Feb 3, 2012 at 18:44

3 Answers 3


You have three questions there:

  1. It makes more sense to group by project, i.e. svn\project1\whatever, since "project" is the most meaningful category. Why would you group completely unrelated projects just because they are implemented in C#?
  2. Not sure I understand your second question. With SVN, files in your working copy may have several possible statuses: checked in, dirty (i.e. you have uncommitted local changes), ignored (i.e. local files not managed by the repository), etc. Use an UI such as TortoiseSVN (if you are using Windows) and it will nicely show you the "status" of each file. Or you could use the command line as well, but that's less user friendly.
  3. "Also, how does everyone feel about putting checked out SVN files on shared drives?" This question makes me think you don't entirely understand the purpose of using a source versioning tool such as SVN. The purpose of checking out files is for you to have a local copy to work with. If you share this copy, especially if you provide write access to it, you are defeating part of the purpose of using SVN to begin with!

Note that SVN cannot gracefully handle conflicts in XLS and DOC reports, because they are binary files (you'll get a conflict if two people try to modify and commit the same file). Merge/diff in SVN is meant for text-based files, such as source code, not for binaries. One way to solve this problem is to lock your binaries for editing. This can be done using the svn lock command (or the corresponding option from an UI such as TortoiseSVN).

You may want to read an explanation of when locking is necessary. It's relatively easy to understand.

  • User friendly depends on a number of things. If you are not on Windows, the command line is a better friend. Commented Feb 3, 2012 at 15:13
  • Maybe so, but let me guess that the OP is using Windows ;)
    – Andres F.
    Commented Feb 3, 2012 at 15:16
  • Let me clarify my other question. Let's say we have a shared drive called the S drive which contains project folder called S:\Projects\Project1, which contains Report.doc, and Script.sql. Script.sql is actually a file that is checked out from the SVN repository that just lives on the S drive so that people know there is a file associated to this project in SVN. Because this checked out file is on a shared drive, if two people try working on it, they would have to create their own local copies, which almost defeats the point of having it on the shared drive at all. Does this make sense?
    – sooprise
    Commented Feb 3, 2012 at 15:18
  • @sooprise I think I understand you. It's a bad idea for people to edit your file Script.sql on the shared drive. People can figure out what files are there by browsing the SVN repo directly! No need for a shared drive at all.
    – Andres F.
    Commented Feb 3, 2012 at 15:22
  • 1
    @sooprise: Any content that is important to the project and evolves with time can be put in version control. Content that isn't source code should should be in a different folder under the main project directory in order to keep things from being jumbled together. Commented Feb 3, 2012 at 15:35

What's the benefit of segregating source files based on language? Why put all the resources (code, images, configuration files, etc.) in the same project directory? I'd stick with the conventional SVN layout and have subdirectories for trunk, branches, and tags:


Within a project directory such as trunk, you'd have all the files that you need to build the project. If it makes sense to divide them into subdirectories, do it, but make sure that there's some benefit to the organization. For example, you might have a directory for artwork so that you can let your graphics team access those files but not the source code, and your programmers can access the source code but can't change the art. Or, it might just make it easier to copy all the image files to the right spot in the product during the build process. If it makes sense to segregate files by language, there's nothing wrong with doing that too. Just know why you're doing it.

Take a look at Version Control with Subversion for a great deal of helpful information. For example, there's a chapter on administering a repository that starts off by considering repository organization.

  • @unholysampler, is it standard to have trunk, branches, and tags directories per project? That's something else I was wondering about. Currently in SVN we have things split up by language, and each language folder has the trunk, branches, and tags folders inside. It sounds like from the comments here that we'll split things up by project, but I'm still unclear if there should be these trunk, branches, and tags folders for the entire projects folder, or per project folder. Thanks :)
    – sooprise
    Commented Feb 3, 2012 at 15:40
  • The trunk, branches, and tags directories are the usual convention. There's nothing in Subversion that enforces that -- you can organize your stuff any way you like, but if you stick to the convention other people will have an easier time relating to your repository.
    – Caleb
    Commented Feb 3, 2012 at 15:51
  • I'm wondering if you should put trunk, branches, and tags in SVN\Projects or in SVN\Projects\Project1, SVN\Projects\Project2 etc
    – sooprise
    Commented Feb 3, 2012 at 17:46
  • Put them in the individual project directories: Projects/Project1/trunk, Projects/Project1/branches, etc. The trunk directory will, depending on how you use it, contain the main line of stable development code, or perhaps the current distribution code. Branches are typically used for new development until that new code is ready to be merged into trunk. Read the book I linked -- it's free, and there's a lot of good info in there.
    – Caleb
    Commented Feb 3, 2012 at 17:54

You know, in SVN most popular folders sheme for "things" is trunk, branches, tags.

Now, how to choose what kind of "things" to use for above scheme?

My preferred way to arrange SVN structure can be called "versioning-driven". Not that it's particularly "my" way, just one suggested by more experienced colleagues. Anyway it's one that has been proven to work best for me.

Versioning-driven means things are defined by whether you find it convenient to have dediccated versions sequence for this kind things, like version 1.0, 2.0, 3.1 etc. anything you want to be "within" that version sequence, makes single SVN "thing". Anything you would find convenient to release under different "version streams" gowes to different SVN "things".

- This product release is composed from component1 version 1.23, component2 version 4.56 and component3 version 7.98. where can I get code for component1 used in this release?
- Code for component1 v1.23 is in SVN folder component1/tags/1.23

- There was patch 666 we did for component2 version 4.3.1 two years ago. Where I can get its code? I am particularly interested in releases 1.0 and 2.0
- That's easy. You can find patch code in SVN folder component2/branches/ and releases in component2/tags/, component2/tags/

You see, above has basically nothing to do neither with project nor with source file type.

  • If I need say particular "mix" C#, SQL, Matlab to be released/versioned as a whole (component1 ver 1.0, 2.0, ...), these would go inside one "thing" - having same trunk, tags, branches.

  • If I need some bunch of C# files to be released/versioned separately of another bunch of C# files (component2 version 4.56 and component3 version 7.98), these would go to separate "things", each having dedicated sub-folders trunk, tags, branches.

As for the projects, SVN folders for these are, again, versioning-driven. If I can think of versions 1.0, 2.0, etc of the project, to me it means the need for own SVN "thing" - own folder "project-name" with trunk, tags, branches sub-folders inside.

Your Answer

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

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