How would you organize a Subversion repository for in house software projects

Question

I work for a company whose primary business is not software related. Most documentation for using source control is written with a development team writing for commercial or open source projects in mind. As someone who writes in house software I can say that work is done differently then it would be in a commercial or open source setting. In addition there are stored procedures and database scripts that need to be kept in sync with the code.

In particular I am looking to get suggestions on how best to structure the repository with in house software in mind. Most documentation suggests trunk, branches, tags etc. And procedures for keeping production, test and development environments in sync with their respective sections in the repository etc.

Answer 1

You could use a service like www.unfuddle.com to set up a free SVN or GIT repository.

We use Unfuddle and it's really great. There are free and paid versions (depending on your needs).

Or, you could of course set up a local copy. There are plenty of tutorials to be found via Google for that: http://www.google.com/search?rlz=1C1GGLS_enUS291&aq=f&sourceid=chrome&ie=UTF-8&q=set+up+svn

Answer 2

As specified in this thread, distributed VCSs (git, Mercurial) are a better model than centralized ones, due to branch creation ease, branch merging ease, no need to setup a special server, no need to have network access to work and some other advantages. If you'll work alone the DVCS allows you to incorporate people to your projects if the need arises very easily.

Anyhow, answering directly your question, a way to set up SVN would be to have a repository per project and, depending on if stored procedures and scripts and libraries are shared or not, create a directory on each project tree for scripts and stored procedures, or a full repository for the shared code.

Answer 3

For subversion, there is Assembla too which comes with Trac and other useful tools. It's free or you could pay for an account if you need more space or users per project.

Kind Regards

Answer 4

For my company, I use svn+ssh and key-based authentication. You can do this with both windows clients and linux clients. This is real easy to use once you get your keys straight as you use an ssh key to login rather than typing a password.

Here's an article on setting up svn+ssh with notes on security. If you understand all of this stuff and follow these steps, you'll be off to a good start. http://svn.haxx.se/dev/archive-2004-03/0253.shtml

This article describes a number of ways to further secure your ssh logins for the svn accounts. http://svn.collab.net/repos/svn/trunk/notes/ssh-tricks

I recommend creating accounts specifically for svn access with no other access to that server. My guess is that you would use a daily build or automated script to update your stored procs in the db. Daily builds can have their own special accounts and their own ssh keys. I don't like for my automated tools to run with the same login as a human user (so I know which tool is broken).

If you don't understand all of the security tricks, searching google can get you some help. If you have trouble, set one up without the security tricks first. That makes it a bit simpler to troubleshoot.

Good luck, and enjoy having the benefits of source control!

Answer 5

One repository for your projects is probably sufficient. I like the typical approach that indexes the layout by project (see this section from the O'Reilly Subversion book):

/first-project/trunk
/first-project/branches
/first-project/tags
/another-project/trunk
/another-project/branches
/another-project/tags
/common-stuff/trunk
/common-stuff/branches
/common-stuff/tags

Keep in mind that you can always reorganize the repository later.

Also, for in-house stuff, I prefer FSFS for the data-store, as opposed to Berkeley DB. FSFS is more resilient and the speed of checkouts is not much concern for small teams/projects. You can compare and decide for yourself.

Other standard parts of the recipe include Trac and a minimal Linux server to host the repository on the LAN.

Answer 6

Setting up SVN repositories can be tricky only in the sense of how you organize them. Before we setup SVN, I actually RTFM'd the online Subversion manual which discusses organizational techniques for repositories and some of the gotchas you should think about in advance, namely what you cannot do after you have created your repositories if you decide to change your mind. I suggest a pass through this manual before setup.

For us, as consultants, we do custom and in-house software development as well as some document management through SVN. It was in our interest to create one repository for each client and one for ourselves. Within each repository, we created folders for each project (software or otherwise). This allowed us to segment security access by repository and by client and even by project within a repository. Going deeper, for each software project we created 'working', 'tags' and 'branches' folders. We generally put releases in 'tags' using 'release_w.x.y.z' as the tag for a standard.

In your case, to keep sprocs, scripts, and other related documents in synch, you can create a project folder, then under that a 'working' folder, then under that 'code' and next to it 'scripts', etc. Then when you tag the working version for release, you end up tagging it all together.

\Repository
   \ProjectX
      \Working
         \Code       
         \Scripts
         \Notes       
      \Tags
      \Branches

As for non-code, I would suggest a straight folder layout by project or document type (manuals, policies, etc.). Generally with documents and depending on how your company operates, just having the version history/logs is enough.

We run SVN on Windows along with WebSVN which is a great open source repository viewer. We use it to give clients web access to their code and it's all driven by the underlying Subversion security. Internally, we use TortoiseSVN to manage the repositories, commit, update, import, etc.

Another thing is that training should be considered an integral part of your deployment. Users new to version control may have a hard time understanding what is going on. We found that giving them functional instructions (do this when creating a project, do this when updating, etc.) was very helpful while they learned the concepts. We created a 'sandbox' repository where users can play all they want with documents and folders to practice, you may find this useful as well to experiment on what policies to establish.

Good luck!

Answer 7

After posting this question I spoke with a coworker who suggested I read the article:

http://www.codinghorror.com/blog/archives/000968.html

In short, it advocates that programmers be more aware of branching. It helped me to see there is no right way to go about organizing our repository. For our team we will have a trunk and two long term branches for test and development. In addition we will make seperate branches for each task do we and merged the changes from the task branches as we promote the task up to testing and production.

Answer 8

I believe in following the basic pattern with a project dir with trunk,tags,branches beneath it. I usually like to setup the top level like this

Projects holds all of the individual project or modules Releases holds release tags that involve multiple modules Users holds private user branches Admin holds my hook scripts, backup scripts etc.

The release tags are useful if you have a product that is made up of several modules that all may be a different tags for a specific release (one ring to bind them and all that). It makes it easy for source escrow and for developments to reference what made up release 1 or 2.

Answer 9

I agree with using the common conventions of trunk/branches/tags. Beyond that, I think you might be looking for something like my answer at http://stackoverflow.com/questions/222827/how-do-you-organize-your-version-control-repository#304036.