[closed] SCM: Complete vs. Deliver change sets
Steve Speicher (317●6●5)
| asked Aug 06 '08, 10:43 a.m.
JAZZ DEVELOPER closed Nov 08 '16, 10:50 a.m. by Ralph Schoon (63.4k●3●36●46)
I struggle to understand the need for both complete and deliver.
What I'd like to do is deliver my change set periodically to share with others but not complete it. It would be Is there a better way to do this? Thanks in advance |
The question has been closed for the following reason: "The question is answered, right answer was accepted" by rschoon Nov 08 '16, 10:50 a.m.
3 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 06 '08, 4:37 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Steve,
I'd suggest that you open an enhancement workitem for this. In particular, I agree that this (i.e. removing the notion of a "complete" change-set) would be desirable from an end-user perspective. WRT the implementation, the only time you'd logically have to check whether a configuration had the most recent state of a change-set is when you are creating a new state of the change-set. In the nucor implementation for example, a change-set was an "auditable" (i.e. had a sequence of states), and what was stored in a configuration was a particular state of that change-set. The nucor GUI then gave you feedback on whether a particular configuration had the latest state of a particular change-set. So you could change a change-set any time you wanted (creating a new state of the change-set), with the only restriction being that a workspace had to be caught up to the most recent state of a change-set before creating a new state for it. Cheers, Geoff sspeiche wrote: John Camelonwrote: |
sspeiche wrote:
I struggle to understand the need for both complete and deliver. There is not really a better way to do this right now. Our implementation model trusts that a change set is active in only one workspace at a time, in order to A) simplify our model and B) prevent corruption of configuration with respect to change history. If we were to allow active change sets to exist in multiple streams, we would need to come up for a representation for accepting change-set modifications, and we would need to continually check to see if your version of change set X is the latest version of X for all SCM operations. The complete action exists so that you as a user can choose to segment your work off into pieces that you can easily roll back to, and to allow for sharing of change sets through mechanisms other than streams (e.g. work item links). Thanks, JohnC SCM Server Comments There is not really a better way to do this right now. Our
sspeiche wrote: John, Please open an enhancement request on Source Control and assign it to me (John Camelon). Thanks
and assign it to me (John Camelon) Not done, permission denied :? |
Hi Steve,
have to keep doing "Deliver". Followed by "New Change Set", enter in comment, associate change to it, repeat. Hope this tip will alleviate some of the pain ;-) Creating a change set from a work item with drag and drop. Here is a recommended workflow we use most of the time. 1. Create a work item describing what you are working on. Add your collaborators to the work item. Now they can see all your change sets for this work item! 2. Create change set as described above from work item editor (quick and easy!). 3. When reaching a stable point you want to share with others, deliver. Repeat from step 2. Note that your collaborators can see your change set(s) through the work item editor. They can accept them even if you did not deliver them. Yes, they will have to accept as a patch - aka get a 'copy' - if you did not deliver nor complete the change set. Which brings us to workflow #2. Alternative workflow #2: informal collaboration through a work item 1. 2. same as above 3. Making progress you want to share but not ready to deliver (because the JUnit tests don't pass for example)? Complete the change set(s) and add a comment in the work item 'Mike, I'm done with this change set, accept it and let me know when you've done your part'. 4. Mike can accept your change set and as in step2. Mike creates a change set associated to this work item. When Mike is done he delivers your change set Workflow #3: separate stream. If you need to work on an experimental and destabilizing feature with another person, you would create a new stream from your workspace and both you and your collaborator would deliver to that stream. Then you would deliver all your change sets to the regular stream when the job is done and tests are green. The link above is from Advanced Gestures and Workflows. Maybe some other tips there will be of interest to you. Let us know if you need more details. Thanks for the feedback . Chrix |