One SVN repository or many?

Question

If you have multiple, unrelated projects, is it a good idea to put them in the same repository?

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/br         


        

Answer 1

If you plan to or use tool like trac wich integrate with SVN, it makes more sense to use one repo per project.

Answer 2

Personally, I'd create new repositories for each. It keeps the check out process much simpler and makes administration on the whole easier, at least with regards to user access and backups. Also, it avoids the global version number problem, so the version number is meaningful on all projects.

Really though, you should just use git ;)

Answer 3

Similar to Blade's suggestion about sharing files, here is a slightly easier, yet less flexible solution. I setup ours like so:

• /var/svn/
• /var/svn/bin
• /var/svn/repository_files
• /var/svn/svnroot
• /var/svn/svnroot/repos1
• /var/svn/svnroot/repos2
• ...

In "bin", I keep a script called svn-create.sh which will do all of the setup work of creating an empty repository. I also keep the backup script there.

In "repository_files", I keep common "conf" and "hooks" directories that all of the repositories have sym links to. Then, there's only one set of files. This does eliminate the ability to have granular, per-project access without breaking the links, though. That was not a concern where I set this up.

Last, I keep the main directory /var/svn under source control ignoring everything in svnroot. That way the repository files and scripts are under source control as well.

#!/bin/bash

# Usage:
# svn-create.sh repository_name

# This will:
# - create a new repository
# - link the necessary commit scripts
# - setup permissions
# - create and commit the initial directory structure
# - clean up after itself

if [ "empty" = ${1}"empty" ] ; then
  echo "Usage:"
  echo "    ${0} repository_name"
  exit
fi

SVN_HOME=/svn
SVN_ROOT=${SVN_HOME}/svnroot
SVN_COMMON_FILES=${SVN_HOME}/repository_files
NEW_DIR=${SVN_ROOT}/${1}
TMP_DIR=/tmp/${1}_$$

echo "Creating repository: ${1}"

# Create the repository
svnadmin create ${NEW_DIR}

# Copy/Link the hook scripts
cd ${NEW_DIR}
rm -rf hooks
ln -s ${SVN_COMMON_FILES}/hooks hooks

# Setup the user configuration
cd ${NEW_DIR}
rm -rf conf
ln -s ${SVN_COMMON_FILES}/conf conf

# Checkout the newly created project
svn co file://${NEW_DIR} ${TMP_DIR}

# Create the initial directory structure
cd ${TMP_DIR}
mkdir trunk
mkdir tags
mkdir branches

# Schedule the directories addition to the repository
svn add trunk tags branches

# Check in the changes
svn ci -m "Initial Setup"

# Delete the temporary working copy
cd /
rm -rf ${TMP_DIR}

# That's it!
echo "Repository ${1} created. (most likely)"

Answer 4

My suggestion is one. Unless you have different users accessing each one, then I'd say use multiple.

But again, even that's not a good reason to use multiple.

Answer 5

one additional thing to consider is the fact that using multiple repositories cause you to loose the ability to have unified logging(svn log command) this alone will be good reason for choosing single repository.

I use TortuiseSvn and found that the "Show Log" option is a mandatory tool. although your projects are unrelated, I'm sure that you will find that having a centralized global cross-projects information (paths, bug ids, messages and so on....) is always useful.

Answer 6

Similar to mlambie's of using a single repo, but went bit further with the folder structure to easily zoom to particular type of projects - web html based projects vs. cs (C#) vs. sql (SQL create/execute scripts) vs. xyz (Domain Specific Languages like afl (AmiBroker Formula Language) or ts (TradeStation)):

/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>

Note, I have trunk live within branches as I treat it as the default branch. The only pain sometimes is when you want to quickly create another project you need to build out the ProjectName/branches|tags structure. I use app-settings simply as place to keep specific Apps settings files in repo so easily shareable to others (and substitute ClientName to VendorName and ProjectName to AppName in this folder structure; and the branches|tags can be useful to tag settings across different major versions of vendor products too).

Welcome to any comments on my structure - I recently changed it to this and so far pretty happy but sometimes find it burdensome to maintain branches|tags structures per project - particularly if the project is simply a project setup simply to Unit Test another project.