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.
program_maintrunkcorefile.php program_maintags1.0corefile.php program_maintags1.1corefile.php program_maintags1.2corefile.php
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.
program_modtrunkcorefile.php program_modtrunkadditionlalfile.php program_modtags1.0corefile.php program_modtags1.0additionalfile.php program_modtags1.1corefile.php program_modtags1.1additionalfile.php program_modtags1.2corefile.php program_modtags1.2additionalfile.php
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.
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
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
(in this picture trunk dir is external from independent repo)
Your current flat structure of program_mod
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
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!)