I have a horrible habit of checking in source files when our group needs to keep the DB stable for a batch of testing. Is there a way for me to disable checkins for myself and then re-enable when the testing completes? I still need to use perforce to check out files and monitor the status of the DB.. I just would like to disable my ability to do checkins.
Thanks!
Switch your work into a new branch, and then you can submit without affecting the mainline.
Note that this is somewhat backwards from how it should work (the mainline should be branched for stabilization, rather than "freezing" it and forcing everyone else to branch) but the principle of "branch on incompatible submit policy" still applies.
https://www.perforce.com/pdf/scm-best-practices.pdf
You could use a read only client: https://www.perforce.com/blog/vcs/read-only-clients-helix-server-20152
Related
I sometimes forget to commit offline work in perforce as you cannot see them in the pending changelist.
Does anyone know how to force user to put offline work into pending
list or can it be done automatically?
If I were going to force reconcile to be run before submit I would create a custom submit dialog in P4V. The API is detailed here:
http://www.perforce.com/perforce/doc.current/manuals/p4jsapi/p4jsapi.pdf
Try to get yourself in the habit of reconciling even when you know exactly which files you worked on and they're already in a changelist.
Personally, I'm currently working with an IDE that claims to integrate with Perforce but in fact does not actually do anything, so I have to reconcile before any changes are picked up. I remember to scan for changes because it's indispensable.
I have currently 3 codelines in my perforce depot
Main
Development
Release
The idea being changes will be integrated into Main from release and dev branches. But as of now some of the devs are making changes directly to Main branch. Is there a way to freeze check-ins for the "Main" codeline and allow integrations via branch mappings in perforce?
OR if there is any other best practice (restrictions) out there that can be applied to avoid direct check-ins into the Main branch.
Thx
As Adam said, you should use permissions to limit access to the Main branch. You can do this either by using the Admin tool, or by running p4 protect from the command line (as long as you have super user access).
You should limit the permissions for Main to read for most people, and allow write for those you trust to submit to the Main branch. You can also choose to give "normal" users open access instead of read, which will allow them to check files out, but not submit them.
Another thing to consider apart from just setting the permissions is the approach we are running for some of our branches:
We use a review tool (Reviewboard in our case) and have a Perforce trigger in place, which checks if there is a review in ReviewBoard that matches the following criteria:
there is a review associated with the current Perforce change number
the latest review has the "ship it" flag set to True
the reviewer in ReviewBoard is NOT the submitter of the change list.
the list of files in the review matches the list of files in the change list
You could be even more restrictive, e.g. that the reviewer has be to a special person (guard of the branch). The advantage to just setting hard permissions is that you get control over what to submit and in what quality. This would also enable you to submit important bugfixes to the main-branch without prior messing with p4 protect.
In our Perforce workspaces at work, there are a couple of control files that contain branch information that should never be integrated across branches.
Is there a way to tell Perforce to always ignore these files in integrations?
You could set up a branch spec and use that for your integrations.
You may be able to use some type of permissions through p4 protect, so that only the admin can modify them. I know this works for actually checking out and checking in a file, but I'm not sure about integrating it to another branch.
You could write a server-side trigger script that looks for the control file names and filters them out of an integrate.
There's pretty good documentation on triggers. There's a load of examples too in the public Perforce depot.
I am trying to understand what perforce “jobs” provide over an external bug tracking system and just putting the bug ID in the check-in comment.
I was hoping that "job" could help with How do I see if a branch contains a bug fix in Perforce?
Nothing. Take it from someone who endured years of aggravation working with the Perforce/FogBugz integration mechanisms (the latest being the Perforce Defect Tracking Gateway which uses Perforce jobs as part of the integration). They provide very little return on a significant investment in time setting them up and then trying to figure what went wrong when they stop working (which is often).
I now do just what you suggest. I simply put the FogBugz case number in the Perforce check-in comment, then add that Perforce changelist number to the FogBugz case upon resolving it. As simple and reliable as it gets.
We put the issue ID in the comment but also have a Perforce trigger that updates the issue database (JIRA) with the changelist number. During the next build the automated build process also updates the issue with the actual build number.
A very nice part of this implantation is that the trigger gives an error if the issue is not marked as in progress or the developer doing the check-in is not working on the issue. Therefore it is uncommon for a miss-typed issues ID number to get past the checks.
As a bugtracker, Perforce jobs are somewhat basic. They can be created and modified with the P4V GUI client or using p4 job and p4 jobs on the command line.
The idea is for them to serve as a link (a connector as Perforce calls it or an interface as a developer might look at it) to a third party issue management system and basically provide the information which changelists were committed for which issue. The issue management system can then tap into this information using the Perforce Defect Tracking Gateway (PDF documentation here) and generate bugfix charts or statistics for management or whatever.
We are using this with Jira in both directions with some success. The basics worked pretty much straight out of the box, more advanced use cases (such as e.g. which bugs were fixes in which release ?) or integration with other bugtrackers may require modification of the Perforce job model.
One of the advantages over tracking changelist and issue numbers using commit comments is that you can select the job/issue from a dropdown box when you commit a changelist using P4V.
In practice, developers tend to forget to add the job information when they commit a changelist. This can be enforced using Perforce triggers.
I have made some changes in one perforce client, but haven't submitted them. I want to propagate these changes to another perforce client, without submitting the changes in the first client.
Is it possible? If yes how?
Thanks
You cannot do this from within Perforce itself. You will need to perform a manual process:
sync and resolve any conflicts with the changes on Client A
sync Client B
check out target files on Client B
copy files from Client A to Client B
This process could be automated by using commands like p4 changes and p4 describe and OS tools to parse the output (like for in DOS), but this would be overkill in most cases.
check out the new shelving feature in the perforce 9.2 release (currently available in beta)- you can cache your modified files on the server, without having to check them in as a versioned change.
http://blog.perforce.com/blog/?p=1872
Although I didn't work with git-p4, the answer to this question seems to refer to your use case as well: git-p4 and pulling from other repos