mistakenly check in unresolved files with deliver operation

To me, the dialog is very clear. All that dialog is asking is if you want to "Check in" "Unresolved changes". Files in a "Checked in" state can be modified.

As a matter of fact, most users here do check in, but do not deliver unresolved changes. They have change sets for this very purpose (i.e., "Checked in, but do not deliver yet"). They can continue to modify the "checked in" files afterward (they go into the unresolved state when edits are made to them and then you can overwrite the files in the change set by checking them in again). When they are ready to deliver the files, they move the files to another change set (i.e., Code changes for WI 1234) and associate a Work Item to it. Then they deliver the new change set.

This is very helpful in case something happens to their PC (system crash, for example), since RTC has captured their changes. Since the checked in files are in RTC, if something happens, and they need to reload their workspace, they get their "Checked in" files and pick up where they left off. This is sort of a "Software Development Best Practices" way of working and one of the reasons that developers here like using RTC.

- Walter

When I delivered a change set, there is a dialog to ask me if I need to check other unresolved files. At most time, that is not what I want because I am going to modify them for a while. But this dialog leads me to say yes for several time, and to check in these unfinished code.

I know if I am more careful to choose no in the pop-up dialog, I will have no problems. But I just want to mention this here, maybe there is one way to improve the dialog somehow. Thanks.

Best,

Jiangfan

In 3.0 and 2.0.0.2 iFix4 we've added an option to "not show this again" to the dialog and use your default option as the suggestion. We've had a lot of feedback on this dialog, some love it, some hate it, so we've made it configurable.
Cheers,
Jean-Michel

In 3.0 and 2.0.0.2 iFix4 we've added an option to "not show this again" to the dialog and use your default option as the suggestion. We've had a lot of feedback on this dialog, some love it, some hate it, so we've made it configurable.
Cheers,
Jean-Michel

Thanks, Walter.

It is interesting to know how most people use RTC. For example, we can edit files which are in an outgoing folder, and then re-check in to overwrite them. There is one more question.

"When they are ready to deliver the files, they move the files to another change set (i.e., Code changes for WI 1234) and associate a Work Item to it. Then they deliver the new change set."

Why do we create another change set B, and more the current change set A to it? Why not directly associate a work item to A?

Best,

Jiangfan

When I delivered a change set, there is a dialog to ask me if I need to check other unresolved files. At most time, that is not what I want because I am going to modify them for a while. But this dialog leads me to say yes for several time, and to check in these unfinished code.

I know if I am more careful to choose no in the pop-up dialog, I will have no problems. But I just want to mention this here, maybe there is one way to improve the dialog somehow. Thanks.

Best,

Jiangfan

Thanks for the tip, Jean-Michel.

which is exactly what I need for now.

Best,

Jiangfan

In 3.0 and 2.0.0.2 iFix4 we've added an option to "not show this again" to the dialog and use your default option as the suggestion. We've had a lot of feedback on this dialog, some love it, some hate it, so we've made it configurable.
Cheers,
Jean-Michel

Hi Jiangfan,

Developers here like to keep the Change Set named "Checked in, but do not deliver yet" available for future use. Following your earlier email, we'll call this Change Set A. So, they ordinarily do not associate a Work Item with it. They could do so, if they wanted to. They just find it easier to move code being delivered to another Change Set (which we will call B) and deliver that Change Set to the stream.

For example, you could have 50 files in the Change Set A, but only want to deliver 32 of them to the stream so that other developers can see the changes. You move those 32 files to Change Set B, associate a Work Item to it, and deliver it. You will still have Change Set A available for use.

Jean-Michel,

Add me to the list of people who like the dialog the way it is :D

Thanks,

- Walter

Thanks for the tip, Jean-Michel.

which is exactly what I need for now.

Best,

Jiangfan

In 3.0 and 2.0.0.2 iFix4 we've added an option to "not show this again" to the dialog and use your default option as the suggestion. We've had a lot of feedback on this dialog, some love it, some hate it, so we've made it configurable.
Cheers,
Jean-Michel

Hello Jean-Michel,

I can understand your procedure which is reasonable. This is what I use RTC now.

Following your example, I keep changing 50 files in an unsolved folder. If I need to deliver 32 of them, I will check them in to a "checked in, but do not deliver yet", and deliver it. So I do not need to create one more "checked in, but do not deliver yet" for delivering 32 files.

Any suggestion is welcome.

Best wishes.

Jiangfan

Hi Jiangfan,

Developers here like to keep the Change Set named "Checked in, but do not deliver yet" available for future use. Following your earlier email, we'll call this Change Set A. So, they ordinarily do not associate a Work Item with it. They could do so, if they wanted to. They just find it easier to move code being delivered to another Change Set (which we will call B) and deliver that Change Set to the stream.

For example, you could have 50 files in the Change Set A, but only want to deliver 32 of them to the stream so that other developers can see the changes. You move those 32 files to Change Set B, associate a Work Item to it, and deliver it. You will still have Change Set A available for use.

Jean-Michel,

Add me to the list of people who like the dialog the way it is :D

Thanks,

- Walter

Thanks for the tip, Jean-Michel.

which is exactly what I need for now.

Best,

Jiangfan

In 3.0 and 2.0.0.2 iFix4 we've added an option to "not show this again" to the dialog and use your default option as the suggestion. We've had a lot of feedback on this dialog, some love it, some hate it, so we've made it configurable.
Cheers,
Jean-Michel

A couple of comments.

First, note that "this is how we use RTC" comments were all from Walter
.... Jean-Michel just posted the comment that RTC has been enhanced to
allow you to dismiss this dialog.

Second, WRT common usage, there are many different good ways of using
RTC change sets. Walter describes the way that works well for his team.
For my team, I recommend that every change set be associated with a
work item from the very beginning (my rationale is that if you don't
know why you are making the change, you shouldn't be making it in the
first place, and if you do know why you are making a change, you should
have a work item describing that reason :-).

Cheers,
Geoff

On 7/29/2010 5:07 PM, jiangfanshi wrote:

Hello Jean-Michel,

I can understand your procedure which is reasonable. This is what I
use RTC now.

Following your example, I keep changing 50 files in an unsolved
folder. If I need to deliver 32 of them, I will check them in to a
"checked in, but do not deliver yet", and deliver it. So I
do not need to create one more "checked in, but do not deliver
yet" for delivering 32 files.

Any suggestion is welcome.

Best wishes.

Jiangfan


wmansurwrote:
Hi Jiangfan,

Developers here like to keep the Change Set named "Checked in,
but do not deliver yet" available for future use. Following
your earlier email, we'll call this Change Set A. So, they
ordinarily do not associate a Work Item with it. They could do so,
if they wanted to. They just find it easier to move code being
delivered to another Change Set (which we will call B) and deliver
that Change Set to the stream.

For example, you could have 50 files in the Change Set A, but only
want to deliver 32 of them to the stream so that other developers can
see the changes. You move those 32 files to Change Set B, associate a
Work Item to it, and deliver it. You will still have Change Set A
available for use.

Jean-Michel,

Add me to the list of people who like the dialog the way it is :D

Thanks,

- Walter
jiangfanshiwrote:
Thanks for the tip, Jean-Michel.

which is exactly what I need for now.

Best,

Jiangfan

jlemieuxwrote:
In 3.0 and 2.0.0.2 iFix4 we've added an option to "not show this
again" to the dialog and use your default option as the
suggestion. We've had a lot of feedback on this dialog, some love it,
some hate it, so we've made it configurable.
Cheers,
Jean-Michel

Thanks all your great answers. I opened my eye for RTC from experts here.

Best wishes and Have a great day!

Jiangfan

A couple of comments.

First, note that "this is how we use RTC" comments were all from Walter
.... Jean-Michel just posted the comment that RTC has been enhanced to
allow you to dismiss this dialog.

Second, WRT common usage, there are many different good ways of using
RTC change sets. Walter describes the way that works well for his team.
For my team, I recommend that every change set be associated with a
work item from the very beginning (my rationale is that if you don't
know why you are making the change, you shouldn't be making it in the
first place, and if you do know why you are making a change, you should
have a work item describing that reason :-).

Cheers,
Geoff

On 7/29/2010 5:07 PM, jiangfanshi wrote:

Hello Jean-Michel,

I can understand your procedure which is reasonable. This is what I
use RTC now.

Following your example, I keep changing 50 files in an unsolved
folder. If I need to deliver 32 of them, I will check them in to a
"checked in, but do not deliver yet", and deliver it. So I
do not need to create one more "checked in, but do not deliver
yet" for delivering 32 files.

Any suggestion is welcome.

Best wishes.

Jiangfan


wmansurwrote:
Hi Jiangfan,

Developers here like to keep the Change Set named "Checked in,
but do not deliver yet" available for future use. Following
your earlier email, we'll call this Change Set A. So, they
ordinarily do not associate a Work Item with it. They could do so,
if they wanted to. They just find it easier to move code being
delivered to another Change Set (which we will call B) and deliver
that Change Set to the stream.

For example, you could have 50 files in the Change Set A, but only
want to deliver 32 of them to the stream so that other developers can
see the changes. You move those 32 files to Change Set B, associate a
Work Item to it, and deliver it. You will still have Change Set A
available for use.

Jean-Michel,

Add me to the list of people who like the dialog the way it is :D

Thanks,

- Walter
jiangfanshiwrote:
Thanks for the tip, Jean-Michel.

which is exactly what I need for now.

Best,

Jiangfan

jlemieuxwrote:
In 3.0 and 2.0.0.2 iFix4 we've added an option to "not show this
again" to the dialog and use your default option as the
suggestion. We've had a lot of feedback on this dialog, some love it,
some hate it, so we've made it configurable.
Cheers,
Jean-Michel

Thanks all your great answers. I opened my eye for RTC from experts here.

Best wishes and Have a great day!

Jiangfan

A couple of comments.

First, note that "this is how we use RTC" comments were all from Walter
.... Jean-Michel just posted the comment that RTC has been enhanced to
allow you to dismiss this dialog.

Second, WRT common usage, there are many different good ways of using
RTC change sets. Walter describes the way that works well for his team.
For my team, I recommend that every change set be associated with a
work item from the very beginning (my rationale is that if you don't
know why you are making the change, you shouldn't be making it in the
first place, and if you do know why you are making a change, you should
have a work item describing that reason :-).

Cheers,
Geoff

On 7/29/2010 5:07 PM, jiangfanshi wrote:

Hello Jean-Michel,

I can understand your procedure which is reasonable. This is what I
use RTC now.

Following your example, I keep changing 50 files in an unsolved
folder. If I need to deliver 32 of them, I will check them in to a
"checked in, but do not deliver yet", and deliver it. So I
do not need to create one more "checked in, but do not deliver
yet" for delivering 32 files.

Any suggestion is welcome.

Best wishes.

Jiangfan


wmansurwrote:
Hi Jiangfan,

Developers here like to keep the Change Set named "Checked in,
but do not deliver yet" available for future use. Following
your earlier email, we'll call this Change Set A. So, they
ordinarily do not associate a Work Item with it. They could do so,
if they wanted to. They just find it easier to move code being
delivered to another Change Set (which we will call B) and deliver
that Change Set to the stream.

For example, you could have 50 files in the Change Set A, but only
want to deliver 32 of them to the stream so that other developers can
see the changes. You move those 32 files to Change Set B, associate a
Work Item to it, and deliver it. You will still have Change Set A
available for use.

Jean-Michel,

Add me to the list of people who like the dialog the way it is :D

Thanks,

- Walter
jiangfanshiwrote:
Thanks for the tip, Jean-Michel.

which is exactly what I need for now.

Best,

Jiangfan

jlemieuxwrote:
In 3.0 and 2.0.0.2 iFix4 we've added an option to "not show this
again" to the dialog and use your default option as the
suggestion. We've had a lot of feedback on this dialog, some love it,
some hate it, so we've made it configurable.
Cheers,
Jean-Michel