Tutorial :SVN partial branch


I'm new to SVN so this could be an easy question.

We have a "trunk" with 1st level directories:

10 <-- documents  20 <-- source code, db scripts, ...  30 <-- documents  40 <-- referenced 3rd party library-es  

I made a "develop" branch from the "trunk". In "develop" we change our source code and after testing it we merge it to "trunk".

The problem in that in directories "10" and "30" are stored *.doc files that are not needed for development so it is REQUIRED that "develop" branch doesn't have those directories.

The solution should still:

  1. allow "svn update" on root folder of "develop" working copy, (20 and 40)
  2. that update should not re-create directories 10 and 30 and
  3. of course merging "develop" to "trunk" should NOT delete 10 or 30 in "trunk".

EDIT: I forgot to mention that "source code" is not only in 20. There are referenced dll-s and build scripts etc. that are also on 1st level directory, lets say 40.


If I read your question correctly, this is a simple matter of using svn copy to copy only the desired directories into a branch -- basically, a combination of answers from Mike Kushner and Ivan Krechetov. I think, however, it might be easier to understand after running through the steps yourself, so the rest of this post will create a sample repository and show the copies and merges.

I'm going to assume that you're using the "standard" repository layout, which at the top level has three sub-directories, trunk, branches, and tags. And that your 10, 20, 30, and 40 directories are under trunk. In other words:

trunk      10      20      30      40  branches  tags  

And, as Mike pointed out, your goal will be to have a structure that looks like this:

trunk      10      20      30      40  branches      sandbox          20          40  tags  

It's unclear from your posting (at least as-of the current edit), but you may have a directory structure in which 10, 20, et al are at the top level. In this case, you'll need to create a new top-level directory, which I'll call dev, so that your overall repository looks like the following:

10  20  30  40  dev      20      40  

Note that you cannot create dev under 20. Well, physically you can, but you're almost guaranteed to break your build when doing so.

OK, so let's walk through an example, in which we create a new repository and put some files in it. You have to be able to run the svnadmin command (which you should be able to do, unless you have a paranoid sysadmin). So pick a temporary directory, and execute the following commands (I'm running Linux; if you're running Windows the commands will be the same, but you'll need to put a Windows-specific path in the REPO variable):

svnadmin create temp.repo  REPO="file://`pwd`/temp.repo"  svn co $REPO temp  

This creates a new (empty) repository, and checks out a working copy of it. The second line needs some explanation: it simply creates the repository URL from the current directory. In my workspace directory, the URL looks like this:


OK, now that you've got a working copy, let's create the sample directory structure and some files:

cd temp  svn mkdir trunk  svn mkdir branches  svn mkdir tags  svn commit -m "standard repo structure"    pushd trunk  svn mkdir 10  svn mkdir 20  svn mkdir 30  svn mkdir 40  svn commit -m "example sub-project structure"    echo "this doesn't change" > 10/dontchange.txt  svn add 10/dontchange.txt  echo "this does change" > 20/change.txt  svn add 20/change.txt  svn status  svn commit -m "example files"  popd  

At this point we have the sample directories and two files in them. Here's the output from find, excluding subversion's hidden directories:

temp, 531> find . | grep -v svn  .  ./tags  ./trunk  ./trunk/10  ./trunk/10/dontchange.txt  ./trunk/30  ./trunk/20  ./trunk/20/change.txt  ./trunk/40  ./branches  

Next step is to create the sandbox directory, and make copies of the two directories that are going to be in it:

svn mkdir branches/sandbox  pushd branches/sandbox  svn copy ${REPO}/trunk/20 .  svn copy ${REPO}/trunk/40 .  svn commit -m "make development branch"  popd  

This is the important part: I creating the branch and copies in my working directory, as a copy from the repository. Normally, you just copy trunk into a child of branches, using svn copy with two repository arguments. That doesn't work here, because we want only two children of trunk.

After doing this, my working copy looks like this:

temp, 539> find . | grep -v svn  .  ./tags  ./trunk  ./trunk/10  ./trunk/10/dontchange.txt  ./trunk/30  ./trunk/20  ./trunk/20/change.txt  ./trunk/40  ./branches  ./branches/sandbox  ./branches/sandbox/20  ./branches/sandbox/20/change.txt  ./branches/sandbox/40  

At this point, you'd normally check out the development branch into a new working directory and work there. So I'll do that (after a cd back to my Workspace directory):

svn co ${REPO}/branches/sandbox sandbox  cd sandbox  

And now make some changes:

vi 20/change.txt  svn commit -m "changed on branch"  

OK, now it's time to merge back to the trunk. So go back to the workspace, and check out just the trunk:

svn co ${REPO}/trunk trunk  cd trunk  

And merge from the sandbox. The merge process is described in the Subversion docs:

svn merge -r 4:5 ${REPO}/branches/sandbox  svn status  

That last command should show you that only the file 20/change.txt was affected by the merge. Since you didn't copy the 10 or 30 directories into the branch, they won't be touched by the merge.


What you want to do is create a copy of "20" somewhere in your svn tree, which you can merge back and forth with. A common structure is

repo  ---> trunk      ---> 10       ---> 20      ---> 30  ---> branches      ---> sandboxes          ---> develop <branch of 20>  ---> tags  

When you want to update "develop", you either create a new branch of "20" under sandboxes or perform a merge from 20 to develop. When you want the changes in "develop" back in your trunk you merge the other way. Your developers should check out a copy of "develop" (or create their own branches based on "develop")


afaik you can't do it with the repository structure you currently have.

I suggest you restructure your repository, so 10 & 20, 40 & the other code related assets are moved under a new 1st level folder. This way you avoid this situation, and simplify being able to grab just the code related assets.


Ideally then you should branch at a lower level. i.e. branch 20 not trunk. That way you're only branching the content that should be branched. i.e. that you want branched.


You can achieve that by making only the source code subdirectory of your working copy point to its branch.

svn cp http://example.com/svnrepo/trunk/source_code http://example.com/svnrepo/branches/development/source_code    cd ./source_code  svn sw http://example.com/svnrepo/branches/development/source_code  

Do the changes, commit. Then, let's merge to the trunk:

svn sw http://example.com/svnrepo/trunk/source_code  cd ..  svn merge -r [start_rev]:HEAD http://example.com/svnrepo/branches/development/source_code ./source_code  

Review to make sure all's fine:

svn diff | less  

And then commit. Done.


We do something like this:

-repo: Assemblies  --SomeAssembly  ---Current  ---v1.0  ---v1.1  -repo: Source  --trunk  ---Code  ---Assemblies (external from Assemblies repo)  --branches  ---v1.0  ----Code  ----Assemblies (external from Assemblies repo)  --Documents  

In this example, the 3rd party assemblies have their own repository. This way you aren't maintaining different versions in each branch and trunk. As a side note, the latest version of any assembly is duplicated in the "Current" folder for each assembly. This allows the assembly to be updated without having to update references in all your projects. This may not be an issue in your domain, but it was a big pain in ours.

Also note that the documents are at the same level in the hierarchy as trunk and the branches. This way those files don't get duplicated. If this is not an option, those can be externaled as well, which would allow them to be present in the trunk and branches without being separately source controlled.


The way you structure your project, along with the docs dir restrictions, doesn't fit with SVN's model out of the box.

Some ideas:

  • Move the docs dir outside trunk, and add it as an svn:external
  • Move the docs dir outside trunk, and have a build script combine trunk and the docs dir
  • Merge using a script (instead of a direct svn merge), and have the script enforce the rules


From your comment:

We want to prevent modification of documents in 10 and 30. They should be modified only in the trunk.

Have you considered using svn:externals in the develop branch for 10 and 30? Relative referencing from root using ^/ would probably be a good approach.

So whilst 10, 20, 30 and 40 would be accessible on the branch, 10 and 30 are still referenced from trunk. You can then define your authorization needs as required.

..-> trunk
....-> 10
....-> 20
....-> 30
....-> 40
..-> branches
....-> develop
......-> 10 (lives on trunk, svn:externals ^/trunk/10)
......-> 20 (lives on branch, merge to trunk)
......-> 30 (lives on trunk, svn:externals ^/trunk/30)
......-> 40 (lives on branch, merge to trunk)

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »