There is a specific workflow that requires there be no more than one version (i.e., #1, and only a #1) for files in a specific Perforce path. Updating these files with a version #2 is not allowed.
Is there a way to prevent Perforce from allowing a #2 checkin for a Perforce tree?
Locking the entire tree is not an option, since users are free to check-in new files, just not update existing ones.
p4 change ChangeList
p4 add -c ChangeList
p4 lock -c ChangeList
Then just never touch it again and don't delete your workspace?
Related
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).
I have a large number of files that I am trying to check in. This process needs to be done several times and is time and resource consuming. I am using the follow command to do this:
cleartool lsco -cvi -all -s | awk '{print "cleartool ci -c \"<Name of checkin>\" " <path to vob> | sh
This command does work, but it takes a very long time to run, as each file is checked in individually. Is it possible to checkin all files at once, or perhaps a faster method of checkin in the files individually. Is it possible to use the same concept, but for a mass checkout?
As I mentioned in "What are the basic clearcase concepts every developer should know?", ClearCase remains a file-by-file VCS, meaning each operation (checkout; checkin, merge) is done file by file.
clearfsimport remains one possible "bulk" operation (even though behind the scene, it will still checkout or mkelem for new files, copy, and checkin the files one by one)
That means you can use one view as source folder (clearfsimport will import any folder, ClearCase view or not), and a snapshot view with the same config spec as destination. See "ClearCase, use clearfsimport to perform brute force update" and "How can I use ClearCase to “add to source control …” recursively?".
With the -rmane option, it will even remove files which are no longer present in the source folder. See "Remove unused source code files".
We use ClearCase as control version system.
In our system sometimes we make releases without some developers commits because of time limit.
For example I made some changes in six classes but another user did changes in all or some of them also. And I have to commit code without his changes. So I scan my files with previous versions so that I can revert his changes. But it's a slow and boring process.
Is there another way to do that? Maybe an extension or a script?
The only way to automate that process is through:
subtractive merge or negative merge (as described in this IBM article):
cleartool merge -to filename -delete -ver \main\branch\version_number
cset.pl, which can take all the checkins of an UCM activity and cancel them.
See "Clearcase: how to rollback all changes on specific branch?".
But this is for UCM (which might not be your case)
In both cases, the idea is to create a new version which cancels the version of your other developer.
Hi I wanted to know if there is a way to do cleartool findmerge without creating .contrib files. Its a nuisance to have to remove them after merging.
It depends on your version of ClearCase and type of merge, as detailed in this technote:
The .contrib files are generally used to compare the file's previous contents with its new after-merge version; moreover, these files are view-private and can be removed.
There has been discussion around the ability to allow the end-user to disable/enable the .contrib creation; however, with UCM, since all checkouts involved in deliver or rebase activities are reserved, there is no chance of loss changes as a result of the merge.
The .contrib file, in regards to UCM, does not serve the same purpose, or hold the same significance as with base ClearCase.
Change request (RFE) RATLC00608266, was opened to improve the logic used for leaving .contrib files after a deliver or rebase operation. There is no danger for loss of data as a result of the .contrib not getting created.
This behavior has changed in ClearCase 7.0. where feature level 5 was introduced. When using the native client, contrib files are no longer generated when merges occur during deliver and rebase (the Rational ClearCase Remote Client continues to create and use these files)
So with CC7.x and for deliver/rebase types of merge (ie UCM merges), you can aboid the contrib files.
Not with CCRC or base ClearCase merges (which is used by a cleartool findmerge).
That is why that same technote details ways to remove multiple .contrib files in one command (like for /R %i IN (*.contrib) do del %i or del /s *.contrib* for Windows).
When I check out a file in ClearCase it asks me if I want to check out the file "Reserved" or "Unreserved". What are the differences between these types of checkouts and when are the appropriate times to use them?
As mentioned in "What are the basic clearcase concepts every developer should know?", ClearCase support a locking mechanism which is both:
"pessimistic": reserved checkout doesn't actually prevent other people to do their own checkout, but they will have to wait for the person who has the file checked out as "reserved" to do the check in: nobody can check-in until that person does the first check-in (then each other user will have to merge his/her version with the latest checked-in file)
Note: a "reserved" checkout can release its lock and be made unreserved, either by the owner or the administrator;
"optimistic": unreserved checkout which means (if nobody use a reserved checkout on the same file): the first one to check-in can do it without any other operation, the other ones will have to merge their work with the latest checked-in file.
In term if usage policy:
Usually, reserved checkout is fine since it allows you to make your changes with a "high prioritization": they have to be taken into account first.
For local modifications which don't have to be checked-in right away, an unreserved checkout is enough.
For local modification which don't have to be checked-in at all, hijacked file or eclipsed files are enough (so, no checkout at all)
Notes:
A cleartool checkout/checkin is not the same as:
svn checkout/git checkout, which are updating a working repository with the content of a revision/commit, as opposed to checkout a version of a file: set of files vs. one file.
"checkin": svn commit/git commit which registered changes of possibly multiple files to the repo (remote for SVN, local for Git), as opposed to creating a new version for one file.
Git itself would not have "file locking" (reserved checkout). Only system using Git might offer that feature, like Git LFS.