Questions about Branches, labels and snapshots

[drteeth]

Hi this is more a question of best practices i guess.

I'm wondering what is the best way to maintain a source tree. Supposing there is an active branch of a tree, and several stable releases. using labels would seem ideal, especially working with vs.net as i could label a branch once it becomes stable and continue working on the next iteration. my question is what do i do when i need to provide a bug fix say to a stable version? using labels i assume i would get that label and make my changes, but how do i check in my updates to my stable version as a new label and not as changes to my development branch.

the most obvious way i see is to use branching, but there are complications there with shared folders and how to organize the branches in vault. Add vs.net to the mix and things can get ugly.

I'd like to know how others tackle this situation.

[mlippert]

I have the same question phrased slightly differently.
I've seen the post that recommends that under the root $ of a repository that you have the folders "branches", "trunk" and "snapshots".

Now suppose the product this respository is for is Widget, and it is made up of 3 separate modules "client", "engine" and "server".

I was thinking that I'd have 3 folders under trunk, 1 for each module, so:
$/trunk/client
$/trunk/engine
$/trunk/server

Now suppose we release version 1.0 of Widget.

Should I label $/trunk "Widget 1.0" recursively (I haven't actually seen how Vault labeling and branching works yet, so I'm speaking as a transplanted VSS user)

Can I later create a branch from that label?

Should I create a branch instead of a label? In which case I'm guessing (and please let me know if this is a bad way to do this) that I'd create a new folder in branches "Widget 1.0" and branch the 3 trunk projects into there?
$/branches/Widget 1.0/client
$/branches/Widget 1.0/engine
$/branches/Widget 1.0/server

Now I know that there is a planned 1.1 and 1.2 release and eventually a 2.0 release.

I expect the development of 1.1 and 1.2 to be serial while development of 2.0 is happening in parallel with those 2.

So how would you propose that the source control be handled?

I can see having 2.0 development proceeding in the trunk while 1.1 development goes on in the 1.0 branch? And to keep the 1.1 modifications in the trunk someone will need to merge all the 1.1 changes into the trunk (say weekly so it doesn't get out of hand) and I'm expecting Vault to make this process easier.

Now when 1.1 is finished, should I do a recursive label on the Widget 1.0 branch "Widget 1.1", and/or create a new "Widget 1.1" branch from the Widget 1.0 projects:

$/branches/Widget 1.1/client
$/branches/Widget 1.1/engine
$/branches/Widget 1.1/server

And then start work on Widget 1.2 in that branch?

This feels a little off as a process, but I haven't seen source control handling simultaneous development before, and this is exactly why we're looking to replace VSS, so any advice is very welcome.

Thanks,
Mike

ps How and why would I use a snapshot?

[mlippert]

Hmm, I seem to be replying to myself, but I've been reading various other messages here, as well as the article <a href="http://www.perforce.com/perforce/bestpr ... High-level Best Practices in Software Configuration Management</a> from Perforce, and have some new thoughts on this.

I'm thinking that for my scenario above what I might want is 2 subfolders in branches, one "releases" and the other "development" or some other name that implies an unstable under development code branch.

Then Widget 1.0 development is done in the trunk and labeled in the trunk. If there are critical bugs that need to be fixed in 1.0 a branch is created for those fixes:

$/branches/releases/Widget 1.0

or perhaps a branch should always be created when the label is created on the trunk, to prepare for the possibility of changes.

At this point development of Widget 1.1 continues in the trunk, while another branch is created for simultaneous development of Widget 2.0:

$/branches/development/Widget 2.0

When Widget 1.1 is done (development is frozen) the trunk is labeled Widget 1.1 (and a branch is created for critical fixes?). Development on Widget 1.2 continues in the trunk while development of Widget 2.0 continues in the development branch.

Changes on the trunk are merged into the Widget 2.0 branch on a regular basis.

When Widget 1.2 is done, the trunk is labeled Widget 1.2 (and a branch is created for critical fixes?).

At this point the Widget 2.0 no more releases prior to 2.0 are scheduled so the Widget 2.0 branch can be merged back into the trunk, and Widget 2.0 develoment will proceed in the trunk and the branch is basically done.

<i>Is this better than what I described previously?</i>

What happens if management decides that we need a 1.3 release? It will probably need to be based on the final 1.2 source found in the Widget 1.2 branch and that is somewhat counter to how this was supposed to be working.

Mike

[mlippert]

I just found this article and although I haven't had a chance to read it yet, I think it is relevant and so, I'm adding it to this thread.
http://www.seapine.com/pub/papers/SCMBr ... Models.pdf

[ericsink]

ps How and why would I use a snapshot?

I don't recommend using snapshots. They were left in the product only for legacy reasons. Branches or labels are better.

[ericsink]

I have the same question phrased slightly differently.
I've seen the post that recommends that under the root $ of a repository that you have the folders "branches", "trunk" and "snapshots".

Now suppose the product this respository is for is Widget, and it is made up of 3 separate modules "client", "engine" and "server".

I was thinking that I'd have 3 folders under trunk, 1 for each module, so:
$/trunk/client
$/trunk/engine
$/trunk/server

Now suppose we release version 1.0 of Widget.

Should I label $/trunk "Widget 1.0" recursively (I haven't actually seen how Vault labeling and branching works yet, so I'm speaking as a transplanted VSS user)

Can I later create a branch from that label?

Should I create a branch instead of a label? In which case I'm guessing (and please let me know if this is a bad way to do this) that I'd create a new folder in branches "Widget 1.0" and branch the 3 trunk projects into there?
$/branches/Widget 1.0/client
$/branches/Widget 1.0/engine
$/branches/Widget 1.0/server

Now I know that there is a planned 1.1 and 1.2 release and eventually a 2.0 release.

I expect the development of 1.1 and 1.2 to be serial while development of 2.0 is happening in parallel with those 2.

So how would you propose that the source control be handled?

I can see having 2.0 development proceeding in the trunk while 1.1 development goes on in the 1.0 branch? And to keep the 1.1 modifications in the trunk someone will need to merge all the 1.1 changes into the trunk (say weekly so it doesn't get out of hand) and I'm expecting Vault to make this process easier.

Now when 1.1 is finished, should I do a recursive label on the Widget 1.0 branch "Widget 1.1", and/or create a new "Widget 1.1" branch from the Widget 1.0 projects:

$/branches/Widget 1.1/client
$/branches/Widget 1.1/engine
$/branches/Widget 1.1/server

And then start work on Widget 1.2 in that branch?

This feels a little off as a process, but I haven't seen source control handling simultaneous development before, and this is exactly why we're looking to replace VSS, so any advice is very welcome.

Thanks,
Mike

ps How and why would I use a snapshot?

Two good rules of thumb:

1. Label often.

2. Branch only when needed.

Labels are cheap and lightweight. You can apply a label as often as you want. They are a handy way of remember a certain situation so you can easily get back to it.

We have an automated build script which produces daily (and sometimes more) builds. That script applies a label every time it does a build. There are hundreds and hundreds of these labels in our repository, and that's okay. If we want to go back and retrieve the source code for build 2433, we can do it easily.

Branches are more problematic. As soon as you branch, you incur the future responsibility to merge. Therefore, I recommend that people never branch until the moment when you actually do need to have two distinct versions being developed at the same time.

In your case, I would branch the entire trunk folder, not the individual folders underneath it. There's no harm in branching to high up the hierarchy.

Does this help?

[Don Hiatt]

My problem is similar but in the context of building applications in VS IDE.

Branching appears to be a bad way of working on ver 1.1 or 2.0 of a codebase because VS also appears to store source code control location information in the project files.

I'm getting the impression that you must work from within VS IDE to perform all SCC operations. However, I don't see menu choices to label, branch & pin projects and solutions.

How now brown cow? I'm completely lost. I think of SCC in terms of here is a directory of files. Now let me use VS to perform edit/debug/author operations against this set of source files. I could use any number of tools/methods to copy/backup/control my source files.

I have four solutions, with one project in each, of a system. I have just deployed to production for the customer. Now I need to perform some code review/changes and add some features for the next service pack.

Can someone help me understand how best to do this?

[christian]

Hmm, I seem to be replying to myself, but I've been reading various other messages here, as well as the article <a href="http://www.perforce.com/perforce/bestpr ... High-level Best Practices in Software Configuration Management</a> from Perforce, and have some new thoughts on this.

Hi Mike,
I haven't read the articles at the end of the links but what you've just described sounds identical to the best practices recommended in a book called "Software Configuration Management Patterns" http://www.scmpatterns.com, so I think what you're suggesting (to yourself!) is pretty sound.

It sounds as though you're describing the following patterns:
Mainline (this is your trunk)
Active Development and Task Branch (make sure that the Mainline / trunk remains stable / useable. One technique is to create a branch to ring-fence disruptive changes or in your case features due in a future release. Work on the trunk and on the task branch can then be performed in parallel)
Release Line (eg a branch to support Widget 1 hotfixes)

Christian

[mlippert]

Hi Mike,
I haven't read the articles at the end of the links but what you've just described sounds identical to the best practices recommended in a book called "Software Configuration Management Patterns" http://www.scmpatterns.com, so I think what you're suggesting (to yourself!) is pretty sound.

Thanks Christian, that was exactly the type of feedback I was hoping for, and it's nice to know that I am on the right track.

Thanks for the link to that book also, I'm going to go check it out.

(Eric, I was trying to figure out how to say that your response answered half of my questions, but didn't address the ones that Christian just did. I was doing more reading to figure out what to ask, and then I saw Christian's post, so thanks, between the 2 of you I'm getting a sense of the "right" way to get started.)

Mike

[christian]

No problem Mike. Its nice to think that everyone can help each other out from time-to-time.

[dsellers]

So basically if you are doing your releases by task and stuff your Vault trunk ($) gets to have a LOT of folders in it. Just thinking about all of this, I have the picture:

$Trunk
----Releases
--------v1.0
------------1.1
----v2.0
--------2.0 Bugfix
----Projects
--------New Website UI
--------New Person System

And that you merge all of these different folders into the trunk once you have fixed everything or completed a project. Does this sound right? I am always worried about clutter so this seems the right way but feels wrong.

Thanks!!!
Dru

[christian]

So basically if you are doing your releases by task and stuff your Vault trunk ($) gets to have a LOT of folders in it. Just thinking about all of this, I have the picture:

$Trunk
----Releases
--------v1.0
------------1.1
----v2.0
--------2.0 Bugfix
----Projects
--------New Website UI
--------New Person System

And that you merge all of these different folders into the trunk once you have fixed everything or completed a project. Does this sound right? I am always worried about clutter so this seems the right way but feels wrong.

Thanks!!!
Dru

Hi Dru,

My observation on the above...

From what I've read, branching from a branch (ie branching v1.0 to give you v1.1) is usually something you do NOT want to do. I think the idea here is that you want all release branches to have the trunk as a common ancestor as this makes tracking easier.

So therefore in your example you want to be working on your trunk for features going into release 1. You branch the trunk to give you your first release branch, thus:

$Trunk
$Releases
----v1.0

You then work on the trunk for vs1.1 features. In the meantime if you're need to support bug fixes you work on the v1.0 branch - just make sure that you merge these fixes into the trunk so that they go into v1.1.
When time comes to release 1.1 you branch the trunk to create v1.1 branch thus:

$Trunk
$Releases
----v1.0
----v1.1

Now supposing before you get to releasing vs1.1, part of the team wants to start on vs2.0 features. This is where you spin off a "Task branch" from the Trunk. This branch ring-fences vs2.0 from your current push (in the trunk) to get vs1.1 out of the door. This gives you:

$Trunk (currently working on vs1.1 features)
$Releases
----v1.0 (stable branch to support bug fixes)
$TaskBranches
----v2.0 (vs2 features that you're working on in parallel to work on the trunk)

Just make sure that you're regularly (probably daily) merging the trunk into your v2.0 branch.

At some point after releasing vs1.1 you're going to want to release vs2.0. At this point you merge $TaskBranches/v2.0 back into the $Trunk. This should be easy so long as you've kept $TaskBranches/v2.0 fresh with merges from the trunk. After a successful merge you then spin off another release branch ($Trunk/$Releases/v2.0).

$TaskBranches/v2.0 is now closed down / archived / no longer worked on. It has served its purpose and is now superseded by $Trunk/$Releases/v2.0.

You end up with Vault looking like this:

$Trunk (work on vs3 (or manybe vs2.1 features)
$Releases (stable branch to support bug fixes)
----v1.0
----v1.1
----v2.0
$TaskBranches
----v2.0 (archived branch)

I hope this helps.
Christian

[dsellers]

Yes very helpful!!!!

First off, whoa you can multiple $folders! hadn't known that I am going to have to play with that one.

Also, what is the best way to represent this layout on the physical disk?

Thanks a lot!!!!!!!
Dru

[christian]

Yes very helpful!!!!

First off, whoa you can multiple $folders! hadn't known that I am going to have to play with that one.

I think I've been slightly misleasding in my diagrams. My last diagram should read:

$ (this is the root node in Vault)
---Trunk (work on vs3 (or maybe vs2.1 features)
---Releases (stable branch to support bug fixes)
------v1.0
------v1.1
------v2.0
---TaskBranches
------v2.0 (archived branch)

ie there is one root node in Vault!

Also, what is the best way to represent this layout on the physical disk?
Thanks a lot!!!!!!!
Dru

I try and ensure that the structure of the working directory mirrors the hierarchy in Vault as much as possible. This way what you see in Vault is what you get [in your working directory] when you do a recursive get / check-out.

Christian

[dsellers]

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?