Concurrent programming and repository workspaces
Hi All,
I'm coming from the Clearcase world and now starting to use RTC source control. I setup my repository workspace and now want to change a file. I don't see a way to check-out the code as I was used to in clearcase. So it seems that other members in my team are also able to work on that file in parallel in their repository workspaces. Now when i deliver my changes. What happens with the changes of my colleague? I guess the change will show up in the pending changes view and he has to merge the my code with his. So in order to have something like a check-out, I need to lock the file, right?
So am I right with what I think? I didn't find the corresponding documentation. Maybe you can point me to it.
And the second question refers to my repository workspace. What's is the preferred scope of the repos workspace according to the RTC way? Public, Private or Scoped. I think the best way is to make it private but I'm not sure. If someone in my team is asking me I wouldn't know what to say.
Thanks in advance,
Regards,
arens
Accepted answer
Hi,
RTC does optimistic locking vs. pessimistic locking that is supported by ClearCase and other classic SCM tools. The Files are loaded on disk with read/write access. That means everybody can potentially change any file he has access to.
When working against a stream the SCM system will detect outgoing changes (checked in) and incoming changes (delivered to the stream). In case of a conflict that is also detected and you are provided with information about the type of conflict and support for merging.
Locking is weaker than check out. It is possible to lock a file on a stream. This will prevent others from delivering to the stream. It will not prevent others from changing the file locally. They just won't be able to deliver the change to a locked file. This is similar to hijacking a file if not connected in ClearCase.
Ralph
Comments
Note: The Pessimistic Locking feature was delivered in RTC 5.0.2.
For more information on this see:
New & Noteworthy: https://jazz.net/downloads/rational-team-concert/releases/5.0.2?p=news#pessimisticLocking
Also, the 2nd question was not answered, but it's encouraged to make repository workspaces private unless a need is there to make it public. This reduces the 'clutter' when people try to find workspaces by name for example (assuming they are not trying to find 'yours'). However if you intend to run personal builds, then you will need the repository workspace to be public so that the build user can see and load from that repository workspace.