Best practice for structure of Subversion repository working copy?

Question

I'm just getting started learning how to use Subversion for building my web applications, so bear with me.

Here is how I am setting it all up:

• One of my domains will host the repositories for all of my projects. I have the standard tags/branches/trunk structure. This is in a public folder so it can be accessed by other developers.
• I will have a folder on my live server containing each release of the application, and I'll have a symlink in the web directory pointing to the current release. This way, when I release an update to the application, I export it to the release directory and then switch the symlink so the changes are online instantaneously.

Here is my question:

What is the best structure for the local working copy of the project? I'm going to be working on both branches and the trunk quite frequently, so should I check out the entire repository structure (tags/trunk/branches) or just check out the trunk and each branch individually into different folders?

Also, if anything I said about how I have it set up seems strange or a wrong way to do it, let me know (I'm new to this!).

Answer 1

I've always used svn switch to bounce around between branches when developing. Works pretty well and saves you the need to have all sorts of checkouts floating around (can do this all in one working directory)

Here's the docs: http://svnbook.red-bean.com/en/1.0/re27.html
And a brief article on the topic: http://concisionandconcinnity.blogspot.com/2008/04/svn-switch.html

Answer 2

You can check out the entire repository if you really feel like it. It's up to you. Personally, I would just check out the parts that I'm actively working on. That way, "svn update" doesn't take forever, and less space is taken up on my own hard drive. As for switching between locations in your repository, there is a special command for that: "svn switch" (abbreviated "svn sw"). Use "svn help switch" or see the link for more info:

http://svnbook.red-bean.com/en/1.1/ch04s05.html

Answer 3

Agreed- keeping only the branch you're working on is the best idea. The only hiccup with svn switch is that you'll need to use the --relocate option to flip between repositories should you wind up with a truly local copy.

You could look at git if you need to really start distributing clones of your repository. Git will allow you to keep a full local copy, easily move between branches and push your changesets back to the "master" repo or other clones.

Answer 4

Hi

If I were you, I'd also think about having a workspace with a standard and meaningful name in the live server which contains the current (most current if you like) release and this would be a checkout of the release folder in your central repository. Then you will simply need to do a "svn update" instead of changing symlinks to the different releases. Would save you space as well on your server as the repository would keep your archives all crunched up.

For clarity: If your svn repository has this typical structure:

/trunk

/src
/bin
/docs
/scripts

/tags

/released

You can have this folder to store your releases OR as in our case, you can have a seperate repository for binary archives if you MUST keep all the archives handy (else versioning the source files should be sufficient)

So then, your live server will have a workspace called release(or whatever) which is a checkout of the http:///tags/released . This way you run a svn update on the workspace on the server and voila, your app points to the latest release. Hope this helps.

For local workspace, if you are very new and there is fear of committing incorrectly, its okay to checkout the whole structure once and for all and only update stuff that you are committing and need to change. The other suggestions above are effective as well. YOu can look at checking out the top level directory strcuture of any given folder but make sure that you retain the names consistently to avoid confusion.

Chug away :-)

Answer 5

I like to do a sparse checkout of the entire repository with --depth immediates. Then I make some parts of the working copy "deeper" with

svn update --set-depth somedepth

to get to the parts I want to work on. You can also make part of the working copy "shallower" again to gain disk space.

I do not like to use svn switch because of bad experiences with partially switched working copies. Switch will error out halfway when it encounters an unversioned file obstructing a versioned one etc. It can get confusing.