Organizing SVN Branches with TortoiseSVN

Posted on


How do I organize branches in the SVN system? I’m using TortoiseSVN since I use Windows.

Currently I have this kind of file/directory structure. I’m somewhat getting used to managing numbered versions although I don’t see the whole picture of how this management system works.


Now I’d like to make another program based on it. It’s going to be a separate program but it uses the main program as its base. If the main program is updated, the extended modified program also updates with the corresponding version number.


When I right click on the trunk folder of the main program and choose TortoiseSVN -> Branch/Tag and specify the path to /program_main/branches/program_mod/1.0, it tries to upload the files to the branch folder under the main project directory on the public server. The main project directory is public and visible to everyone, I’d like not to upload the modified(branch) version on that server.

In this case, how am I supposed to do? I guess this must be a very simple operation by using the merge command or something.

Thanks for your advice and information.


Some notes

  • Repository tree organisation, functions of different nodes inside Subversion repository is just a matter of conventions, “best practices” and habits and strictly related to working style, not used client-side tools for accessing repository. I.e “using TortoiseSVN” is irrelevant information in the light of your task (same /found and satisfied/ technique will be|may be used with any svn-client on any OS)

  • Your business-task have to be defined (better and more correct, from my POV) not as “how to use branches”, but as “how store and link related projects in case of Subversion SCM-backend”, where using branches (or any other hierarchy inside repo) is only one and not best (IMNSHO) choice


Subversion externals

Any part of SVN-repository, which have to be cloned into any another place (and relation between clone and original saved in future) may be utilized over svn:external trick. This way we’ll add to repository “virtual tree”, which exist somewhere-somehow, but can appear in checkout’ed WC as part of our repository

Repo-browser with externals

(in this picture trunk dir is external from independent repo)

Your current flat structure of program_mod

dir /B



imposes a restriction on the version of Subversion (on both – client and server – side), because file-externals was added only in Subversion 1.6, for directory-externals

dir /B /S




earlier versions can be used also. The latter option also has a one more slight advantage in terms of controllability in the case of expanding of core-project into multi-file project: in case of file-based externals you’ll have to add every new file by hand, directory externals will include all files inside external object

Branches and merges

From the other side you can use branch-merge method for maintaining program_mod

Branch source of core (/trunk) into some, any separate node inside repository (branches/program_mod, f.e). Add additionalfile.php into this branch. After each trunk-commit /better/ or before program_mod release /worse/ merge trunk into program_mod branch (or svn copy corefile in post-commit hook – TBT!)

Leave a Reply

Your email address will not be published. Required fields are marked *