It's all about the answers!

Ask a question

[closed] SCM: Complete vs. Deliver change sets


Steve Speicher (31765) | asked Aug 06 '08, 10:43 a.m.
JAZZ DEVELOPER
closed Nov 08 '16, 10:50 a.m. by Ralph Schoon (63.2k33646)
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 nice if the SCM system would manage keeping my current change set alive, while making my changes visible (either by handling creating child change sets or not) to the parent stream. Once done with my change set, only then will I complete it. Then I would not have to keep creating new change set.

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



permanent link
Christophe Cornu (47123) | answered Aug 07 '08, 10:42 a.m.
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 and his. This is a very lightweight way to collaborate, very convenient for simple tasks. And because you created your change set, Mike does not get all the credit for your good work :-) Or we know who to blame if some change breaks something...

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

permanent link
John Camelon (1.7k14) | answered Aug 06 '08, 11:42 a.m.
JAZZ DEVELOPER
sspeiche wrote:
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
nice if the SCM system would manage
keeping my current change set alive, while making my changes visible
(either by handling creating child change sets or not) to the parent
stream. Once done with my change set, only then will I complete it.
Then I would not have to keep creating new change set.

Is there a better way to do this?

Thanks in advance


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
Steve Speicher commented Aug 06 '08, 2:25 p.m. | edited Nov 08 '16, 10:44 a.m.
JAZZ DEVELOPER
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).



John,
Thanks for the information. I did attempt to find a description of "complete" in online docs and help system and was not able to find it.

I'm struggling if your response is: "working as designed" or "open a enhancement"?

I would see this as a valuable usability improvement but could be implemented without impacting the integrity of the existing model.

For example, I create my change set named "Explore new model impls". I deliver my work at the end of the day (but not complete it). What is really delivered is something like change set "Explore new model impls 20080805". I still have an active change set called "Explore new model impls". As time goes on, I can keep just doing a "Deliver". When I'm done, I can just "Complete" the change set and it's gone.

With the current model, I have to keep doing "Deliver". Followed by "New Change Set", enter in comment, associate change to it, repeat.

Thanks,
Steve


John Camelon commented Aug 07 '08, 10:10 a.m. | edited Nov 08 '16, 10:45 a.m.
JAZZ DEVELOPER

sspeiche wrote:

John,
Thanks for the information. I did attempt to find a description of
"complete" in online docs and help system and was not able
to find it.

I'm struggling if your response is: "working as designed" or
"open a enhancement"?

Please open an enhancement request on Source Control and assign it to me
(John Camelon).

Thanks


Steve Speicher commented Aug 07 '08, 4:22 p.m. | edited Nov 08 '16, 10:45 a.m.
JAZZ DEVELOPER

Please open an enhancement request on Source Control


Done https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/59650

and assign it to me (John Camelon)

Not done, permission denied :?


permanent link
Geoffrey Clemm (30.1k33035) | 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:
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).

John,
Thanks for the information. I did attempt to find a description of
"complete" in online docs and help system and was not able
to find it.

I'm struggling if your response is: "working as designed" or
"open a enhancement"?

I would see this as a valuable usability improvement but could be
implemented without impacting the integrity of the existing model.

For example, I create my change set named "Explore new model
impls". I deliver my work at the end of the day (but not
complete it). What is really delivered is something like change set
"Explore new model impls 20080805". I still have an active
change set called "Explore new model impls". As time goes
on, I can keep just doing a "Deliver". When I'm done, I
can just "Complete" the change set and it's gone.

With the current model, I have to keep doing "Deliver".
Followed by "New Change Set", enter in comment, associate
change to it, repeat.

Thanks,
Steve