Can one developer continue work on another's change set?
Hi
The scenario is one developer finish part of the work and another finish the rest. So 1. developer1 check-in a new changeset1, completes changeset1 (must do this in order for developer2 to accept, right?).
2. developer2 change flow target to developer1's workspace, and accept the changeset1.
3. developer2 makes more changes in the files, then try to check-in.
At this moment, I find developer2 can only check-in to a new changeset, not changeset1. Is this right? Is there a way for developer2 check-in to the same changeset1?
Thanks
Jirong
The scenario is one developer finish part of the work and another finish the rest. So 1. developer1 check-in a new changeset1, completes changeset1 (must do this in order for developer2 to accept, right?).
2. developer2 change flow target to developer1's workspace, and accept the changeset1.
3. developer2 makes more changes in the files, then try to check-in.
At this moment, I find developer2 can only check-in to a new changeset, not changeset1. Is this right? Is there a way for developer2 check-in to the same changeset1?
Thanks
Jirong
2 answers
Hi:
You're correct, a change set can only have one owner. It has to be completed to be accepted into another workspace. So you can't have different developers check-in changes against the same active change set. This way, you know who did what, when looking at the history view which lists all the change sets.
On the other hand, you can certainly have multiple developers associate the same work item to their respective change sets. We frequently do this kind of informal collaboration that doesn't require a separate stream or knowledge of each other's workspace. It's fine for simple collaborations.
e.g. if Mike and Zoe are 2 developers working on work item 100, this is how it can go:
1. Mike modifies some files and checks-in into a new change set 1. Associate change set 1 to work item 100, and complete the change set.
2. Mike adds a comment to work item 100 @zoe please accept associated change set and help me fix my code
3. Zoe can accept the change set associated to work item 100 (assuming Mike and Zoe's workspaces are in sync with each other to start with). Then further modifies the files and check-in into a second change set. Associate that change set to work item 100.
4. Zoe adds a comment to Mike in work item 100: @mike done! that was easy. Accept my change set.
For longer term collaboration involving big changes, it's best to clone an existing stream. Mike and Zoe can then deliver/accept to that side stream each other's change sets.
HTH
Christophe Cornu
You're correct, a change set can only have one owner. It has to be completed to be accepted into another workspace. So you can't have different developers check-in changes against the same active change set. This way, you know who did what, when looking at the history view which lists all the change sets.
On the other hand, you can certainly have multiple developers associate the same work item to their respective change sets. We frequently do this kind of informal collaboration that doesn't require a separate stream or knowledge of each other's workspace. It's fine for simple collaborations.
e.g. if Mike and Zoe are 2 developers working on work item 100, this is how it can go:
1. Mike modifies some files and checks-in into a new change set 1. Associate change set 1 to work item 100, and complete the change set.
2. Mike adds a comment to work item 100 @zoe please accept associated change set and help me fix my code
3. Zoe can accept the change set associated to work item 100 (assuming Mike and Zoe's workspaces are in sync with each other to start with). Then further modifies the files and check-in into a second change set. Associate that change set to work item 100.
4. Zoe adds a comment to Mike in work item 100: @mike done! that was easy. Accept my change set.
For longer term collaboration involving big changes, it's best to clone an existing stream. Mike and Zoe can then deliver/accept to that side stream each other's change sets.
HTH
Christophe Cornu
We found a little trick to change the owner of an existing change-set... :)
The scenario:
- developer1 check-in a new changeset1. Notice that the change-set is not completed.
- developer2 duplicates the repository workspace owned by developer1 (right click on developer1's repository workspace, then click "Duplicate...", etc.).
- Set the ownership of this repository workspace to developer2.
- developer2 got changeset1 and now he can check-in the same change-set! In fact, the duplicate action creates a new changeset2 equals to changeset1.