What is trunk, branch and tag in Subversion?

Question

Possible Duplicate:
What do “branch”, “tag” and “trunk” really mean?

What is a trunk, branch and tag in Subversion and what are the best practices to use them?

What tools can I use for Subversion in Visual Studio 2008?

Solution 1

The trunk is the main line of development in a SVN repository.

A branch is a side-line of development created to make larger, experimental or disrupting work without annoying users of the trunk version. Also, branches can be used to create development lines for multiple versions of the same product, like having a place to backport bugfixes into a stable release.

Finally, tags are markers to highlight notable revisions in the history of the repository, usually things like "this was released as 1.0".

See the HTML version of "Version Control with Subversion", especially Chapter 4: Branching and Merging or buy it in paper (e.g. from amazon) for an in-depth discussion of the technical details.

As others (e.g. Peter Neubauer below) the underlying implementation as /tags /branches and /trunk directories is only conventional and not in any way enforced by the tools. Violating these conventions leads to confusion all around, as this breaks habits and expectations of others accessing the repository. Special care must be taken to avoid committing new changes into tags, which should be frozen.

---

I use TortoiseSVN but no Visual Studio integration. I keep the "Check for modifications" dialog open on the second monitor the whole time, so I can track which files I have touched. But see the "Best SVN Tools" question, for more recommendations.

Solution 2

The "trunk", "branches", and "tags" directories are conventions in Subversion. Subversion does not require you to have these directories nor assign special meaning to them. However, this convention is very common and, unless you have a really good reason, you should follow the convention. The book links that other readers have given describe the convention and how to use it.

Solution 3

The answer by David Schmitt sums things up very well, but I think it is important to note that, to SVN, the terms 'branch', 'tag', and 'trunk' don't mean anything. These terms are purely semantic and only affect the way we, as users of the system, treat those directories. One could easily name them 'main', 'test', and 'releases.'; As long as everyone using the system understands how to use each section properly, it really doesn't matter what they're called.

Solution 4

A great place to start learning about Subversion is http://svnbook.red-bean.com/.

As far as Visual Studio tools are concerned, I like AnkhSVN, but I haven't tried the VisualSVN plugin yet.

VisualSVN does rely on TortoiseSVN, but TortoiseSVN is also a nice complement to Ankh IMHO.

Solution 5

To use Subversion in Visual Studio 2008, install TortoiseSVN and AnkhSVN.

TortoiseSVN is a really easy to use Revision control / version control / source control software for Windows. Since it's not an integration for a specific IDE you can use it with whatever development tools you like. TortoiseSVN is free to use. You don't need to get a loan or pay a full years salary to use it.

AnkhSVN is a Subversion SourceControl Provider for Visual Studio. The software allows you to perform the most common version control operations directly from inside the Microsoft Visual Studio IDE. With AnkhSVN you no longer need to leave your IDE to perform tasks like viewing the status of your source code, updating your Subversion working copy and committing changes. You can even browse your repository and you can plug-in your favorite diff tool.

View more solutions

Comments

[Jørn Schou-Rode]

... combined with: stackoverflow.com/questions/453481/…

[Peter Mortensen]

stackoverflow.com/questions/16142: "What do “branch”, “tag” and “trunk” really mean?".

[Rich]

Where did you get the notion that Ankh relies on Tortoise? Afaik that is not the case, only for VisualSVN.

[Quintin Robinson]

I don't know where I got that impression but I did think it was required. In either case I think it's nice to have Tortoise as a compliment, but thanks for making me look into it!

[Hemanshu Bhojak]

I have ankh installed without tortoise.

[Hemanshu Bhojak]

Yeah it's true. Subversion does not restrict you with such naming conventions. Its just a recommendation. Thanks for your answer, it helped.

[Hemanshu Bhojak]

I guess ankh is the best for me. I can do almost everything from right within visual studio. Thanks!!!

[rondoagogo]

Fundamentally, the answers provided by @Peter-Neubauer and KOGI (below) are arguably closer to true. As they've noted, David Schmitt's answer here simply explains the convention for how those directories are typically used -- but there's in fact nothing at all magical about those folders per se, or how they're utilized. Thanks to David Schmitt, but +1's to the others for delineating that crucial difference.

[David Schmitt]

"Arguably" the OP asked about the best practices, not the (IMHO pretty weak) implementation of those.

[Admin]

So does, for example, subversion know the concept of "revision"? Is every single commit just a snapshot of the entire repository? How do you know if someone wipes out 50% of the release tags with one of their check-ins by mistake? Wouldn't you constantly have to watch for that?

[KOGI]

@ebyrob it's been a while since I've used SVN, but IIRC, SVN tracks diffs between revisions, NOT entire snapshots. Regardless, and in any VCS, there is the potential to "delete" release tags (or any other file/folder for that matter) that you may not want to delete. I put "delete" in quotes, though, because it's never really truly gone, it's always in the history and can always be restored (except for maybe 1 very fringe case in GIT, I think)

[ϹοδεMεδιϲ]

My one penny worth to add here; only trouble I have had so far with a repository that violated this convention was when I tried importing the repo into git, using svn-git. It just doesn't like it if the branches are inappropriately formed. So the summary is, when it comes to tools like svn-git (which you might have to use in the future), they will be tuned to work against a repo that follows these conventions, and might refuse to function correctly/usefully otherwise.