[p4] p4 submit question

[Steve Cogorno]

The behavior of P4 submit is quite perplexing. Why can't I include more
than one file spec on the command line? Often I want to do something like
this:

p4 submit //depot/{tree1,tree2}/foo/bar

The shell expands this into

p4 submit //depot/tree1/foo/bar //depot/tree2/foo/bar

Of course this is rejected because submit only takes a single argument.


Is there a reason why only one file is permitted on the command line? It
sure makes code submission more difficult that it needs to be.

Steve Cogorno
Sun Microsystems

[Rick Macdonald]

Post by Steve Cogorno
The behavior of P4 submit is quite perplexing. Why can't I include more
than one file spec on the command line? Often I want to do something like
p4 submit //depot/{tree1,tree2}/foo/bar
The shell expands this into
p4 submit //depot/tree1/foo/bar //depot/tree2/foo/bar
Of course this is rejected because submit only takes a single argument.

"p4 help submit" indicates that a filespec can go on the command line, but
I think it has to be a p4 filespec, quoted from the shell expansion if
necessary. For example: p4 submit //depot/tree.../foo/bar

...RickM...

[Dave Lewis]

Date: Thu, 21 Oct 1999 17:48:21 -0800 (PDT)
The behavior of P4 submit is quite perplexing. Why can't I include more
than one file spec on the command line? Often I want to do something like
p4 submit //depot/{tree1,tree2}/foo/bar
The shell expands this into
p4 submit //depot/tree1/foo/bar //depot/tree2/foo/bar
Of course this is rejected because submit only takes a single argument.
Is there a reason why only one file is permitted on the command line? It
sure makes code submission more difficult that it needs to be.

its funny, but I was only marginally aware you could use submit in
this manner. Most everybody here does a submit of the default changelist;
if there are files in there I don't want to submit, I edit them out
before completing the submit.

In the gui, it is easy to drag files into as assortment of changelists,
corresponding to different fixes/features etc. I thought that was a pretty
cool feature of the gui, even though I'm about a 99% command line guy.

dave

[Nick Barnes]

Post by Steve Cogorno
The behavior of P4 submit is quite perplexing. Why can't I include more
than one file spec on the command line? Often I want to do something like
p4 submit //depot/{tree1,tree2}/foo/bar
The shell expands this into
p4 submit //depot/tree1/foo/bar //depot/tree2/foo/bar
Of course this is rejected because submit only takes a single argument.

In this example, you might be able to do something like this:

p4 submit //depot/tree\*/foo/bar

but it's not elegant.

This is a problem I often face. My work procedures often involve
submitting changes to a number of files at once. Sometimes there's a
sensible filespec for these files (e.g. prototype/ABCD/...), sometimes
there isn't. Quite often I have a large number of files open in my
default changelist, and editing out the files I want is a lengthy and
error-prone task. I would certainly appreciate a change to p4 submit
to allow multiple filespecs.

Nick B

[Dave Foglesong]

-----Original Message-----
From: Nick Barnes <***@pobox.com>
To: Dave Lewis <***@vignette.com>
Cc: ***@Eng.Sun.COM <***@Eng.Sun.COM>;
perforce-***@perforce.com <perforce-***@perforce.com>
Date: Friday, October 22, 1999 2:14 AM
Subject: Re: [p4] p4 submit question

Post by Nick Barnes
This is a problem I often face. My work procedures often involve
submitting changes to a number of files at once. Sometimes there's a
sensible filespec for these files (e.g. prototype/ABCD/...), sometimes
there isn't. Quite often I have a large number of files open in my
default changelist, and editing out the files I want is a lengthy and
error-prone task. I would certainly appreciate a change to p4 submit
to allow multiple filespecs.

You could generate the submit form as a text file (via a script or
whatever), and then pass it to the submit command with the -i switch, such
as
p4 submit -i < c:\submit.txt
(You can also feed the submit form into the command directly from stdin and
bypass the file generation step, but I like having the option of verifying
the contents before doing the submit.)

I do something like this all the time in Perl to submit only specific files,
instead of everything that is opened on the local client.

The downside of this method is that you'd need your script to parse the
filespecs you pass it so it would properly generate the right lists of files
to include in the form.

Or, if you knew in advance that specific files were going to go together on
checkin, go ahead and create a blank change list, then open the files by
specifiying that change number, eg,
p4 change (this should return a changelist number, such as 20000)
p4 edit -c 20000 //depot/path/to/file/foo.c
etc.
p4 submit -c 20000

You can use p4 reopen to move existing open files into a new change list, so
you can get them out of the default change list.

[Steve Cogorno]

Post by Nick Barnes
p4 submit //depot/tree\*/foo/bar
but it's not elegant.
This is a problem I often face. My work procedures often involve
submitting changes to a number of files at once. Sometimes there's a
sensible filespec for these files (e.g. prototype/ABCD/...), sometimes
there isn't. Quite often I have a large number of files open in my
default changelist, and editing out the files I want is a lengthy and
error-prone task. I would certainly appreciate a change to p4 submit
to allow multiple filespecs.

Sounds like your situation mirrors mine closely. We have a policy that one
changelist = one bug (whenever possible). That changelist should also
encompass *all* versions of the codelines that need repair. It is quite
difficult to write a filespec for that.

And, like you, I have tons of files open in the default changelist.
It is a pain to edit them out. If I make a mistake, then I am truly hosed,
because there is no way to undo a submit.

Steve Cogorno
Sun Microsystems

[Steve Cogorno]

Post by Dave Foglesong
You could generate the submit form as a text file (via a script or
whatever), and then pass it to the submit command with the -i switch, such
as
p4 submit -i < c:\submit.txt

Yeah, I've tried this too. But, if I use this method, the filespecs need to
be in depot syntax. Using the "p4 submit <path>" allows the path to be a
client path. It's sometimes difficult to map from the client to the depot
in a generic way.


Steve Cogorno
Sun Microsystems

[Dave Foglesong]

You can use "p4 fstat" to get the local and depot paths to a file. Fstat
only works on files that already exist in the depot, but that doesn't sound
like it would be a problem in your scenario.

In my scripts I have a routine which works by examing the results of the
"where" command, but I only use this because I also need to determine depot
locations for folders and files that haven't yet been added. The results
returned by fstat is much simpler to parse.

-----Original Message-----
From: Steve Cogorno <***@eng.sun.com>
To: dfogleso (Dave Foglesong) <dfogleso (Dave Foglesong)>
Cc: ***@pobox.com <***@pobox.com>; ***@vignette.com
<***@vignette.com>; ***@eng.sun.com
<***@eng.sun.com>; perforce-***@perforce.com
<perforce-***@perforce.com>
Date: Friday, October 22, 1999 11:27 AM
Subject: Re: [p4] p4 submit question

Post by Steve Cogorno

Post by Dave Foglesong
You could generate the submit form as a text file (via a script or
whatever), and then pass it to the submit command with the -i switch,

such

Post by Steve Cogorno

Post by Dave Foglesong
as
p4 submit -i < c:\submit.txt

Yeah, I've tried this too. But, if I use this method, the filespecs need

to

Post by Steve Cogorno
be in depot syntax. Using the "p4 submit <path>" allows the path to be a
client path. It's sometimes difficult to map from the client to the depot
in a generic way.
Steve Cogorno
Sun Microsystems
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Scott Blachowicz]

Post by Dave Foglesong
You can use "p4 fstat" to get the local and depot paths to a file. Fstat
only works on files that already exist in the depot, but that doesn't sound
like it would be a problem in your scenario.
In my scripts I have a routine which works by examing the results of the
"where" command, but I only use this because I also need to determine depot
locations for folders and files that haven't yet been added. The results
returned by fstat is much simpler to parse.

If all you need is the depot syntax for some files, I'd say that
"where" is a bit easier to parse....just do

p4 where files | awk '{print $2}'

to get the list of server-side depot files instead of something like:

p4 fstat files | awk '$2 == "depotFile" {print $3}'

(all ignore error checking).

Unless, of course, I missed something in my quicky test commands.

***@seaslug.org

[Greg Spencer]

It seems to me that this would a really simple change for the perforce folks
to make -- I think they must have simply overlooked multiple arguments when
they implemented the "give-submit-a-path" feature. It would be backward
compatible, and wouldn't preclude future enhancements to the submit
function.

I'd suggest writing to ***@perforce.com, and asking them for this
feature -- they're quite responsive to this sort of change.

-Greg.

----- Original Message -----
From: Steve Cogorno <***@Eng.Sun.COM>
To: Perforce List <perforce-***@perforce.com>
Sent: Thursday, October 21, 1999 7:48 PM
Subject: [p4] p4 submit question

Post by Steve Cogorno
The behavior of P4 submit is quite perplexing. Why can't I include more
than one file spec on the command line? Often I want to do something like
p4 submit file://depot/{tree1,tree2}/foo/bar
The shell expands this into
p4 submit file://depot/tree1/foo/bar file://depot/tree2/foo/bar
Of course this is rejected because submit only takes a single argument.
Is there a reason why only one file is permitted on the command line? It
sure makes code submission more difficult that it needs to be.
Steve Cogorno
Sun Microsystems
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Fredric]

Post by Greg Spencer
It seems to me that this would a really simple change for the perforce folks
to make -- I think they must have simply overlooked multiple arguments when
they implemented the "give-submit-a-path" feature. It would be backward
compatible, and wouldn't preclude future enhancements to the submit
function.
feature -- they're quite responsive to this sort of change.

This one-file-parameter-only feature for submit has bugged me ever since
it was introduced. I gladly add my voice to the choir that wants this
fixed.

/Fredric

PS. Is it just me or is this list turning into some kind of referendum
(is this the word?) for enhancements to p4 ;-).
I do not mind but I just thought that maybe it would be a good idea
for Perforce to set up a web page where we could drop our votes. This
might help them to prioritize.