This question is not answered. 
Replies: 4 - Pages: 1 - Last Post: Nov 10, 2010 4:14 PM Last Post By: Mark_at_Softwar... Threads: [ Previous | Next ] Posts: 2
Registered: Nov 09, 2010 11:41:22 AM checking in to a timed snap
Posted: Nov 09, 2010 11:48:33 AM when I attempt to check in to a snapshot view whose config starts with
element * CHECKEDOUT what should happen? It appears to me that, at least sometimes, the result is a checkin to the dynamic view instead, without any warning whatsoever, which is a disaster. This is bound to happen because I am a human being and forget which views are timed and which are not. On the other hand, I don't want to remove the above lines from the view, for if I remove them, it gets updated, which I don't want. How to keep timed snapshot views and prevent disaster at the same time? Your dynamic views presumably pick the latest version on some branches. When something gets checked in the dynamic view rule picks it. This is exactly what is supposed to happen. You need some branch rules to go with your time rule if you are going to proceed with this approach. What you really need to do is tell us your requirements so we can suggest a solution... When you check in where do you want the new versions to go? And why a time rule? More typically people use a label. What is the whole story? The dynamic view of the code tree reflects the "official" sources, from which the official software release is built. When I develop new features, I pull a snapshot view, do and test my changes only within the snapshot view, check in and out to the snapshot view many times, only when I am satisfied everything is working, I check the modified files to the dyno view. Sometimes I want to grab the state of the official sources from some time in the past. This I do by first pulling the current snapshot, then adding the time field to the config spec, as shown before, and updating. I forgot a particular snapshot was timed in this way, I attempted to develop there and check out and in of that snap. When I checked in, I was amazed to discover that some files went straight to dynamic view instead. I can understand that, since you cannot check in to the past, perhaps ClearCase figured out, what the heck, he wants to check in here, he can't, so let me check into the dyno view instead. But that is a disaster, as I am corrupting the official sources with as yet not developed new sources. How to prevent this and still be able to keep timed views. Ummm....you do realize that you are using IBM Rational ClearCase, right? Did you know that ClearCase allows the creation and use of labels and branches? I don't think you understand how dynamic and snapshot views work (and branches and labels for that matter). I strongly suggest you have a look at the "Developing Software with Rational ClearCase" guide and implement a better usage model. You're paying a lot of money for ClearCase and should get more of your money's worth out of it! (Sorry, I'm in kind of a bad mood this morning...) -Jeff Ng The only way with a time/snapshot scenario would be to not check anything in until you wanted to release it. A snapshot or a dynamic view - it doesn't matter. You really can't do what you are attempting to without branches. There isn't one single right way to do what you want. But typically... Mark Use the search field to find all types of content in My developerWorks with that tag. Use the slider bar to see more or fewer tags. Popular tags shows the top tags for this particular type of content or application that you're viewing. My tags shows your tags for this particular type of content or application that you're viewing.
time
Posts: 467
Registered: Apr 08, 2008 11:40:52 PM Re: checking in to a timed snap
Posted: Nov 09, 2010 04:02:49 PM 
in response to: MarkGaleck's post Time but itself is a very poor rule if you are going to check in.
Posts: 2
Registered: Nov 09, 2010 11:41:22 AM OK, here is the whole story.
Posts: 676
Registered: Jun 25, 2007 04:53:38 PM Re: checking in to a timed snap
Posted: Nov 10, 2010 11:51:13 AM in response to: MarkGaleck's post You wrote: OK, here is the whole story. The dynamic view of the code tree reflects the "official" sources, from which the official software release is built. When I develop new features, I pull a snapshot view, do and test my changes only within the snapshot view, check in and out to the snapshot view many times, only when I am satisfied everything is working, I check the modified files to the dyno view. Sometimes I want to grab the state of the official sources from some time in the past. This I do by first pulling the current snapshot, then adding the time field to the config spec, as shown before, and updating. I forgot a particular snapshot was timed in this way, I attempted to develop there and check out and in of that snap. When I checked in, I was amazed to discover that some files went straight to dynamic view instead. I can understand that, since you cannot check in to the past, perhaps ClearCase figured out, what the heck, he wants to check in here, he can't, so let me check into the dyno view instead. But that is a disaster, as I am corrupting the official sources with as yet not developed new sources. How to prevent this and still be able to keep timed views.
Posts: 467
Registered: Apr 08, 2008 11:40:52 PM Re: checking in to a timed snap
Posted: Nov 10, 2010 04:14:20 PM in response to: jeff98air's post Jeff may be in a bad mood but he is right.
Your time rule probably corresponds to some previous release?
If there isn't a label associated with it, use your view with the time rule and make a label on all the versions selected by the rule.
Then create a view (snapshot or dynamic it doesn't matter) that has mkbranch statements in the the config spec. If you aren't familiar with this...
https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/topic/com.ibm.rational.clearcase.tutorial.doc/topics/a_config_rules_subbranch.htm
Now when you check out it will automatically create a branch from the labelled version (and handle new files you add).
Finally you need to consider when you have finished.
You can merge back to the main branch at some appropriate time. Some here would argue you should release off the branch you developed on instead. 
Less 
No comments:
Post a Comment