Sharing Code with peer developers
There are only 2 developers. Is the 2nd method recommended:
- Developer maintains his/her own Repository Work Space & deliver to the Stream; 2nd developer Accepts the Code from the Stream.
- One Respository Workspace to be shared by 2 developers; both developers check-in code to the same repository workspace. Code change delivered to Stream once each Sprint.
2nd method is easy to understand & simple to use. though 2nd option would not be viable for more than 2 developers.
Accepted answer
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.
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.
- It is not supported
- The tool will tell you the repository workspace is loaded in two locations
- Changing the same repository workspace in different load locations will cause "out of sync errors"
-
Only the owner of the repository workspace can check in/has write permission for the repo ws
Summary: terrible idea, not supported, does not work.
2 other answers
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
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.
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.
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.
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.
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.