headers
Jeff A. Bowles | 1 Mar 2008 01:15
Picon
Favicon

Re: [p4] Adding a Changelist # to C++ code...?

He's using "ant" conventions, because anyone who can will use "ant" for Java
compilations...
But it's a really easy substitution, to instead run a very simple script
that runs "sed" (or perl or ...) to replace  <at> change.list.number <at>  with the
exact "p4 changes -m1 -s submitted //depot/codelinename/..." answer.

The question itself, is easy to put into the wrong category.

It's really a "how do I generate this extra file at build-time to include in
the release" question.  Take your build-nerd aside and show him/her this
thread, couched in this language.

  - Jeff Bowles

ps. I spoke about this at the Perforce 1999 (or was it 2000?) User
Conference.  I had two versions of that file - the official-build was
created at build-time, but the checked-in version in development builds had
a different hard-coded string.  (Something about how it was built from a
development workspace, so the binary wasn't official.)

On Tue, Feb 26, 2008 at 12:42 AM, Troughton, Robert <rtroughton <at> midway.com>
wrote:

> Hi,
>
> Thanks for the reply - this sounds like exactly what we need. What do I
> do with the code that you pseudo'd, though...? Is there somewhere that I
> can compile this such that our server will do this?
>
> Sorry... I've not done much work with Perforce other than using the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nittin chawala | 1 Mar 2008 07:37
Picon
Favicon

[p4] P4 C/C++ API's experience

Hi,

  I want to write my own custom client using Perforce C/C++ Api's.

  http://www.perforce.com/perforce/loadsupp.html

  Does anyone have good/bad prior experience in that. Is it similar to P4PERL API's ?

  --

       
---------------------------------
 Download prohibited? No problem. CHAT from any browser, without download.
_______________________________________________
perforce-user mailing list  -  perforce-user <at> perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user
Permalink | Reply | 1 comment |
headers
Nittin chawala | 1 Mar 2008 08:32
Picon
Favicon

Re: [p4] Limiting users ability to create new branches

How would you differentiate if someone is branching or renaming/moving files around because use has to use
"p4 integ" for this purpose also ?

  --

Robert Cowham <robert <at> vaccaperna.co.uk> wrote:
  As well as protections, you can use a pre-submit trigger to check on newly
branched files and their locations.

For example:

http://public.perforce.com/guest/robert_cowham/perforce/utils/triggers/index
.html

There are a couple of examples which ensure that people at least name their
branches in accordance with certain standards. Keeps the namespace clean and
tidy and prevents typos etc.

There is also the pro-active education side of things to find out why they
are creating so many, to show some of the issues and to educate them as to
the error of their ways. The latter can, on occasion, be helped by
application of said baseball bat :) 

> -----Original Messag-----
> From: perforce-user-bounces <at> perforce.com 
> [mailto:perforce-user-bounces <at> perforce.com] On Behalf Of 
> Jamison, Shawn
> Sent: 27 February 2008 14:22
> To: perforce-user <at> perforce.com
> Subject: [p4] Limiting users ability to create new branches
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen Vance | 1 Mar 2008 15:11

Re: [p4] P4 C/C++ API's experience

It is not similar to P4Perl. If you understand the C/C++ API many things 
about P4Perl are clear, but there's not much about P4Perl that will help 
you with the C/C++ API.

Robert Cowham has some writings on his blog and did a presentation at 
the User Conference on using the C/C++ API. That and Perforce's 
documentation in the tarball comprise the extent of the documentation as 
I know it. There are also several projects in the Public Depot that may 
be useful as examples. WebKeeper is one example that I know off the top 
of my head.

Steve

Nittin chawala wrote:
> Hi,
>    
>   I want to write my own custom client using Perforce C/C++ Api's.
>    
>   http://www.perforce.com/perforce/loadsupp.html
>    
>   Does anyone have good/bad prior experience in that. Is it similar to P4PERL API's ?
>    
>   --
>
>        
> ---------------------------------
>  Download prohibited? No problem. CHAT from any browser, without download.
> _______________________________________________
> perforce-user mailing list  -  perforce-user <at> perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff A. Bowles | 1 Mar 2008 21:13
Picon
Favicon

Re: [p4] Limiting users ability to create new branches

That is, well, sort of the main hassle with that strategy.
Me, I'd have a trigger that does this:

(1) "p4 describe -s" on the changelist. Might need to do "p4 opened".
     - if nothing opened for the operation of branch or integrate, the
trigger succeeds.
(2) Run "p4 resolved" to see what was merged/branched from where. (You might
need
    to run "p4 -c workspacename resolved" and even then, it's possible that
you'll have
    a hassle with client workspaces that have "Host:" specified in the spec.
Look up
    "p4 -H machinename" if necessary.)
(3) Using Perl/Python/Ruby but not Unix shell/DOS ".bat" files, compare the
two
     lists: files that are being branched/integrated and the "resolved"
output. This will allow you
     to definitively know what is being branched from where, and to where.
     - For each of the files being branched/integrated, compare against a
master list
     or template. I would hard-code it for the first draft of the script,
perhaps table-driven
     but not too sophisticated: "main to release/1.0 is okay, the other
direction is okay".
     Perhaps even wildcards that you can recognize in your Perl/Python/Ruby
script,
     such as "//depot/main/.*" to "//depot/releases/\d\.\d/.*" is okay.
     - Do not forget that main->main and releases/1.0 -> releases/1.0 (and
so on) is
     okay, which takes care of renames within branches but forbids them
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olle Hallin | 2 Mar 2008 22:50
Picon

Re: [p4] Jira integration: use jobs or not?

Hi,

I'd say that you should go for #2 in your list below.

In this setup, the p4 jobs exist only to support the p4 tool set, so you
could say that it is JIRA-centric. (The set of p4 jobs corresponds to the
subset of JIRA issues that represent code changes.)

We use JIRA+p4 this way, with great success.

The developers appreciate that they are relieved from memorizing JIRA issue
names.
(This works provided that they have setup their JobView properly, e.g.,
"assignee=ollehallin ^issuestatus=closed").

It also increases the quality of the integration, since the risk for typos
is eliminated.

HTH,
Olle Hallin

2008/2/29, Dan Halbert <halbert <at> everyzing.com>:
>
> Hi - I am asking some advice from those of you who use Jira with Perforce.
>
> We are switching from Bugzilla to Jira for bug tracking. We do not use
> P4DTI. Instead, we have a simple homegrown integration with Bugzilla
> using a submit trigger. Every submit must include one or more Bugzilla
> bug numbers in the description. The submit description is added as a
> comment to the bug. This enforces matching bugs with fixes.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jamie.Echlin | 3 Mar 2008 06:55

Re: [p4] Jira integration: use jobs or not?

> I'd say that you should go for #2 in your list below.

I agree. Furthermore I have disabled the changelist indexing, and
disabled the module that displays the P4 Changes tab in jira.

Other than the good reasons already listed for using jobs over relying
on changelist comments, is that it's still easy to see what jobs have
been fixed by changelists even after integrating to other branches
(fixes -i). If you rely on changelist comments this becomes difficult.

I don't have strong feelings between 2 and 3, I take the project mgmt's
lead on that, and set it up on a project by project basis. BTW, it's not
a "hidden job", it's just that the checkbox is "hidden".

I also restrict the area that jira indexes in perforce to one file, if
you have many changelists it can take a long time to index the whole
depot unless you do this.

Cheers, jamie

> -----Original Message-----
> From: perforce-user-bounces <at> perforce.com 
> [mailto:perforce-user-bounces <at> perforce.com] On Behalf Of Olle Hallin
> Sent: 03 March 2008 05:50
> To: perforce-user <at> perforce.com
> Subject: Re: [p4] Jira integration: use jobs or not?
> 
> Hi,
> 
> I'd say that you should go for #2 in your list below.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ildefonzo Arocha | 3 Mar 2008 10:14
Picon

[p4] Scripting with perforce, pitafalls ...

Hello Perforcers,

Is it me or does anyone else find that even for the simplest task,
scripts have to handle and validate a lot of possible errors/warnings.

I am relatively new with Perforce.  In the last months I have been
developing some administrative and end-users scripts.  It has been a
challange though, no matter what I do, there is always some little
detail that makes my scripts fail.

On some situations some warnings are sent out as information messages
so parsing the output for "error" is not possible, same examples:

> p4 -s add -n project.r
error: project.r - protected namespace - access denied.
exit: 0
==> OK

> p4 -s add project.xml
error: project.xml - file(s) not in client view.
exit: 0
==> OK

> p4 -s add -n test.p
info: //xp/i2/main/ui/test.p#1 - opened for add
info1: //xp/i2/main/ui/test.p - also opened by iar <at> main
exit: 0
==> Not Ok?

> p4 -s add test.p
(Continue reading)

Permalink | Reply | 5 comments |
headers
Nittin chawala | 3 Mar 2008 13:07
Picon
Favicon

Re: [p4] Scripting with perforce, pitafalls ...

Yes so better to check for command success pattern instead of error .

  About exit status P4 always have been returning 0, i recently filed a enhancement request with P4 on this,
ideally they should have returned non-zero exit status for failed commands.

  ---

  
Ildefonzo Arocha <ilde.web <at> gmail.com> wrote:
  Hello Perforcers,

Is it me or does anyone else find that even for the simplest task,
scripts have to handle and validate a lot of possible errors/warnings.

I am relatively new with Perforce. In the last months I have been
developing some administrative and end-users scripts. It has been a
challange though, no matter what I do, there is always some little
detail that makes my scripts fail.

On some situations some warnings are sent out as information messages
so parsing the output for "error" is not possible, same examples:

> p4 -s add -n project.r
error: project.r - protected namespace - access denied.
exit: 0
==> OK

> p4 -s add project.xml
error: project.xml - file(s) not in client view.
exit: 0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff A. Bowles | 3 Mar 2008 17:08
Picon
Favicon

Re: [p4] Scripting with perforce, pitafalls ...

Step on: know what tools are available for the script writer.
Option #1:  normal 'p4' command usage.

Example:  "p4 sync" / "p4 files" / "p4 submit -i"

Good/bad:

   - simple, but you are parsing formatted output.
   - Filenames with embedded spaces are headaches.
   - Getting status / success-fail is harder.

Option #2: Use "p4 -s" for easier status / success-fail processing.

Example:  "p4 -s sync" / "p4 -s files"

Good/bad:

   - simple, but you are parsing formatted output.
   - Filenames with embedded spaces are headaches.
   - Getting status / success-fail is slightly easier. You still need to
   decide whether the command worked or not. ("Exit status" from the 'p4' tells
   you whether the protocol worked, not whether the command worked, so '-s'
   helps.)

Option #3: Read up on tagged output.

Example:  "p4 -Ztag  sync" / "p4 -Ztag files"

Good/bad:
(Continue reading)

Permalink | Reply | 3 comments |

Gmane