I recently had cause to make an SVN branch in one of my hobby projects' repository. Alas, when I configured the repository, I didn't do it right and make trunk and branches, but instead put my project right in the root of the repository. It only took a little SVN command-line stuff, but it was pretty easy to change the repositories without losing any history.

For my purposes, I generally create a common SVN repository root, which I expose then through my Apache server, usually using the path /svn. Then the repositories in the root can all have their own commit histories. Within the repository roots I create project folders; this is where I've gone awry. Most often I'll make a project in Eclipse, for example, and then use the SVN plug-in to share the project. I've probably done it wrong and not chosen a trunk/branch kind of layout.

Normally this isn't a problem as I'm not usually one to make branches on my own projects. I do keep the versions for history, but also to make it easy to share workspaces across systems, and even to access code through the web browser for quick copies of clever code to other projects. In this particular case, I wanted to make a branch to try something new, but didn't want to affect the baseline from which code had been released; it did work out, in fact, that I discovered something that needed changing in the released project, so I was able to make the change in the trunk, and later reflect it when I merged the branch back...but that's getting a little ahead of the story.

With the following few commands, the error of missing trunk and branch folders can be quickly rectified. This is assuming an HTTP-enabled repository; if using a local file system use "file:///path/to/repo" instead of the "http://servername/svn/repo" in the example. The servername is the hostname of the server in question. The svn is the path exposed in the HTTP config, and repo is the name of the repository in particular; if not using an SVNParent it may be that the svn is the root of the repository, so the repo can be skipped. Finally, the project is the project folder within the repository.

svn mv http://servername/svn/repo/project http://servername/svn/repo/project-trunk -m "Making trunk/branches"

svn mv http://servername/svn/repo/project-trunk http://swbyjeff.com/svn/repo/project/trunk --parents -m "Making trunk/branches"

svn mkdir http://servername/svn/repo/project/branches -m "Making trunk/branches"

The blog doesn't do the wrapping well, but each line starts with "svn" and ends with the "making trunk/branches" comment.

• The first line moves the current repository project folder out of the way. The target name just needs to be unique and not collide with another folder or project. At this point the original project folder doesn't exist, so any checked-out projects won't be able to be synchronized; it's important to either plan for a new project name or to return to the same project name in the next step.
• The second line creates a new project folder and moves the original content into the trunk. Note this couldn't be done in one step with the previous unless the project name was being changed as the mv command won't move a folder into a subdirectory of itself.
• The last line finally creates the branches folder for the project. Technically this isn't necessary until branches are being made, but having the folder out there before it's needed will make brancing easier.

This will create three new revisions in the repository, but the whole history will be maintained.

Where the project has been checked out, such as in the IDE, all that remains is to switch the repository folder for the project to the trunk folder. Since the new folder is in the same tree as the previous, this is a simple step and shouldn't be met with difficulty. From the command-line this is as simple as doing an "svn switch http://servername/svn/repository/project/trunk" from the root of the checked-out folder. Alternatively the project can simply be checked-out from the trunk folder.

After moving the root, making branches is possible, as there's a trunk from which to copy. Branches will then end up in the repo/project/branches/BRANCHNAME folder, where BRANCHNAME is whatever is specified when the  branch is created.

Note that if there are no project folders, and the content is in the root of the repository, there'll be more effort as it isn't possible to  move a root folder into a subfolder of the root in one felled swoop (as the two-step copy above shows). However, with some dilligence it can be done. The first step is to create a trunk folder in the root of the repository. The next step is to move each file and folder in the root into the newly created trunk folder. Then the branches folder can be created. Finally the switch to trunk can be made.