Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Component/s: p4-plugin
-
Labels:None
-
Environment:Server is linux x86_64.
Slave is Windows Server 2003 Standard Edition, 5.2.3790 Service Pack 2 Build 3790
-
Similar Issues:
Description
No build has been triggered for days even though a change to the sources has been checked in.
This is the Perforce Polling Log:
Started on Feb 8, 2011 3:20:57 PM
Looking for changes...
Using node: twinpeaks-vm
Using remote perforce client: hudson-OE-HUBS-DW-TWINPEAKS-VM
[OE-HUBS-DW] $ "C:\Program Files\Perforce\p4" workspace -o hudson-OE-HUBS-DW-TWINPEAKS-VM
Saving modified client hudson-OE-HUBS-DW-TWINPEAKS-VM
[OE-HUBS-DW] $ "C:\Program Files\Perforce\p4" -s client -i
Last sync'd change was 663559
[OE-HUBS-DW] $ "C:\Program Files\Perforce\p4" counter change
[OE-HUBS-DW] $ "C:\Program Files\Perforce\p4" -s changes '"//depot/IT_Engineering/DIAL - New QC App/..."@663559,@673276'
No changes found.
Done. Took 1.2 sec
No changes
This is what I get on the slave server when I do a "p4 changes":
--------------
Z:\>p4 -u rolem -c hudson-OE-HUBS-DW-TWINPEAKS-VM -s changes "//depot/IT_Engineering/DIAL - New QC App/..."@663559,@673241
info: Change 665714 on 2011/02/03 by fmartin@lglt-fmartin 'Eliminate 'Customer Requests' i'
exit: 0
So Perforce reports that something has been checked in, but the Perforce plugin doesn't seem to be seeing it.
One other thing worth mentioning: We have checked "Use View Mask" in the Advanced button of Perforce settings. The View mask is:
"//depot/IT_Engineering/DIAL - New QC App/..."
and the "Use mask when polling" checkbox is checked.
Attachments
Activity
Now I've figured out the combination that works: Remove the quotes from the path in the View Mask. That seems obvious now, but it was not initially obvious because, without the quotes the same path fails in the client spec. (I think that is true. At the very least, the quotes work in the client spec.)
So it might be argued that this is not really a bug. You just have to know not to use quotes in the View Mask.
But I would still argue that it is a bug, the reason being that the View Mask is supposed to be a subset of the client spec. The way I got my path for the View Mask was by cutting and pasting from the client spec. It seems to me like, whatever is supported in the client should work in the View Mask.
I leave it to you to decide what to do with this "bug". For me, I now know the "work around", so my job once agains works.
Michael Curtiss
added a comment - Now I've figured out the combination that works: Remove the quotes from the path in the View Mask. That seems obvious now, but it was not initially obvious because, without the quotes the same path fails in the client spec. (I think that is true. At the very least, the quotes work in the client spec.)
So it might be argued that this is not really a bug. You just have to know not to use quotes in the View Mask.
But I would still argue that it is a bug, the reason being that the View Mask is supposed to be a subset of the client spec. The way I got my path for the View Mask was by cutting and pasting from the client spec. It seems to me like, whatever is supported in the client should work in the View Mask.
I leave it to you to decide what to do with this "bug". For me, I now know the "work around", so my job once agains works. It looks like we came to same conclusion independently. Thanks for you help with this.
Michael Curtiss
added a comment - It looks like we came to same conclusion independently. Thanks for you help with this. 
I've sifted through the code a bit, and I think it should work if you simply remove the double quotes from that line in your view mask. Can you give that a shot? The config page might complain about it not being valid, but just ignore it. If that fixes it, I'll add some code to strip them out before passing them onto the command line.