Simultaneously Process Configuration
Hello,
we work on a team and want to configure or process simultaneously - i.e each one create a type of WI - but RTC don't allow us saying that work will be lost when we try to save something at process configuration after someone else has edited him too. I understand that process configuration source has been changed, but there is a way to simultaneously configurate the process?
tks!
we work on a team and want to configure or process simultaneously - i.e each one create a type of WI - but RTC don't allow us saying that work will be lost when we try to save something at process configuration after someone else has edited him too. I understand that process configuration source has been changed, but there is a way to simultaneously configurate the process?
tks!
4 answers
There currently is no good way to simultaneously configure the process.
Here's the best I've come up with:
------------
First, a couple of general comments:
You can update an existing process template by importing from the file
system, but you cannot update from a project area.
You cannot update the process of a project area from a template.
You cannot delete a project area, and you cannot delete a process
template if any project areas have been instantiated from it.
So this means that you'll want to do your editing/debugging in a project
area and only create a process template for export to, and import from,
source control.
To avoid creating a new process template for every new process version,
a user will always import into a special template created for that user,
and will delete an export process template after the export is done.
Overall flow:
A: Put the process under source control
B: Developer dev1 makes some changes to the process
C: Developer dev2 make some changes in parallel,
D: Developer dev1 delivers his changes
E: Developer dev2 accepts the changes from dev1, merges, and delivers
his changes.
Details:
A: Put the process under source control
1. Select or create a stream, "acp-stream", with a component "acp-component"
2. Select or create a workspace on that stream, and load it into Eclipse
3. Create a new empty Eclipse project, called "acp-project", put it
under source control in the acp-component, and deliver it to acp-stream.
4. Open the project area you want to put under source control, and
change its name to be "acp-template"
5. Select the "Extract Process Template" operation, pick some ID, e.g.
"acp-template-id".
6. Open the Process Templates view
7. Right click on the acp template, and select "Export". For the
destination folder, select the acp-project root folder.
8. Right click on the acp template, and select "Delete" (we need to keep
acp-template and acp-template-id available for development of new
versions of the template).
9. In the Pending Changes view, select "Refresh Sandbox" (a new
"acp-template" folder should show up as an unresolved change).
10. Check in and deliver the changes.
B: Developer dev1 makes some changes to the process
1. Select or create a dev1-ws that flows with the acp-stream
2. Load dev1-ws
3. In the package explorer, open the acp-project folder, right click on
the acp-template-id folder, and select the "File -> Import -> Team
Process -> Process Template" operation. For the process name and
process id, specify dev1-acp-template and dev1-acp-template-id
4. Right click on the dev1-acp-template, and select New -> Project_Area.
5. Modify the process configuration of the project area, and test the
changes.
6. Right click on the project area, and select "Extract Process
Template" operation.
7. Modfy the process template name to be "acp-template" and modify the
process template id to be "acp-template-id"
8. Open the Process Templates view,
9. Right click on the acp template, and select "Export". For the
destination folder, select the acp-project root folder.
10. Right click on the acp template, and select "Delete" (we need to
keep acp-template and acp-template-id available for development of new
versions of the template).
11. In the Pending Changes view, select "Refresh Sandbox".
12. To work-around defect 174120, assuming you have not modified any
icons, undo all changes to the attachments.txt file, and to the
attachments directory.
13. Check in and complete the changes.
C: Developer dev2 make some changes in parallel,
Same operations as B, except all strings with "dev1" are changed to be
"dev2".
D: Developer dev1 delivers his changes
1. In Pending Changes view, select "deliver all".
E: Developer dev2 accepts the changes from dev1, merges, and delivers
his changes.
1. In Pending Changes view, select "accept all".
2. Resolve any conflicts (the built-in text Eclipse text merge tool
worked fine for me).
3. Checkin all changes, and deliver all.
------------
Cheers,
Geoff
On 11/8/2011 3:38 PM, fausto wrote:
Here's the best I've come up with:
------------
First, a couple of general comments:
You can update an existing process template by importing from the file
system, but you cannot update from a project area.
You cannot update the process of a project area from a template.
You cannot delete a project area, and you cannot delete a process
template if any project areas have been instantiated from it.
So this means that you'll want to do your editing/debugging in a project
area and only create a process template for export to, and import from,
source control.
To avoid creating a new process template for every new process version,
a user will always import into a special template created for that user,
and will delete an export process template after the export is done.
Overall flow:
A: Put the process under source control
B: Developer dev1 makes some changes to the process
C: Developer dev2 make some changes in parallel,
D: Developer dev1 delivers his changes
E: Developer dev2 accepts the changes from dev1, merges, and delivers
his changes.
Details:
A: Put the process under source control
1. Select or create a stream, "acp-stream", with a component "acp-component"
2. Select or create a workspace on that stream, and load it into Eclipse
3. Create a new empty Eclipse project, called "acp-project", put it
under source control in the acp-component, and deliver it to acp-stream.
4. Open the project area you want to put under source control, and
change its name to be "acp-template"
5. Select the "Extract Process Template" operation, pick some ID, e.g.
"acp-template-id".
6. Open the Process Templates view
7. Right click on the acp template, and select "Export". For the
destination folder, select the acp-project root folder.
8. Right click on the acp template, and select "Delete" (we need to keep
acp-template and acp-template-id available for development of new
versions of the template).
9. In the Pending Changes view, select "Refresh Sandbox" (a new
"acp-template" folder should show up as an unresolved change).
10. Check in and deliver the changes.
B: Developer dev1 makes some changes to the process
1. Select or create a dev1-ws that flows with the acp-stream
2. Load dev1-ws
3. In the package explorer, open the acp-project folder, right click on
the acp-template-id folder, and select the "File -> Import -> Team
Process -> Process Template" operation. For the process name and
process id, specify dev1-acp-template and dev1-acp-template-id
4. Right click on the dev1-acp-template, and select New -> Project_Area.
5. Modify the process configuration of the project area, and test the
changes.
6. Right click on the project area, and select "Extract Process
Template" operation.
7. Modfy the process template name to be "acp-template" and modify the
process template id to be "acp-template-id"
8. Open the Process Templates view,
9. Right click on the acp template, and select "Export". For the
destination folder, select the acp-project root folder.
10. Right click on the acp template, and select "Delete" (we need to
keep acp-template and acp-template-id available for development of new
versions of the template).
11. In the Pending Changes view, select "Refresh Sandbox".
12. To work-around defect 174120, assuming you have not modified any
icons, undo all changes to the attachments.txt file, and to the
attachments directory.
13. Check in and complete the changes.
C: Developer dev2 make some changes in parallel,
Same operations as B, except all strings with "dev1" are changed to be
"dev2".
D: Developer dev1 delivers his changes
1. In Pending Changes view, select "deliver all".
E: Developer dev2 accepts the changes from dev1, merges, and delivers
his changes.
1. In Pending Changes view, select "accept all".
2. Resolve any conflicts (the built-in text Eclipse text merge tool
worked fine for me).
3. Checkin all changes, and deliver all.
------------
Cheers,
Geoff
On 11/8/2011 3:38 PM, fausto wrote:
Hello,
we work on a team and want to configure or process simultaneously -
i.e each one create a type of WI - but RTC don't allow us saying that
work will be lost when we try to save something at process
configuration after someone else has edited him too. I understand
that process configuration source has been changed, but there is a
way to simultaneously configurate the process?
tks!
Hi Geoff,
tks for your response. Just one remaining question:
at the enhancement 174120, you say "My current advice to the customer is to uncheckout changes to the attachments.txt file, and any changes to the attachments directory, and handle those manually". If i create new WI types consequently attachments.txt will suffer changes, and then i will need to do manual merge. Is that right?
tks for your response. Just one remaining question:
at the enhancement 174120, you say "My current advice to the customer is to uncheckout changes to the attachments.txt file, and any changes to the attachments directory, and handle those manually". If i create new WI types consequently attachments.txt will suffer changes, and then i will need to do manual merge. Is that right?
There currently is no good way to simultaneously configure the process.
Here's the best I've come up with:
------------
First, a couple of general comments:
You can update an existing process template by importing from the file
system, but you cannot update from a project area.
You cannot update the process of a project area from a template.
You cannot delete a project area, and you cannot delete a process
template if any project areas have been instantiated from it.
So this means that you'll want to do your editing/debugging in a project
area and only create a process template for export to, and import from,
source control.
To avoid creating a new process template for every new process version,
a user will always import into a special template created for that user,
and will delete an export process template after the export is done.
Overall flow:
A: Put the process under source control
B: Developer dev1 makes some changes to the process
C: Developer dev2 make some changes in parallel,
D: Developer dev1 delivers his changes
E: Developer dev2 accepts the changes from dev1, merges, and delivers
his changes.
Details:
A: Put the process under source control
1. Select or create a stream, "acp-stream", with a component "acp-component"
2. Select or create a workspace on that stream, and load it into Eclipse
3. Create a new empty Eclipse project, called "acp-project", put it
under source control in the acp-component, and deliver it to acp-stream.
4. Open the project area you want to put under source control, and
change its name to be "acp-template"
5. Select the "Extract Process Template" operation, pick some ID, e.g.
"acp-template-id".
6. Open the Process Templates view
7. Right click on the acp template, and select "Export". For the
destination folder, select the acp-project root folder.
8. Right click on the acp template, and select "Delete" (we need to keep
acp-template and acp-template-id available for development of new
versions of the template).
9. In the Pending Changes view, select "Refresh Sandbox" (a new
"acp-template" folder should show up as an unresolved change).
10. Check in and deliver the changes.
B: Developer dev1 makes some changes to the process
1. Select or create a dev1-ws that flows with the acp-stream
2. Load dev1-ws
3. In the package explorer, open the acp-project folder, right click on
the acp-template-id folder, and select the "File -> Import -> Team
Process -> Process Template" operation. For the process name and
process id, specify dev1-acp-template and dev1-acp-template-id
4. Right click on the dev1-acp-template, and select New -> Project_Area.
5. Modify the process configuration of the project area, and test the
changes.
6. Right click on the project area, and select "Extract Process
Template" operation.
7. Modfy the process template name to be "acp-template" and modify the
process template id to be "acp-template-id"
8. Open the Process Templates view,
9. Right click on the acp template, and select "Export". For the
destination folder, select the acp-project root folder.
10. Right click on the acp template, and select "Delete" (we need to
keep acp-template and acp-template-id available for development of new
versions of the template).
11. In the Pending Changes view, select "Refresh Sandbox".
12. To work-around defect 174120, assuming you have not modified any
icons, undo all changes to the attachments.txt file, and to the
attachments directory.
13. Check in and complete the changes.
C: Developer dev2 make some changes in parallel,
Same operations as B, except all strings with "dev1" are changed to be
"dev2".
D: Developer dev1 delivers his changes
1. In Pending Changes view, select "deliver all".
E: Developer dev2 accepts the changes from dev1, merges, and delivers
his changes.
1. In Pending Changes view, select "accept all".
2. Resolve any conflicts (the built-in text Eclipse text merge tool
worked fine for me).
3. Checkin all changes, and deliver all.
------------
Cheers,
Geoff
On 11/8/2011 3:38 PM, fausto wrote:
Hello,
we work on a team and want to configure or process simultaneously -
i.e each one create a type of WI - but RTC don't allow us saying that
work will be lost when we try to save something at process
configuration after someone else has edited him too. I understand
that process configuration source has been changed, but there is a
way to simultaneously configurate the process?
tks!
Yes, that is correct, when you are actually adding or changing an
attachment, you need to fix up the attachment names (and the content of
the attachments.txt file), so that all of the existing attachments have
the same numeric order as they did before, and that the new attachments
are added to the end of the attachments.txt file (with the appropriate
name corresponding to their order in the revised attachments.txt file).
One probably could write a script to automate all/most of this, by
giving the script the location of the "pre-change" directory and the
location of the "post-change" directory ... if anyone has a chance to
write such a script, please attach it to 174120 !
Also, I'd encourage you to add a comment to 174120, indicating your
interest in getting this fixed.
Cheers,
Geoff
On 11/8/2011 9:38 PM, fausto wrote:
attachment, you need to fix up the attachment names (and the content of
the attachments.txt file), so that all of the existing attachments have
the same numeric order as they did before, and that the new attachments
are added to the end of the attachments.txt file (with the appropriate
name corresponding to their order in the revised attachments.txt file).
One probably could write a script to automate all/most of this, by
giving the script the location of the "pre-change" directory and the
location of the "post-change" directory ... if anyone has a chance to
write such a script, please attach it to 174120 !
Also, I'd encourage you to add a comment to 174120, indicating your
interest in getting this fixed.
Cheers,
Geoff
On 11/8/2011 9:38 PM, fausto wrote:
Hi Geoff,
tks for your response. Just one remaining question:
at the enhancement 174120, you say "My current advice to the
customer is to uncheckout changes to the attachments.txt file, and
any changes to the attachments directory, and handle those
manually". If i create new WI types consequently attachments.txt
will suffer changes, and then i will need to do manual merge. Is that
right?
gmclemmwrote:
There currently is no good way to simultaneously configure the
process.
Here's the best I've come up with:
------------
First, a couple of general comments:
You can update an existing process template by importing from the
file
system, but you cannot update from a project area.
You cannot update the process of a project area from a template.
You cannot delete a project area, and you cannot delete a process
template if any project areas have been instantiated from it.
So this means that you'll want to do your editing/debugging in a
project
area and only create a process template for export to, and import
from,
source control.
To avoid creating a new process template for every new process
version,
a user will always import into a special template created for that
user,
and will delete an export process template after the export is
done.
Overall flow:
A: Put the process under source control
B: Developer dev1 makes some changes to the process
C: Developer dev2 make some changes in parallel,
D: Developer dev1 delivers his changes
E: Developer dev2 accepts the changes from dev1, merges, and
delivers
his changes.
Details:
A: Put the process under source control
1. Select or create a stream, "acp-stream", with a
component "acp-component"
2. Select or create a workspace on that stream, and load it into
Eclipse
3. Create a new empty Eclipse project, called
"acp-project", put it
under source control in the acp-component, and deliver it to
acp-stream.
4. Open the project area you want to put under source control, and
change its name to be "acp-template"
5. Select the "Extract Process Template" operation, pick
some ID, e.g.
"acp-template-id".
6. Open the Process Templates view
7. Right click on the acp template, and select "Export".
For the
destination folder, select the acp-project root folder.
8. Right click on the acp template, and select "Delete"
(we need to keep
acp-template and acp-template-id available for development of new
versions of the template).
9. In the Pending Changes view, select "Refresh Sandbox"
(a new
"acp-template" folder should show up as an unresolved
change).
10. Check in and deliver the changes.
B: Developer dev1 makes some changes to the process
1. Select or create a dev1-ws that flows with the acp-stream
2. Load dev1-ws
3. In the package explorer, open the acp-project folder, right click
on
the acp-template-id folder, and select the "File -> Import
-> Team
Process -> Process Template" operation. For the process
name and
process id, specify dev1-acp-template and dev1-acp-template-id
4. Right click on the dev1-acp-template, and select New -
Project_Area.
5. Modify the process configuration of the project area, and test
the
changes.
6. Right click on the project area, and select "Extract Process
Template" operation.
7. Modfy the process template name to be "acp-template"
and modify the
process template id to be "acp-template-id"
8. Open the Process Templates view,
9. Right click on the acp template, and select "Export".
For the
destination folder, select the acp-project root folder.
10. Right click on the acp template, and select "Delete"
(we need to
keep acp-template and acp-template-id available for development of
new
versions of the template).
11. In the Pending Changes view, select "Refresh
Sandbox".
12. To work-around defect 174120, assuming you have not modified any
icons, undo all changes to the attachments.txt file, and to the
attachments directory.
13. Check in and complete the changes.
C: Developer dev2 make some changes in parallel,
Same operations as B, except all strings with "dev1" are
changed to be
"dev2".
D: Developer dev1 delivers his changes
1. In Pending Changes view, select "deliver all".
E: Developer dev2 accepts the changes from dev1, merges, and
delivers
his changes.
1. In Pending Changes view, select "accept all".
2. Resolve any conflicts (the built-in text Eclipse text merge tool
worked fine for me).
3. Checkin all changes, and deliver all.
------------
Cheers,
Geoff
On 11/8/2011 3:38 PM, fausto wrote:
Hello,
we work on a team and want to configure or process simultaneously -
i.e each one create a type of WI - but RTC don't allow us saying
that
work will be lost when we try to save something at process
configuration after someone else has edited him too. I understand
that process configuration source has been changed, but there is a
way to simultaneously configurate the process?
tks!
Ok Geoff,
thanks for your help. I will add a comment at 174120.
regards,
Fausto
thanks for your help. I will add a comment at 174120.
regards,
Fausto
Yes, that is correct, when you are actually adding or changing an
attachment, you need to fix up the attachment names (and the content of
the attachments.txt file), so that all of the existing attachments have
the same numeric order as they did before, and that the new attachments
are added to the end of the attachments.txt file (with the appropriate
name corresponding to their order in the revised attachments.txt file).
One probably could write a script to automate all/most of this, by
giving the script the location of the "pre-change" directory and the
location of the "post-change" directory ... if anyone has a chance to
write such a script, please attach it to 174120 !
Also, I'd encourage you to add a comment to 174120, indicating your
interest in getting this fixed.
Cheers,
Geoff
On 11/8/2011 9:38 PM, fausto wrote:
Hi Geoff,
tks for your response. Just one remaining question:
at the enhancement 174120, you say "My current advice to the
customer is to uncheckout changes to the attachments.txt file, and
any changes to the attachments directory, and handle those
manually". If i create new WI types consequently attachments.txt
will suffer changes, and then i will need to do manual merge. Is that
right?
gmclemmwrote:
There currently is no good way to simultaneously configure the
process.
Here's the best I've come up with:
------------
First, a couple of general comments:
You can update an existing process template by importing from the
file
system, but you cannot update from a project area.
You cannot update the process of a project area from a template.
You cannot delete a project area, and you cannot delete a process
template if any project areas have been instantiated from it.
So this means that you'll want to do your editing/debugging in a
project
area and only create a process template for export to, and import
from,
source control.
To avoid creating a new process template for every new process
version,
a user will always import into a special template created for that
user,
and will delete an export process template after the export is
done.
Overall flow:
A: Put the process under source control
B: Developer dev1 makes some changes to the process
C: Developer dev2 make some changes in parallel,
D: Developer dev1 delivers his changes
E: Developer dev2 accepts the changes from dev1, merges, and
delivers
his changes.
Details:
A: Put the process under source control
1. Select or create a stream, "acp-stream", with a
component "acp-component"
2. Select or create a workspace on that stream, and load it into
Eclipse
3. Create a new empty Eclipse project, called
"acp-project", put it
under source control in the acp-component, and deliver it to
acp-stream.
4. Open the project area you want to put under source control, and
change its name to be "acp-template"
5. Select the "Extract Process Template" operation, pick
some ID, e.g.
"acp-template-id".
6. Open the Process Templates view
7. Right click on the acp template, and select "Export".
For the
destination folder, select the acp-project root folder.
8. Right click on the acp template, and select "Delete"
(we need to keep
acp-template and acp-template-id available for development of new
versions of the template).
9. In the Pending Changes view, select "Refresh Sandbox"
(a new
"acp-template" folder should show up as an unresolved
change).
10. Check in and deliver the changes.
B: Developer dev1 makes some changes to the process
1. Select or create a dev1-ws that flows with the acp-stream
2. Load dev1-ws
3. In the package explorer, open the acp-project folder, right click
on
the acp-template-id folder, and select the "File -> Import
-> Team
Process -> Process Template" operation. For the process
name and
process id, specify dev1-acp-template and dev1-acp-template-id
4. Right click on the dev1-acp-template, and select New -
Project_Area.
5. Modify the process configuration of the project area, and test
the
changes.
6. Right click on the project area, and select "Extract Process
Template" operation.
7. Modfy the process template name to be "acp-template"
and modify the
process template id to be "acp-template-id"
8. Open the Process Templates view,
9. Right click on the acp template, and select "Export".
For the
destination folder, select the acp-project root folder.
10. Right click on the acp template, and select "Delete"
(we need to
keep acp-template and acp-template-id available for development of
new
versions of the template).
11. In the Pending Changes view, select "Refresh
Sandbox".
12. To work-around defect 174120, assuming you have not modified any
icons, undo all changes to the attachments.txt file, and to the
attachments directory.
13. Check in and complete the changes.
C: Developer dev2 make some changes in parallel,
Same operations as B, except all strings with "dev1" are
changed to be
"dev2".
D: Developer dev1 delivers his changes
1. In Pending Changes view, select "deliver all".
E: Developer dev2 accepts the changes from dev1, merges, and
delivers
his changes.
1. In Pending Changes view, select "accept all".
2. Resolve any conflicts (the built-in text Eclipse text merge tool
worked fine for me).
3. Checkin all changes, and deliver all.
------------
Cheers,
Geoff
On 11/8/2011 3:38 PM, fausto wrote:
Hello,
we work on a team and want to configure or process simultaneously -
i.e each one create a type of WI - but RTC don't allow us saying
that
work will be lost when we try to save something at process
configuration after someone else has edited him too. I understand
that process configuration source has been changed, but there is a
way to simultaneously configurate the process?
tks!