Sharing Code with peer developers
There are only 2 developers. Is the 2nd method recommended:
2nd method is easy to understand & simple to use. though 2nd option would not be viable for more than 2 developers.
|
Accepted answer
Ralph Schoon (63.1k●3●36●46)
| answered Apr 07 '20, 3:55 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You share a stream. You do not share a repository workspace as it is not supported and will cause a lot of problems.
There is nothing easy about essentially working with two people in the same directory. If you want to use the advantage of a small team, then accept and deliver often and let the others know about it.
Ralph Schoon selected this answer as the correct answer
Comments
IBM documents prescribe sharing the code through Stream.
In my case, two developers have their own Eclipse Workspace & wanted to use one Repository Workspace. Each developer "Accept" the Change Sets of other developer to their Eclipse Workspace when ever required. Still they have 2 Eclipse workspace folders.
Ralph Schoon
commented Apr 07 '20, 4:13 a.m.
| edited Apr 07 '20, 4:14 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Summary: terrible idea, not supported, does not work.
|
2 other answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 07 '20, 1:58 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER As Ralph correctly points out, two different users should never work in a single repository workspace. There are no exceptions to this rule.
If you want to share changes just between two developers (and not between other team members), then you can add the other developer's repository workspace as a flow target of your repository workspace, and "accept" changes directly from the other repository workspace into your workspace. But as soon as you have more than two developers sharing work, you should introduce a stream for that sharing.
Comments
Ralph Schoon
commented Apr 10 '20, 7:01 a.m.
| edited Apr 10 '20, 7:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You can only accept and not even deliver - there is no benefit in doing this, there are only downsides.
I am not aware of other tools supporting this and I am pretty convinced you should not attempt doing this.
Geoffrey Clemm
commented Apr 11 '20, 1:08 p.m.
| edited Apr 11 '20, 1:10 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The upside is that you don't have to deliver ... when you are ready for the other developer to accept the changes in a given change set, you just complete that change set. When the other developer is ready to accept your completed changes, they just accept them.
The benefit of being able to share your code without delivering is that delivering can encounter a conflict, which means you cannot make your changes available for sharing until you have resolved those conflicts. But you might not be ready to accept those conflicting changes, so your changes stay hidden away in your workspace until you are ready to accept those conflicting changes, resolve the conflicts, and then deliver. With the workspace flow approach, you just mark your change set as complete, and it is now ready for use by the other developer. Of course, if there are conflicts, the other developer who wants to accept those changes will have to resolve those conflicts. But that is fine ... they want to accept your changes.
Ralph Schoon
commented Apr 12 '20, 12:52 p.m.
| edited Apr 12 '20, 12:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Package does not matter, file only matters if there are overlapping change locations in the files and the quality of the SCM merge tools make a difference.
I would suggest reading https://jazz.net/library/article/1481 .
My oppinion is, that delivery while there are incoming changes, should be prevented. Any developer should have to accept incoming changes, merge them and, after a successfull build and test, deliver the integration.
This is, by the way, completely independent of whatever tool you use for SCM. In the past the SCM tools used pessimistic locking, which would prevent conflicting changes. That had a lot of disadvantages.
Today the tools empahsize agility, which usually means less pessimistic locking and assuming all coders are high skilled and can do all jobs, merging included. All modern SCM tools work this way today.
So accept and build and deliver often to avoid merge issues.
Geoffrey Clemm
commented Apr 13 '20, 9:29 a.m.
| edited Apr 13 '20, 9:33 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
It would have been best to start a separate question on this topic, rather than have it appear as a comment on an answer to the previous topic. I was trying to carve out these posts into a separate "answer" with comments, so that it could be converted to a separate question, but I am getting forum server errors (it apparently gets upset if you move more than a couple comments around), so unfortunately Ralph's response is stuck in the original answer. I have moved moved Somu's clarification to be its own question ( https://jazz.net/forum/questions/268903 ), so we can continue the discussion there. |
|
Chidambaram L (234●1●41●78)
| answered Apr 12 '20, 9:07 a.m.
edited Apr 13 '20, 9:25 a.m. by Geoffrey Clemm (30.1k●3●30●35)
In another scenarios of code maintenance project in agile mode; There are 4 developers editing the same java package parallely. often they will edit the same file also; editing same line is rare. Though stand up call makes clarity on who is going to edit what, there will still be merge effort. one developer Delivers and rest 3 Accepts code on daily basis. hence merge effort is required for all 3 developers. All 3 developers will merge into the same code. Instead, do you recommend one developer to merge the code from all daily morning & rest of the 3 developers will Accept code after this merge happens.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.