Can anybody diagram the concept of SVN Branching?

Question

I have read Branching / Tagging twice now. I cannot seem to grasp this idea. I want to have a a good understanding of branching, to prevent errors to the main line.

Since I am a visual learner, can anybody diagram the concept of SVN Branching? Or is it possible in plain English to describes the concepts?

lets say i have 3 developers on a team and one repo "out_app" how would dev1 create a branch and merge back to the main line? how would this effect dev 2 and 3?

detail the steps, menue items clicked, settings entered... for the above questions.

Answer 1

You can start reading the SVN readbook on Branching and merging

It is based on cheap copies:

Subversion's repository has a special design.
When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're a Unix user, this is the same concept as a hard-link.
As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard-link concept where it can. It only duplicates data when it is necessary to disambiguate different versions of objects.

Answer 2

See A Visual Guide to Version Control. Great article.

Answer 3

(In my opinion) the best modelling and explanation of good revision control branching is in The Flow of Change by Laura Wingerd, a conference presentation made about Perforce. It describes the tofu scale, where changes flow from "soft" branches (untested, unstable) up to "hard" branches (released, well-tested) as revisions become more solid.

It provides a very understandable metaphor for managing revisions and branches; I cannot recommend highly enough that everyone reads through this presentation and absorbs its ideas.