The Ficks | VCS-Home / Organizing Your Repositories browse

While the main idea is to store your home directory in a VCS system, if you have anything more than just a few files, it will probably be useful to organize your files into multiple repositories by subject matter. The svn externals feature is very helpful in doing this.

Easier svnexternals

To manage externals with svn using properties can be a bit wieldy from the command line, so a simple simple script can be helpful. I usually call it .svnexternals, it generally looks like this:

#!/bin/bash

externals()
{
cat - <<EOF
        mail http://server/svn/mail/
        docs http://server/svn/docs
EOF
}

svn propset svn:externals "$(externals)" .

The format is meant to mirror the format of svn externals. Edit your list and run the script to apply the properties to your local directory.

Easier svnignore

In the same light, you can also create a simple .svnignore script:

#!/bin/bash

ignore()
{
cat - <<EOF
auth
EOF
}

svn propset svn:ignore "$(ignore)" .

Don't forget to check those scripts into the working directory to which they apply!

When deciding to split up your repositories, think not only about subject matter, but also think about the frequency of changes and whether you will want to keep certain subjects indefinitely. Let me give you an example: I store my mail in an svn repo (I know, some people think that is silly, it works nicely for me). While I have hundreds of mail folders that I want to keep longterm, I have several folders that I consider to be mostly temporary, but that I still want backed up (inbox, trash, spam...) For these temporary folders, I have a separate repository, I call it volatile. If at some point I feel that I want to eliminate the history of the temporary folders, it will be easier to do that with a separate repository for them.

Subversion even has a nifty svn-admin tool that will really help you do that. With this tool you can create a new stripped down repository while even maintaining repository version numbers. This means that you can strip down a repository without interrupting your working directories which point to that repository!

Laying out and combining your repositories

Once you have various repositories with different categories of data in them you might discover that you have a need to manage which repositories to pull from and where. If you have multiple home directories, say one at the office and one at home this will soon become evident. One way to manage this is to create a special repository, I use one named layout, to organize different views and not really store any actual data files. You can use this repository like this:

 layout/home/work
            /home
            /guest
            ... 

 ....../machines/mail
                /www
                /music
                ...

each one of these "leaf" directories (which are not necessarily actually leaves, but could be the root of an entire structure) in this diagram would contain some svn externals.

This way, at work in your home directory you would checkout:

  svn:...layout/home/work

which may then contain externals such as:

 ...music/
 ...src/
 ...mail/

which will automatically get checked out! But at home you would instead check out:

  svn:...layout/home

which might then contain even more externals such as:

 ...music/
 ...docs/
 ...src/
 ...mail/

But when you are on your significant other's laptop, you check out:

  svn:...layout/guest

which might then contain a more limited set:

 ...docs/
 ...mail/

Or, you could even add another level under /layout/home with different user accounts and host a repository for your significant other's files too!

Hopefully from this you can see where to go. I added the machine examples also because you might want to manage the layout of other data besides just home directories. Maybe you have your music available through svn, but you also have a music server somewhere. In this case you will choose a directory somewhere on that music server to check your music out into. This directory will not necessarily be in someone's home directory, but nevertheless it might have several data sources and you can then also manage them through externals.