Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Sharing Code with peer developers

Questions
Tags
Users
Badges
Chidambaram L PESIL InfoSol Pvt Ltd
(234●11●51●96) Apr 07 '20, 2:49 a.m.

There are only 2 developers. Is the 2nd method recommended:

  1. Developer maintains his/her own Repository Work Space & deliver to the Stream; 2nd developer Accepts the Code from the Stream.
  2. 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.

0 votes

3 answers
4,838 views
0 votes

Accepted answer

Permanent link
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (64.6k●3●36●49) Apr 07 '20, 3:55 a.m.
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

0 votes

Comments
Chidambaram L PESIL InfoSol Pvt Ltd
Apr 07 '20, 4:13 a.m.
@rschoon, 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
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Apr 07 '20, 4:14 a.m.
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

Permanent link
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (30.1k●3●34●35) Apr 07 '20, 1:58 p.m.

 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.

0 votes

Comments
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Apr 10 '20, 7:08 a.m.
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
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Apr 11 '20, 1:10 p.m.
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
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Apr 12 '20, 12:53 p.m.
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
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Apr 13 '20, 9:33 a.m.
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.

Permanent link
Chidambaram L PESIL InfoSol Pvt Ltd
(234●11●51●96) edited
Apr 13 '20, 9:25 a.m.
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.

0 votes

Your answer

Register or log in to post 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,144

Question asked: Apr 07 '20, 2:49 a.m.

Question was seen: 4,838 times

Last updated: May 06 '20, 8:14 p.m.

Confirmation Cancel Confirm