Branching a label

[Xavier]

Hello,

we are doing our first branch of a project, and need some help (used to do it with source safe...).

We need to start from a label made some days ago (done with 'show labels...' then share): worked fine.

However, as the parent project is pinned; there is nothing we can do without 'unpinning' the parent and having all the files returning to a shared status, then loosing the version they were supposed to have.
This is exactly the same if we would like to merge the branch: it fails because the project is pinned.

So unless I'm wrong, once a project is pinned there is nothing we can do (beside unpinning it and loosing its version status) ? So what's the use of this feature ? Having a quick view of a label ?

If we decide to branch the project, I suppose that all files will be branched; which is also not what we want. We want to be able to either branch a single file of the branched project to do a specific fix without getting all the new stuff, or pin it to another version that may only have a fix.
Is it possible ?

I've read the help, but it's unclear on how you designed it (label branch), how we are supposed to use it.

I think this is the very basic need:
- have a stable version on which we might provide some fixes/service packs (so have most files pinned to a version of the main branch, and some branched)
- have a 'current' version with as many bugs as there are new features
- sometime, with a merge branches, copy a fix from the current version to the stable one.

Besides this pinned project that prevent to do anything, it seems the merge is very pratical !! (sourcesafe is so awful when it comes to merge files...)

Looking forward to some clue, advice on how to use it.

Last question: How can I rename the branch (pinned project), we used to name them by their version : Project_v1, Project_V2, while the current version is named Project

Regards

[Beth]

I was able to confirm that you can't branch on a label when the parent folder is both shared AND pinned. If the parent folder is not shared, but pinned, then one can branch on a label to a point outside of the pinned area. As far as trying to merge branches, I couldn't tell by your description what you were merging where. Can you provide more description there?

If the pinned parent is shared, then the labels should be able to be branched off of the side of the share that's not pinned.

The sole thing in here that is making it confusing is that you have a share and pinning and branching all happening on the same folder. I would need to see how your stuff is laid out, what goes where and how before I can see what should happen here.

think this is the very basic need:
- have a stable version on which we might provide some fixes/service packs (so have most files pinned to a version of the main branch, and some branched)
- have a 'current' version with as many bugs as there are new features
- sometime, with a merge branches, copy a fix from the current version to the stable one.

How I know of to deal with this is to have just a trunk and branches. For example, let's say you have ProjectA. You've just started it in the trunk and are about to release version 1. You make a branch and call it 1.0. That is what you are releasing. You will also create a label on what you release and that label will never change unless you go through label promotion, which is useful if you find a last second change before the release or make an error on what goes into that release. You can do that on the trunk or the branch. The part that is the trunk moves onto the coding for version 2. While that is going on, a bug is reported on version 1.0. You go to the 1.0 branch, make the necessary changes and label the result as 1.1 and then release version 1.1. Next you would merge the bug fix back into the trunk. If need be, you can always pin the branch now so that people leave it alone until another bug report comes in.

You then see that version 2 is ready for release, so you make another branch off of your trunk called 2.0. You label the release version of code 2.0. If bugs come in later, you make the changes in the branch, then merge the changes back to the trunk. If after the 2.0 release happens you find out that you have an old 1.1 bug to fix, then you fix that bug in the 1.1 branch, label that release as 1.2, then merge the changes back to the trunk and then do another merge to get the changes over to the 2.0 version.

In the example I've shown, your stable versions are labeled. That way you can always perform a Get on the label to get a stable version. You could make the trunk the stable version and only allow changes to branches, but I think you will have to do more merging between branches then. Also, in my example, pinning ends up not being needed.

I don't understand your process enough to say what you should do, so if you could provide more detail and/or screenshots that should help me address your situation better.

[Xavier]

Hello Beth,

not far to understand... In fact, we agree on the way to work (release, branch , ...); it's just a matter on how to proceed.

How is your branch made ?
=> show labels...
=> branch once the label is selected ?
=> the problem is that ALL files are branched (I would rather have all files pinned just like sourcesafe). I could then unpin/pin to have a bug fix.
In fact ALMOST ALL !! Some bug ? Some are still shared.
=> the other problem is that I loose all labels on the branch !
=> May be I could use your "Pin All power toy", but it would pin the latest version not the version based on a label. Just tried, but it failed.
=> What it the time option for ?

[Beth]

I received your email and will be taking this offline for some further discussion.

HS: 215139