|
CR Sharing Part II - Floating CRs while Branching Files |
|
In this post, we will discuss the sticky puzzle of how to have our CRs float in the activity views while files are branching in the same activity views.
For review, here is the visual of our hypothetical bike project:
| Folders in BikeCRs |
Views in BikeCode |
Folders in branch BikeCode/5.0 |
Folders in branch BikeCode/6.0 |
RootFolder
---Active
------5.0
------6.0
---Closed
------1.0
------2.0
------3.0 |
RootView
---5.0
---6.0
---Closed1.0
---Closed2.0
---Closed3.0 |
RootFolder
---change-requests
------5.0
---src
---etc ...etc... |
RootFolder
---change-requests
------6.0
---src
---etc ...etc... |
Normal daily operations in activity branches
On a day-to-day basis, the following should be true of our activity branches (BikeCode/5.0 and BikeCode/6.0):
- Checking in a file causes it to branch from its parent in the root view (unless it's already branched, of course).
- Changing the properties of a CR should not branch, but rather float to the CR's parent in the BikeCRs project.
These two things then imply that
- The behavior of CRs must be branch-on-change=no (and configuration=floating).
- The behavior of files must be branch-on-change=yes (which implies a fixed configuration)
Normal daily operations in the master CR project
This subject is simple. There are no files in the BikeCR project, and so it doesn't matter if we make them branch or not. We can think of the BikeCR project as being 100% floating.
The importance of floating folders
The big idea, of course, is that CRs should float. But it is even more important to understand that folders also can have floating or branching behaviors. It is the behaviors of the folders that really make this CR sharing thing work. Specifically, each activity branch has one or more floating folders in it to hold floating CRs. (In this example, I've placed the CR folders (5.0 and 6.0) under an arbitrary root folder called change-requests. This makes it easier if you have multiple CR folders per activity branch -- e.g. 5.0.1, 5.0.2, 5.0.3, etc...). The cool thing is this: because the numbered CR folders (5.0 and 6.0) are floating shares of their counterparts in BikeCR, a new CR entered in either place appers in both. (Better still, the root instance of the new CR item is in the root share instance of the folder no matter which instance was used for entry. If that bends your mind, don't worry about it. It's just a good thing that is worthwhile to know but not essential.)
Creating a new activity branch with CR sharing
This is the critical operation for you, the CM. If you do right setting up the new activity branch, then you avoid a lot of painful work later. If you aren't careful, you can end up pulling an all-nighter to get things back in order. So, BE CAREFUL.
- Create the new branching view in BikeCode from the root view based upon an appropriate configuration of the root view. For example, we might use the latest 6.0 code merged up to root as the basis for our 7.0 activity view. Presumably we labeled it when we last merged 6.0 up to root. The new view should be Branch-All and its configuration should be fixed, presumably to that 6.0.x label.
- Set the view properties to NOT> set items shared into the view to branch on change. Remember that we are setting up to float CRs automatically, and that's why this is necessary. The flip side is that we will have to do some manual work in our merging of files, particularly new files.
- Create the change-requests folder in the new activity view. You might think it's already going to be there, inherited from the root view, but I've not mentioned yet that we don't have any CRs in the root view. I suppose one could, but in my example, I choose not to. In any case, if a change-requests folder is inherited from root, delete it and create a new one in the branch. We don't want the change-requests folders to try to merge with each other and that's why we do this; to ensure that each branch's change-requests folder is complete independent of any other branches.
- Create the numbered CR folder (7.0 in this example) inthe master CR project. (BikeCR in this example) Then share it into the new branch's change-requests folder. IMPORTANT: this is where the view property "set items shared into this view to branch on change" is critical. If you didn't turn off that setting then your CRs will start branching and you don't want that.
Summary
Now you have a new activity branch with a floating folder to float CRs with yor master CR project while keeping your files branching. You also have some big file merge headaches to watch out for, but happily they only have to do with new files. You can merge your existing files in pretty much the normal ways. I mostly use viewmerge.exe for regular merges and occasionally the GUI VCM to resolve conflicts. (updated 2/7/06) In Part III we will discuss in detail how to handle the "last build" and "addressed in" fields, given that the labels to drive them are in only the code view including SDK code to bridge the gap. In Part IV we will discuss in detail how to handle new files at merge time, including the manual details and the SDK code to automate them.
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed