[p4] p4 submit w/o an editor

Shawn Hladky p4shawn at gmail.com
Thu Jul 13 15:21:07 PDT 2006


Perforce provides a C++ API.  From that API, the community has created
interfaces for Python, Perl, Ruby, COM, .Net and others.  In each of those
interfaces, it's a snap to manipulate forms.  I really don't expect Perforce
to devote resources to make shell scripter's lives a little easier, when
they haven't done that for other technologies.  If the demand is strong
enough, my guess is someone will take the API, and write a program to make
form processing easier for shell scripting.  Frankly, I really don't want
Perforce spending my portion of support $ on things that I can easily script
around.  I'd much rather see them working on big-ticket items, like server
replication, better rename support, and improving proxy servers.  Those are
all features that can't be scripted.

On 7/13/06, Weintraub, David <david.weintraub at bofasecurities.com> wrote:
>
> I don't think anyone has problems with Perforce's using text forms as a
> means of input. It is certainly a lot easier to fill out one of these
> forms than trying to enter a half dozen parameters with multiple command
> line parameters. However, you also to take advantage of a command line
> interface for scripting purposes. For example, when I want to automate
> builds, create makefiles, or triggers. And, it seems Perforce did
> everything in their power to make this task as difficult as possible.
>
> For example, let's say I want to do a dump of all the source into a
> particular directory. The best way to do this is to make a temporary
> client, sync it, and then delete it. It would be handy if I could do
> something like this:
>
>     $ p4 client -client "temp$$" -root "$PWD" -view "//depot/dir/dir/...
> //temp$$/..."
>     $ p4 -c "temp$$" sync
>     $ p4 client -d "temp$$"
>
> Takes all of three lines. Instead, I have to build a form in a text
> file, then redirect that input back into the "p4 client" command. A much
> messier process.
>
> The other extremely frustrating issue are all of the Perforce commands
> returning zero error codes even if the command does something
> "unexpected". To draw a parallel, the Unix "grep" command returns a zero
> error code if it finds the regular expression you're looking for, and a
> non-zero value otherwise. This makes it simple to do things like this:
>
>     if grep "foo" barFile.txt
>     then
>         echo "Found the text!"
>     else
>         echo "Text not found"
>     fi
>
> However, this doesn't work for Perforce commands:
>
>    if p4 print //depot/mydir/myfile.txt
>    then
>       echo "File exists!"
>    else
>       echo "No such file!"
>    fi
>
> This will print "File exists!" even if the file doesn't exist in the
> archive.
>
> Then there's the fact that you can't easily verify whether or not a
> client, branch, label, or other specifications exist. It would be nice
> if you could do this:
>
>    if p4 labels $label > /dev/null
>    then
>        echo "Label $label already exists!"
>        exit 2
>    fi
>    echo "Creating label $label"
>    [...]
>
> Unfortunately, the "p4 labels" command doesn't take any parameters. It
> will only print out the entire list. Maybe if this would have worked:
>
>     if p4 label -o $label > /dev/null
>     then
>        echo "Label $label already exists!"
>        exit 2
>     fi
>     echo "Creating label $label"
>
> But, in this case, if label $label doesn't exist, the text form for it
> will be created.
>
> All of these issues makes writing scripts for things like triggers much
> more difficult that it has to be. I spend a lot of time with my scripts
> attempting figure out how I would even know if something didn't work in
> Perforce, or how to get around a particular limitation in Perforce's
> command line. For example, when I was working in ClearCase, I had a
> build script that determined the previous label used, then automatically
> incremented that label number and create a new label. In ClearCase, this
> could be done in just a few lines. It is much more difficult to do
> something like this in Perforce.
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Jeff Grills
> Sent: Thursday, July 13, 2006 2:06 PM
> To: 'Zoltan Grose'; perforce-user at perforce.com
> Subject: Re: [p4] p4 submit w/o an editor
>
>
> I'd like to take the opportunity to come out in support of Perforce's
> approach of text-based forms.  I think it's an ingenious way to provide
> dialog-box type interactions in a text-only environment; just about
> every system I've ever worked with comes with a text editor )or there is
> at least one available if you choose to install it).  When I'm ssh'd
> into a remote machine and only have text, it's really nice - I don't
> think I could devise a better solution if I tried.
>
> If I'm going to be automating perforce actions from a "strong"
> programming language such as Java, I have all the tools necessary to
> build up the text block to send into p4, so I don't think that's really
> an issue for me.  I'm certainly not opposed to tighter integrations with
> a language (like the p4 ruby and perl interfaces) - that can make it
> super easy to do complicated things with perforce.  It's the case of
> trying to automate perforce commands that use forms from a "weak"
> programming language like bash or NT batch that makes things difficult.
>
> I'd agree that p4 submit, in particular, would benefit from being able
> to be driven completely with command line arguments.  It would certainly
> be convenient at times.
>
> j
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Zoltan Grose
> Sent: Thursday, July 13, 2006 11:43 AM
> To: perforce-user at perforce.com
> Subject: Re: [p4] p4 submit w/o an editor
>
> Forget the command line. A scriptable, object-oriented API is the way
> forward. :)
>
> In particular a first-class Java APi would rock my socks.
>
> -z
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



More information about the perforce-user mailing list