the Team who takes care of ClearCase tweaks the view in such a way that 2nd developer will not be able to access the files/code which the 1st developer is working on. It would pop an error stating that another branch is currently working on, so will not be able to checkout.
I suspect this would involve, with ClearCase:
a dedicated branch type for the first developer: Using the mkbrtype command, the admin can create a new branch type that is used only for the first developer's work.
a config spec for the first developer's view:The admin can edit the config spec for the first developer's view to include the new branch type. The config spec might look something like this:
element * CHECKEDOUT
element * .../first_developer_branch/LATEST
element * /main/LATEST -mkbranch first_developer_branch
This config spec tells ClearCase to show the first developer any files they have checked out, then the latest version on their branch, and finally to make a new branch if they check out a file that does not already have a branch of this type.
an access restriction to the new branch type: Using the cleartool protect -chgrp and cleartool protect -chmod commands, the admin can change the group and permissions of the new branch type so that only the first developer (and the admin) can check out files on this branch.
a config spec for the second developer's view: The admin can edit the config spec for the second developer's view to exclude the new branch type. The config spec might look something like this:
element * CHECKEDOUT
element * !.../first_developer_branch/LATEST
element * /main/LATEST -mkbranch second_developer_branch
This config spec tells ClearCase to show the second developer any files they have checked out, then the latest version on the main branch, but not to show them any files on the first developer's branch. If they try to check out a file that the first developer has already checked out on their branch, they will receive an error.
This setup would allow the first developer to work on files without the second developer being able to access them. However, it is a very restrictive setup that goes against the collaborative nature of most modern development workflows. The idea in most modern workflows is that developers should be able to work on any part of the codebase, and any conflicts between their work should be resolved through communication and code reviews, rather than preventing access to the code.
Since the Azure Devops branching strategies do not emulate directly this ClearCase approach, you could instead use Azure DevOps to manage a similar process of concurrent development by multiple developers.
That would involve:
creating a branch for the first developer to work on. This branch would be based off the main branch (or whatever your primary development branch is.
setting the "Branch Policies and Permissions" on the first developer's branch to restrict who can push changes. You can require pull requests for any changes and set up reviewers for these pull requests. You can also restrict who has push and merge permissions on this branch to just the first developer and any necessary admins.
creating a branch for the second developer to work on. This branch would also be based off the main branch.
setting the "Branch Policies and Permissions" for the second developer's branch to restrict who can push changes.
Again, you can require pull requests for any changes and set up reviewers for these pull requests. Restrict who has push and merge permissions on this branch to just the second developer and any necessary admins.
Now, both developers can work independently on their respective branches without affecting each other's work. When they are ready to merge their changes into the main codebase, they can create a pull request, which can be reviewed and approved by the relevant parties.
This set-up does not prevent the second developer from seeing the first developer's changes, but it does prevent them from pushing changes to the first developer's branch. This is more in line with the collaborative nature of modern development workflows, where all code is visible to all developers and conflicts are resolved through communication and code reviews.
However, if the second developer needs to work on the same file as the first developer, they could potentially face merge conflicts when they try to merge their changes back to the main branch. In this case, they would need to resolve these conflicts, which could involve integrating the first developer's changes into their own code. This process is facilitated by Azure DevOps' built-in conflict resolution tools.
