5.2 perforce submit doesn't allow wildcards

[epu]

Depot syntax wildcards are a feature we've come to expect from the p4 command line. In order to use the p4 action instead of a text shell, depot syntax wildcards (/..., /*) need to work whenever they would also work in the command line.

I got the following email from the other visual build user at work, and need to pass it on.


In Visual Build version 5.0 the P4 submit command would automatically run a P4 opened command which would allow me to use wildcards in the files I wanted to submit. Now with version 5.2 I have to run the P4 opened card separately and use the output for the P4 submit command because it doesn't support wildcards. It seems like it's easier just to do everything on the command line.

Dave


Currently, I try prototyping some commands with the p4 action, but this (bug|feature) keeps us from seriously using the p4 action. We've gone back to using p4 commands from DOS or PERL, or work around it by opening a specific new changelist with DOS+P4 and returning the changelist number, opening files into that changelist, and then submitting the changelist with no files specified.

Also, it's my impression (although I haven't verified it recently) that sometimes the DOS-path wildcards would work when the depot ones wouldn't. So listing a file as C:\path\to\files\* might work when //depot/path/to/files/* wouldn't.

Best regards and thanks for the fine product.

-e

[kinook]

There were some changes made in VBP 5.1 to the Perforce action in regard to how submit is dealt with, mostly bug fixes to properly deal with the default changelist (see http://www.kinook.com/Forum/showthread.php?threadid=229 for details).

In addition, the Opened command is now only issued if the Folders field is empty. The reason for this is so that the action can also delete the named changelist if no files have actually changed and they all get reverted. We expected the normal usage in a build would be

1) Create a changelist using a change command (the Perforce action stores the new changelist # in the P4_CHGLIST temporary macro).

2) Use the open command to open any files that might be changed by the build into the %P4_CHGLIST% changelist.

...perform build logic...

3) Use the submit command to submit the build changelist with all modified files in the build changelist, reverting any unchanged files and deleting the changelist if no files were modified (using a blank Folders field and checking the Revert option).


Are you wanting to use wildcards in some manner that prevents this from working, or setting up your builds differently, or ?

[epu]

Dave says,

Not sure if you want to follow up with this or not but I'll use their method instead of what I was doing. I was trying to submit the contents of a folder which would be //depot/MyFolder/... giving me specific control over what section of my files would be checked in. Since the changelist is a better way of doing that and the %P4_CHGLIST% macro gives me the info I need, I'll start using that.

Dave


I was working around not having the p4 changelist number, so I would p4 change and filter output with perl. Now it sounds like I could reinvestigate that step type when I have time.

Some of my manual p4 steps redirect output to NUL since I don't need to read about all 13000+ files being synced on a clean build in my log file. After looking more closely, it looks like output can be set to none. Is this the same?

One of my steps syncs to #none (//...#none); I wasn't sure of the right place to do this in the p4 action. It seems like the command panel > changelist number field could hold the none keyword, but that didn't work ok.

One of my custom steps returns the p4 revision number of a particular checked in file, so I can update its version strings before I build it. (p4 have //some/file.ext filtered by perl). Is there a simple way to do that?

Other p4 actions work ok; opening files for edit, locking files, reverting files, and deleting open changelists. So it looks like both Dave and I can do a revision of our actions if we have time.

[kinook]

Some of my manual p4 steps redirect output to NUL since I don't need to read about all 13000+ files being synced on a clean build in my log file. After looking more closely, it looks like output can be set to none. Is this the same?
Using a Run Program step, yes (alternatively, you could continue to redirect to NUL if you prefix the command with %DOSCMD% ). The Perforce action proper doesn't currently provide a way to do this, but it's a good suggestion for a future release (although you could prevent the output from going to the log file by temporarily disabling file logging for the step -- see the Logging.bld sample for instance).

One of my steps syncs to #none (//...#none); I wasn't sure of the right place to do this in the p4 action. It seems like the command panel > changelist number field could hold the none keyword, but that didn't work ok.
If that is a valid filespec/wildcard for P4, it would go in the 'Folders and/or files...' field.

One of my custom steps returns the p4 revision number of a particular checked in file, so I can update its version strings before I build it. (p4 have //some/file.ext filtered by perl). Is there a simple way to do that?
A step's output is available in the following step via the %LASTSTEP_OUTPUT% system macro (also accessible in that step's vbld_StepDone script event via Application.ExpandMacros("%LASTSTEP_OUTPUT%")). You would still need to parse the output in script code and use (or store in a temporary macro for later use). See 'system macros', 'scripting' and 'script events' in the help index for more details.

[epu]

Ok, I'll check those out. Thank you.