I have a question regarding perforce. I need to setup a scheme where there are 2 versions, a QA and a Production version. I need to be able to submit code, test the change and push it through to production. The development and production versions will be mostly the same, however there are a few differences, such db host names, include paths, etc...
I would also like t have the ability to have personal versions that could be tested before they are pushed to the QA.
Yes, I have to use perforce.
Does anyone know how to set something like this up? This will be on *nix based OS. I would like to write either a bash or Perl script to handle this.
Thanks,
Your help is really appreciated.
Ok so Production is the "Final Destination". You'll have a branch from Production to QA such that when you want to submit from QA to Production you'll do a Reverse Integration. Similarly your devs can have personal branches from QA such that to submit to QA they'll do a Reverse Integration.
Submitted changes can be checked easily in Perforce just by double-clicking the Changelist.
Is there something specific you need help with?
I'll just add that you can maintain divergence by integrating (p4 integ) and then resolving with the -ay (accept yours) option. That gives you merge credit but doesn't actually copy the changes. That way you can tell Perforce that you want to ignore certain changes that shouldn't ever really be merged, and then you won't be bothered with them anymore.
Related
I would like to reserve a 'snapshot' after Perforce sync. Rather than applying sync to all directory tree, I would like to generate a patch file. I will apply manually and checking if the result (after compiling and running simple test cases) satisfies. I am going to do sync officially if result is OK. If it is NG, I can revert to previous 'snapshot' and continue without hard steps of rolling-back.
I can rely on 'patch' since it supports 'undo'. Telling perforce not to sync but to generate patch, how can I do that?
I appreciate if you can guide me how to automate via script. The steps on p4v is OK.
Regards,
Toan Le
As mike and raven suggested, those are good points.
But also you can use branching strategies - make your source code into 2 branches. one for test branch and one for release branch. but here you will have to work on integration/merging as well. best would be to validate your check in perforce using any CI tools (such as hudson, curisecontrol) as part of incremental build and running all the required test cases automated.
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.
Apologies if the name of the question is confusing.
I'm a bit new to version control (sadly) and feel like I'm not using things in the right way, so I've come for some help.
Basically, my situation is that I have two files I've branched off the trunk and edited. The changes in those files are pretty big, so they are to be thoroughly tested on staging before being pushed to production. What I'm confused about is how to sync them into staging if the client view there is the trunk itself. I can't modify the client view to sync from my branch since the sync has to occur from a specific account used by my entire group. Is there a way to say "sync from..." or something along those lines, in a command? Maybe specify a new client view inside of the sync statement?
Any ideas would be helpful. Thanks!
I'm not sure what is the "account" in your description. client, user?
I guess that in the long term you will have to relinquish the constraint that "into staging ... the client view there is the trunk itself". If you do development in branches, and then integrate them back into the trunk after testing, you'll need to be able to use the test environment on some development branch.
Anyway:
p4 help sync
p4 help usage
p4 -c STAGING sync //...
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've been doing some research into finally automating our Development builds and still have one nagging question that I'm hoping the StackOverflow community can solve for me.
My understanding is that an IntervalTrigger when setup properly will check VSS every X seconds for changes and if it finds a modified file, will run my tasks. One of my tasks would be to checkout the AssemblyInfo files and update the version numbers. After these files are updated they would be checked back into VSS.
Thinking about this solution it doesn't make much sense because in my mind, I'm forcing the check for changed files to true every time the trigger fires. Am I missing something here? Is there a way of doing this without triggering an automatic build on the AssemblyInfo check-in?
You can use a Filtered Source Control Block to exclude certain files from the trigger.
I just posted a bunch about my default build process here which may be of some interest to you: SVN Website Development and Deployment Solution
The way I usually configure my projects with CC.NET is to have two project blocks per solution. One configured as an interval trigger that does nothing more than get the latest from my repository, build the solution, and run unit tests. The other is a schedule trigger that does all the things the other one does, but actually publishes a build. This includes changing version numbers, publishing files, etc. This might work in your case, since the change in version would cause the interval project to trigger, but only once.
Checking the automatically generated AssemblyInfo into the version control system is a bad idea, don't do it. You'll get a lot of noise (50% of all commits!) in your history. Also, it does not give you any new information - you can always pull this from VCS. Have your build script autogenerate those files is a good practice, but don't push those changes back!