I would like to lock the main branch of a component so that others can't check in any changes that break existing functionality or API compatibility. I've done a cleartool lock <element>@@/main
for all files in the component, but this also prevents checkout operations.
I've argued that checking out in a branch is still allowed, but I work in an environment with pretty primitive SCM practices, where an unnatural fear of branching exists. Is it possible to just lock the branch for checkins and still allow checkouts?
The only thing I can think about is setting a ClearCase trigger. Are there any better options out there?
As discussed in this thread, locking folders and elements is not ideal.
In order to enforce a policy without having to deploy it for every client, setting a trigger remains the best option.
That thread suggests (for checkout, but the same idea can apply to checkin)
place a trigger on the directory to stop the checkout.
By default when you place an "element" trigger on a directory it is applied to it's current elements and future directory elements via its attachment list and inheritance list.
cleartool mktrtype -ele -preop checkout -exec /path/to/script NO_CHECKOUT
cleartool mktrigger NO_CHECKOUT /path/to/dir_name
In your case, the /path/to/script
(a path that should be accessible by all clients) needs to check if the current branch is /main
(using the trigger environment variables, like CLEARCASE_BRTYPE
).