Subversion branches

Community Forums/General Help/Subversion branches

GfK(Posted 2011) [#1]
I have a subversion repository for my current project, and I wanted to create a slightly modified 'trial' version with cut-down resources as a demo (rather than using SoftwarePassport or whatever, since its next to useless).

I'm not sure if I need to create a branch in subversion. I heard that the further you go with a branch, the more likely it will be that there'll be conflicts when you merge it back into the trunk. This doesn't concern me a lot as I'm fairly sure the branch will never be merged back anyway - it will just reach a point where it stops.

Can I work on the branch copy and the trunk copy at the same time?

I really don't know what I'm doing with this stuff and I don't know if I'd be better off just cloning the entire repository to a new location, and checking it all out again to modify for a trial version.

Any thoughts? (and don't tell me to use git, because I'm using subversion and asking specifically about SVN/TortoiseSVN).


Htbaa(Posted 2011) [#2]
You can use a Subversion branch for that perfectly if you're not going to merge it back to trunk later on.

It's been 2 years since I last used Subversion on a project but branching and merging was hell. And not always when the trunk and branch were much off.

You could consider a branch as a fork of your project, if that makes it a bit more clear. With TortoiseSVN you can simply right-click and choose to make a branch/tag (which in Subversion are the same things).


Perturbatio(Posted 2011) [#3]
Yes, you can create a branch of your main project and create that as a seperate distribution.

Any changes you make to the trunk can be merged up once you know you want them in the trial and if you've implemented any overrides in your branch, they will be retained unless they are superceded by the trunk.

We use subversion extensively at my work (Web Development), my experience of merging is that it's actually really easy to do right, it's just that it's also really easy to do wrong.

So long as you use tortoise to perform all delete/rename/move operations then the only thing you need to worry about is resolving merge conflicts (when code overlaps from both branches), winmerge helps greatly with this.

An example of how you might implement the repository could be:

Core - Trunk
     - Branches
Vars
     - Base Distribution
          - Trunk
          - Branches
     - Full Version
          - Trunk
          - Branches
     - Demo Version
          - Trunk
          - Branches


To set this up from an existing repo:

You would create all the core code for your app in one area (Core - Trunk), and all the variable items in the vars.

Vars - Base Distribution would be branched from the core initially and then NEVER merged down again.

Once done, you remove all variable items from the core.

Then you remove all things core from the base vars.

Then you can branch the base distro to both the full and demo version sections.

Once it's set up, all you do is edit core code in the core area, edit global items that CAN vary in the base distribution (and merge up once ready), and develop distribution specific overrides in the specific distros.

You never merge down from a version dtribution, if something needs to go in both items, test it in the base distribution then merge up.


It can mess with your head if you have a lot of distributions, but not nearly as much as not having this set up.

Last edited 2011


Perturbatio(Posted 2011) [#4]
Actually, for your purposes, you could probably eliminate core and just have everything in base.


GfK(Posted 2011) [#5]
Thanks but I'm still pretty confused. I think my biggest issue is that my repository doesn't have branches/trunk/tags folders and I didn't find out til about half an hour ago that this is the 'standard structure'.

So I'm probably buggered from the start, really.


Htbaa(Posted 2011) [#6]
Well, you can still restructure your repository. Just copy/move everything you have now to a trunk folder, then create a branch folder and branch your trunk into a folder in the branch folder (if that makes sense).


Perturbatio(Posted 2011) [#7]
Yep, just create the structure, svnmove the files into the correct place, then commit, then branch and commit again.

As another tip, I usually have two folders checked out, one is the trunk, and the other is called working, which is simply a pointer to my working copy. I just switch the working copy between branches when I need to work on something else.