Trunk and Branch Naming Conventions

CactusJuice · Post by **CactusJuice** » Wed Jun 14, 2006 11:22 am

I've read some of the posts in this forum but I still have a question on best-practices for naming trunks and branches. Do you actually use "trunk" and "branch" as names? I know this is probably a dumb question. Sorry.

For a web site Visual Studio project named "StaffWeb" that has a seperate "engine" assembly, how do I name my Vault folders?

$/trunk
$/trunk/Engine

OR

$StaffWeb
$/StaffWeb/SwEngine

I also see folder names such as /src and /docs used a lot in examples. But again, is it merely psuedo code being used in posts like this:
http://support.sourcegear.com/viewtopic.php?t=304
Visual Studio does not create an src directory but JBuilder does. Thanks.

lbauer · Post by **lbauer** » Wed Jun 14, 2006 12:04 pm

I know this is probably a dumb question.

There are no dumb questions. Only dumb answers.

I don't know that there's universal "best practice" for naming items in the Vault tree. (Other users feel free to chime in here). Development teams create naming conventions that suit their individual needs.

Usually, the folders in Vault have the same names and structure as the project folders on your local drive.

We use the terms "trunk" and "branch" generically (using the tree analogy) to describe a folder and a copy (branch) of that folder. A folder may also have subfolders or child folders.

"Src" and "docs" are also used generically to describe structures where the source code and documentation are in different folders.

If you're using IDE integration, Visual Studio usually determines folder names and project structure in Vault and in the working directories on the client machine.

GregM · Post by **GregM** » Wed Jun 14, 2006 12:33 pm

Our trunk is at $/Code/Trunk. Our branches go into either $/Code/Branches/Releases or $/Code/Branches/Experimental

We also have $/Components for third-party components for which we have source and to which we make local modifications.

Saturn · Post by **Saturn** » Wed Jul 05, 2006 10:06 pm

We branch for versions, so our "trunk" is simply the project name. Branches are "Project Name YYYY.QQ", since we release every quarter. Similarly, we sometimes branch for one-off changes for customers, so that branch would be "Project Name - Customer".

If the branches get to be too cumbersome, we may move them into their own folder in the future, in which case we'd have "Project Name" and "Project Name Branches"

Tonyb · Post by **Tonyb** » Mon Jul 10, 2006 5:54 pm

Here is the way that we have been using it and it has been working well

Code: Select all

$
 +Project 1
   + trunk
   |  + src

   |  + docs
   |  + ...
   + branches

Tonyb · Post by **Tonyb** » Mon Jul 10, 2006 6:02 pm

Here is the way that we have been using it and it has been working well

Code: Select all

$
 +Solution 1
   + trunk
   |  + src
   |  |  +ProjectA
   |  |  +ProjectB
   |  |  +ProjectC
   |  + docs
   |  + ...
   + branches 
   |  + Version 0.1
   |  |  + src
   |  |  |  +ProjectA
   |  |  |  +ProjectB
   |  |  |  +ProjectC
   |  |  + docs
   |  |  + ...
   |  + Version 0.2
   |  + Version 0.3
 +Solution 2
 +Solution 3

the "trunk" (we have a folder literally called trunk) has the freshest code. At each release we create a branch under the branch folder with the version number as the name. Any bug fixes that go into a released version can then be merged back into the trunk. I wish I could say that we always have a fully updated docs folder but often we don't have any at all, in which case the "src" folder could be eliminated if you wanted to reduce the depth.

Like someone said before it doesn’t really matter how you do it, as long as you find a method that works for you.

Tonyb · Post by **Tonyb** » Mon Jul 10, 2006 6:28 pm

I forgot this in my last post.

If you haven't read Eric Sink's "Source Control HOWTO" it is a great read.

http://www.ericsink.com/scm/source_control.html

The chapter on branches is where I got my ideas from.