On Linux, after a review has been completed on a CL(changelist), the
p4 submit
fails validation indicating a file has changed after the review. Example:
Submit validation failed – fix problems then use 'p submit -c 123456'.
'changeContent' validation failed: This file has been changed between the time it was reviewed and the time it was committed, starting on line 2:
But, the file hasn't changed. This doesn't happen all the time, just some times. When it happens, it doesn't matter how many reviews get completed on the CL, it will never submit. We're forced to move the changes over to Windows and review/submit them from there. Is there any solution to it?
The short answer is that your changeContent trigger is rejecting the submit. Fixing or disabling this trigger should allow the submit to proceed.
As far as speculating about what about this trigger could be broken, Bryan's suggestion about line endings is a good one. Maybe your Linux client is using share and one of your Windows clients is using unix? That's a recipe for a bad time for the Linux client.
Related
As mentioned in the question, I often encounter the situation shown in the picture below:
Problems demonstrate
I'm using the Clean... directive here, not the Reconcile Offline Work...directive
Clean...
This bug was fixed in the server in release 2016.2:
https://www.perforce.com/perforce/doc.current/user/relnotes.txt
#1382996 (Job #74886, #86396) **
'p4 clean' would fail to sync files when needed when they
are exclusively opened by another client. This has been
fixed.
Double check that you're on release 2016.2+ of the server; if you are, you should be at the very least be able to use p4 clean as a workaround (e.g. by adding it as a custom tool to P4V).
We are using adyen Payment, since couple of months we started having an error on every 5-mins "No callbacks found for cron job adyen_payment_process_notification_queue"
Unfortunately we are not able to find the string having "adyen_payment_process_notification_queue" even in the vendor/adyen folder or in the app/code, can anyone guide us from where this could be coming from or what is the possibility for having such errors or how to find its resolutions.
Due to this error all our order status is being stuck in Processing as shipment team tried to updated the status via cron but may be due to this error Order statuses are not updating.
We have also tried checking but there is no any clue related to this error. :
var/log/system.log
var/log/magento.cron.log
var/log/exception.log
var/log/adyen/cronjob.log
var/log/adyen/notification.log
Here is the output of my crontab -e
I'm running p4 interchanges -b my_branch, and I get a ton of results, the first one being a changelist that we integrated a long time ago.
So I try to integrate again, but p4 integrate -b my_branch //...#changelist,#changelist just returns "All revision(s) already integrated".
The only way to unblock this is to do a forced integration (-f in the integrate command) and then simply accept target (-at when resolving), and that works - p4 interchanges then no longer lists this changelist.
But how can Perforce get into this state to begin with? This happened after we've done a bunch of integrating across multiple branches, but I nothing that I'd think would cause a changelist to become "unintegrated" somehow.
This is on a 2014.1 server.
Thank you for specifying your server version.
The 'p4 interchanges' command can give the "All revision(s) already integrated" message with misleading results when cherry-picking is involved.
There is a command line example here:
http://answers.perforce.com/articles/KB_Article/Cherry-Picking-Integrations
You could also be affected by a bug that was patched in 2014.1 listed here in the server release notes:
http://www.perforce.com/perforce/doc.current/user/relnotes.txt
Bugs fixed in 2014.1 PATCH5
#880506 (Bug #71725) **
The istat.mimic.ichanges configurable controls the reporting
of revisions between stream and parent. If set, istat will
not report cherry-picked revisions already present in the target.
The default behavior will report any changes not credited, even
when the content may already be in the target.
If you would like, you can pull the most recent build of the server P4D for your OS from our ftp site: http://ftp.perforce.com/perforce/r14.1/
REFERENCE
http://answers.perforce.com/articles/KB_Article/Integration-Changes-Reporting
I'm working in new application written in Siebel 8.1, issue appears when I'm trying to replay script and I can't handle that.
Replay Output:
Error -27086: Auto-correlation callback function
"flCorrelationCallbackParseWebPage" failed (rc=1) for parameter
"Siebel_Parse_Web_Page40"
web_reg_save_param("Siebel_Parse_Web_Page40",
"LB/IC=",
"RB/IC=",
"Ord=1",
"Search=Body",
"RelFrameId=1",
"AutoCorrelationFunction=flCorrelationCallbackParseWebPage",
"AutoCorrelationDll=LrwiSiebelCorrelationWrapper",
LAST);
I have done all steps for prepare record options from: http://software-qe.blogspot.se/2008/01/siebel-7x-record-and-replay-for.html
I'm using Loadrunner 11.52 (Siebel Web protocol), IE8.
We've been using the autocorrelation library for quite a few years on my team and we see this a lot. Unfortunately, it's not an easy problem to diagnose.
First I would check your test results and your VUser log to see if something happened before the autocorrelation failed. (Make sure your logging is set to parameter substitution in runtime settings).
Check your parameter files for extra spaces, commas, etc. Sometimes I've seen that error right after it rejects something about your parameter file.
Worst case scenario, your script is corrupted and you'll have to start over. We've gotten in the habit of making frequent backups of our scripts just because of this issue. Usually, we'll be able to start from our backup and continue or create a new script and paste the old code in. Autocorrelation error "magically" goes away with the same code in a new script.
If auto(magical)correlation does not work then use manual correlation.
Record twice with same data: Compare. You will find session, state and time data.
Change the credentials: Re-record. Compare. You will find credential related correlation
Change the business record but keep the same business process. Re-Record. You will find the business related correlation.
Do not expect autocorrelation to provide a magical working script. You have about a 0.0001% chance of that happening without LoadRunner script development intervenetion.
I'm using cruisecontrol.net for integration builds along with external source control. The source control (GETMODS) script fails, this is fine and I know why, but the build stays green for some reason when it's expected to fail. CruiseControl shows the exception on the output window below, so why doesn't the build fail?
ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed:
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute
(ProcessInfo processInfo)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.GetModifications(ProcessInfo info, DateTime from, DateTime to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ExternalSourceControl.GetMod ifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl sourceControl, IIntegrationResult lastBuild, IIntegrationResultthisBuild)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.GetModifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.Project.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Integrate()
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Run()
I guess the reasoning would be that the source control block is only used:
to check if there are any changes in the source code which require a rebuild, and
to get all the source code needed for the build.
If this action fails it has nothing to do with the source code and the commits to it. It's an infrastructural problem that prevents the build from happening at all therefore technically the build hasn't fails. It hasn't even started.
With a version control block inside cc.net, it search for repository modification.
If cc.net is unable to contact the repository, it can't start the job.
The result is an exception.
If you want to ignore this, this can help (simple retry counter) !
Can we tell CruiseControl.NET to ignore source control timeout errors?
<maxSourceControlRetries>5</maxSourceControlRetries>
<stopProjectOnReachingMaxSourceControlRetries>true</stopProjectOnReachingMaxSourceControlRetries>
<sourceControlErrorHandling>ReportOnRetryAmount</sourceControlErrorHandling>
I believe this is a recent change to ccnet. We are running two versions on separate machines. Version 1.4 breaks the build if it can't get to our svn repository, but version 1.5 will not break the build. I haven't looked into it yet, but there may be a switch to force 1.5 to break on failure to retrieve code.