Questions about Branches, labels and snapshots

christian · Post by **christian** » Fri Oct 22, 2004 9:56 am

dsellers wrote:Thank you for clearing that up for me. In my attempts to add another $folder I dicovered that you could rename the $root folder. Any reasons why one would or would not change the name of the root folder?

Not sure, I've never tried to change it before!

Post by **jclausius** » Fri Oct 22, 2004 12:13 pm

dsellers:

Did you create a change set item to rename $ or did you actually "commit" a change? The Vault server will not allow a rename of $ to be committed.

mlippert · Post by **mlippert** » Fri Oct 22, 2004 4:18 pm

Just thought this picture might help. It represents my conception of how to setup the folders for development/releases/long term development, and what and when branching and merging would be done.

$/trunk is your mainlne. It is where ongoing development of the next release takes place (is checked in).

With Vault it is likely that you will be doing regular builds, and labeling $/trunk for each of them.

At code freeze time, label $/trunk and branch it to a folder in $/Releases named for the release, say ver1.0.

Now development in the trunk continues immediately on the next planned version called 1.1. Code changes to fix bugs deemed critical for the frozen release are checked into the release branch, and assuming that all fixex are desired in the trunk, merged to the trunk.

Meantime several developers need to start work on a feature that will not be in the next release, possibly not in the next several releases.

A branch is created for that feature, in my diagram it is named for the version it is expected to be included in (ver2.0), however it might also be named after the feature being implemented.

Changes in the trunk are merged to the task branch on a regular basis, in order to ease the integration compared to the task of waiting until the feature is complete.

Meantime 2 other releases ver1.1 and ver1.2 reach code freeze and are treated exactly as ver1.0 was.

When the next release is to contain the feature that was being developed, that branch is merged back to the trunk and is not used any longer, as future development is done from the trunk.

The folder structure in the repository at the end of the attached diagram is:

$
$/trunk
$/trunk/module1...
$/trunk/module2...
$/trunk/module3...

$/Release
$/Release/ver1.0/module1...
$/Release/ver1.0/module2...
$/Release/ver1.0/module3...

$/Release/ver1.1/module1...
$/Release/ver1.1/module2...
$/Release/ver1.1/module3...

$/Release/ver1.2/module1...
$/Release/ver1.2/module2...
$/Release/ver1.2/module3...

$/Release/ver2.0/module1...
$/Release/ver2.0/module2...
$/Release/ver2.0/module3...

$/TaskBranches
$/TaskBranches/ver2.0/module1...
$/TaskBranches/ver2.0/module2...
$/TaskBranches/ver2.0/module3...

I don't know if this will help anyone, but I thought the visual might.

Mike

christian · Post by **christian** » Sun Oct 24, 2004 7:11 am

Sounds as though Mike and myself are reading the same articles / books :-)

mlippert · Post by **mlippert** » Mon Oct 25, 2004 9:36 am

Well I've ordered the book you mentioned Christian, but I haven't gotten it yet.

I have incorporated what I got from your comments here with the various things I've been reading elsewhere, all of which make sense to me. It's been especially helpful when there are discussions of other ways to organize source control and what their pros and cons are.

Mike