Which naming conventions do you use for SVN Branches and Tags?

Question

Our company is creating a naming convention for SVN branches and tags, and I'm not confortable with the idea of using only date or build number on branches/tag names.

I think we need names that brings a greater definition about what this path represents, what effort is being done, etc.

What do you think / use?

Answer 1

All of our developer tasks go into a bug tracking system. This bug tracking system has IDs associated with each task.

So for the branch name of any task, we use:

ticketId_TicketSubject

When a branch contains multiple ticketIds we just combine them into the branch name:

ticketId1_ticketId2_Description

That way if you're in a ticket and you want to know which branch to build, you can easily look it up. Likewise if you want to find the ticket with your branch build, you can easily find it too.

For tags, we tag it by the version number itself.

As for the location of each branch. We have a top level hierarchy like this:

/branches

/tags

/trunk

Then all of our products/projects go under each of those inside their own subfolders.

/trunk/project1/

/branches/project1/TicketId_Description

Answer 2

For a feature branch, name it after what is being done. For example, I moved our ORM from LINQ to SQL to NHibernate and created a branch called "NHibernate". Once you have completed the branch and merged it back into the trunk you can delete the branch to save naming conflicts in the future. If you really need to retrieve the branch you can, you just have to delve back into the history and restore it.

If you have story/quote/job numbers that are relevant to a branch, I would append it to the name of the branch eg. "NHibernate_429" so you can easily reference it against your tracking system. However, I would always go with the English first as that's what people are more realistically going to refer to it by when it is in development.

For things like tags it's hard to say what you want to do as it depends on what it is you are tagging. If you are tagging releases then I would use "Release X.X.X.X" or something simple like that. You really aren't going to care what the date or build number was when you are looking back for a specific release as an example.

Answer 3

What we use (mostly following the accepted convention):

projectName
 |
 --trunk
 |
 --tags
 |
 --branches

Under trunk we have the main trunk.

Under tags we tag every release (both internal, testing releases and customer releases). There we just use the version number as the tag name.

Under branches we have one branch for every major version we released (in our case the result of one XP iteration). Those are named like the major version ("v5.03", "v6.04"). Additionally, we have internal branches for major changes or special versions. There naming is free-form, and the name is supposed to tell people what the branch represents. Expamples would be "workaround_customerA", "module_x_reorg" etc.

Answer 4

We give our branches a ".X" version, where the tags have a number.

For example, the branch would be Foo-1.2.3.X, and the tags would be Foo-1.2.3.1, Foo-1.2.3.2, etc.

We also have a special tag, Foo-1.2.3.0, which is made as soon as the branch is created from trunk, before any changes. That's so we can diff branches and tags to the initial state at any time (since in a couple days, trunk is likely to be different). This practice has made merges a little easier, and it makes figuring out what code changed in the branch a whole lot easier.

Answer 5

I always prefix the tags (and usually branches too) with the date in YYYYMMDD format, followed by a description of the purpose of the tag or branch.

e.g., 20090326_Release_v6.5 or 20090326_Post_Production_Update

This is under the standard trunk/tags/branches hierarchy of course.

The date prefix ensures that they all the tags or branches are displayed in creation order, which is much more useful then just being sorted by description if your scanning through a big folder of tags. You see the timeline of when and why they were created (like mini log messages).

Answer 6

Well, branching is pretty much open, since there's several different kinds of branches, the naming of them can be very different.

It's worth remembering what source control gives you. Tag names are not just "v1.4", it's "/CashCowProject/tags/v1.4". Naming a tag "/CashCowProject/tags/CashCowProject-v1.4" is a little redundant, what else would it be?

Revision control also gives you full access to dates and times that tags were created. Revision control also gives you commit messages which you should be making use of, particularly the first line.

Given all this information, it's not difficult to pull together a simple view giving you all the information you need, coming from consistent and appropriate sources, such as:

CashCowProject
    v1.4 - 26 March 2009     :  With Added whizzbang (more)
    v1.3 - 13 February 2009  :  Best graphics!       (more)
    v1.2 - 01 January 2009   :  Upgraded security    (more)

The only thing that the tag name is really useful for here is the version number. If you're trying to put all the information into a tag name, it's a little wordy and I bet it won't look as good.