[p4] Finding the workspace name: is p4config mandatory?

[Steve M. Robbins]

Hi,

A recent thread on this list concerns adding a changelist number to
C++ code, to which Robert Cowham responded with a suggestion to run a
couple of p4 commands in the root of the workspace [1]. This is easy
to script, but it assumes that the workspace name is available to the
script.

As a build manager, I would prefer to write one script to be used by
all developers. Each developer has their own workspace, so the
workspace name cannot be embedded in the script. Therefore it seems
that the script has to obtain it from the environment. So either you
have to have it set in the environment (but then who uses just one
client?) or you have to have a p4config file properly set up.

Is that the case -- or is there another possibility that I'm
overlooking? Is p4config therefore mandatory even for a shop that
otherwise uses p4v exclusively?

Now, if p4config is mandatory, is there a way to generate them
automatically? I have been crafting each of mine by hand, which is
a real nuisance. It strikes me that the first "p4 sync" could write
the config file for me.

Thanks,
-Steve

[1] http://maillist.perforce.com/pipermail/perforce-user/2008-February/023342.html

[Ivey, William]

Anything that runs from the command line is going to need information
about P4 either from the environment, it's own command line or the
registry on Windows.

I use P4CONFIG on all my build machines - I don't see what's hard
about putting one file per workspace down. Once that's done, the
script can find the client name by parsing the output from p4 info
or p4 client -o, etc.

-Wm

-----Original Message-----
From: perforce-user-***@perforce.com
[mailto:perforce-user-***@perforce.com] On Behalf Of Steve M.
Robbins


Hi,

A recent thread on this list concerns adding a changelist number to
C++ code, to which Robert Cowham responded with a suggestion to run a
couple of p4 commands in the root of the workspace [1]. This is easy
to script, but it assumes that the workspace name is available to the
script.

As a build manager, I would prefer to write one script to be used by
all developers. Each developer has their own workspace, so the
workspace name cannot be embedded in the script. Therefore it seems
that the script has to obtain it from the environment. So either you
have to have it set in the environment (but then who uses just one
client?) or you have to have a p4config file properly set up.

Is that the case -- or is there another possibility that I'm
overlooking? Is p4config therefore mandatory even for a shop that
otherwise uses p4v exclusively?

Now, if p4config is mandatory, is there a way to generate them
automatically? I have been crafting each of mine by hand, which is
a real nuisance. It strikes me that the first "p4 sync" could write
the config file for me.

Thanks,
-Steve

[1]
http://maillist.perforce.com/pipermail/perforce-user/2008-February/02334
2.html

[Steve M. Robbins]

Hi,

I should clarify a few things.

1) It is perfectly possible to use p4v without setting anything in
the environment. Not the workspace, not P4PORT, not even P4CONFIG.
This is how we operate today.

2) We typically want developers to be able to build on their machine.

3) The developer build is set off outside of p4v: from an IDE, or
command line "make", etc.


Item #2 implies that I don't just have a problem of setting up 1
p4config file for N workspaces on a build server, but an NxM problem
where M is the number of developers. (Alternatively, each developer
has to set up N config files.)

Granted, this can be done. It's not rocket science. But it gives you
NxM chances to make a mistake while setting up something that should
be mechanically generated (as is done by both CVS and Subversion).
When I get to a point like this I figure either I'm abusing the tool,
or the the tool is too limited.

So what you folks using p4v with large M do?

Thanks,
-Steve

Post by Steve M. Robbins
Hi,
A recent thread on this list concerns adding a changelist number to
C++ code, to which Robert Cowham responded with a suggestion to run a
couple of p4 commands in the root of the workspace [1]. This is easy
to script, but it assumes that the workspace name is available to the
script.
As a build manager, I would prefer to write one script to be used by
all developers. Each developer has their own workspace, so the
workspace name cannot be embedded in the script. Therefore it seems
that the script has to obtain it from the environment. So either you
have to have it set in the environment (but then who uses just one
client?) or you have to have a p4config file properly set up.
Is that the case -- or is there another possibility that I'm
overlooking? Is p4config therefore mandatory even for a shop that
otherwise uses p4v exclusively?
Now, if p4config is mandatory, is there a way to generate them
automatically? I have been crafting each of mine by hand, which is
a real nuisance. It strikes me that the first "p4 sync" could write
the config file for me.
Thanks,
-Steve
[1] http://maillist.perforce.com/pipermail/perforce-user/2008-February/023342.html
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Dave Lewis]

Actually, I would not embed a changenumber for developer builds, I
would only do that for official builds. I think the environment is
too variable on a developer's machine to produce reliable information.

As some of the replies have shown, the highest changenumber a client
is synced to does not mean you'll get the same set of files if you
sync to that number. That sounds like double talk, but consider
working on a change. Files are open for edit, and the developer does
a test build. In this case, the changenumber info is misleading.
Then the developer submits the change, and now, the client shows that
the highest changenumber in the client's files is the just submitted
changenumber. The developer, however, may not have synced to the
latest changes before submitting their work. Again, the changenumber
will be misleading.

Considering that there is no control over many of these factors, I
would choose a different approach that indicates some uncertainty with
regard to the status of a developer build. A possibility might be
that if the client name is not obvious from the environment, to label
the build with its date/time info and "dev" status.

I suppose you could sync the client to a known state before building
it, but I think that's a bit intrusive for a build to do in the
development situation.

I am not too familiar with P4V, but in P4WIN, you can add tools to the
tool menu. If there is a similar feature in P4V, then starting a
build from P4V can then supply the correct client name, etc.

just a thought,

dave

Post by Steve M. Robbins
Hi,
I should clarify a few things.
1) It is perfectly possible to use p4v without setting anything in
the environment. Not the workspace, not P4PORT, not even P4CONFIG.
This is how we operate today.
2) We typically want developers to be able to build on their machine.
3) The developer build is set off outside of p4v: from an IDE, or
command line "make", etc.
Item #2 implies that I don't just have a problem of setting up 1
p4config file for N workspaces on a build server, but an NxM problem
where M is the number of developers. (Alternatively, each developer
has to set up N config files.)
Granted, this can be done. It's not rocket science. But it gives you
NxM chances to make a mistake while setting up something that should
be mechanically generated (as is done by both CVS and Subversion).
When I get to a point like this I figure either I'm abusing the tool,
or the the tool is too limited.
So what you folks using p4v with large M do?
Thanks,
-Steve

Post by Steve M. Robbins
Hi,
A recent thread on this list concerns adding a changelist number to
C++ code, to which Robert Cowham responded with a suggestion to run a
couple of p4 commands in the root of the workspace [1]. This is easy
to script, but it assumes that the workspace name is available to the
script.
As a build manager, I would prefer to write one script to be used by
all developers. Each developer has their own workspace, so the
workspace name cannot be embedded in the script. Therefore it seems
that the script has to obtain it from the environment. So either you
have to have it set in the environment (but then who uses just one
client?) or you have to have a p4config file properly set up.
Is that the case -- or is there another possibility that I'm
overlooking? Is p4config therefore mandatory even for a shop that
otherwise uses p4v exclusively?
Now, if p4config is mandatory, is there a way to generate them
automatically? I have been crafting each of mine by hand, which is
a real nuisance. It strikes me that the first "p4 sync" could write
the config file for me.
Thanks,
-Steve
[1] http://maillist.perforce.com/pipermail/perforce-user/2008-February/023342.html
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHv1V/0i2bPSHbMcURArqWAJ9kLMHz9VdS6CMdMu1YNl7QxfNBDACffqOx
6wxWqLKl3c88Xq4QjFuAW50=
=0z+C
-----END PGP SIGNATURE-----
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Jeff A. Bowles]

In a talk at the Perforce User's Conference, a while back (1999, I believe),
I gave a talk in which I described auto-generating a 'version.java' as part
of the build. It would *always* be built for overnight / release builds,
and *never* built for developer builds. (A copy stored in Perforce for that
situation who say, "This was compiled on a developer desktop - so do not
include resultant binaries in formal builds or formal testing" or something
obnoxious like that.)
Worked nicely. The QA folks understood that "if it doesn't have an official
release string, we can't install it onto a testing machine" (although there
were sometimes QA folks who would assist in debugging needs for developers
with their time or machines; let's be nice, now.)

There is a possibility that a developer could fill in that file with his/her
own stuff, making a developer build masquerade as an official one, so if
security were a concern you'd need to have a [slightly] more complex
strategy. (Better thumbscrews, also.)

-Jeff Bowles
Perforce Consulting Partner and Certified Trainer

Post by Dave Lewis
Actually, I would not embed a changenumber for developer builds, I
would only do that for official builds. I think the environment is
too variable on a developer's machine to produce reliable information.
As some of the replies have shown, the highest changenumber a client
is synced to does not mean you'll get the same set of files if you
sync to that number. That sounds like double talk, but consider
working on a change. Files are open for edit, and the developer does
a test build. In this case, the changenumber info is misleading.
Then the developer submits the change, and now, the client shows that
the highest changenumber in the client's files is the just submitted
changenumber. The developer, however, may not have synced to the
latest changes before submitting their work. Again, the changenumber
will be misleading.
Considering that there is no control over many of these factors, I
would choose a different approach that indicates some uncertainty with
regard to the status of a developer build. A possibility might be
that if the client name is not obvious from the environment, to label
the build with its date/time info and "dev" status.
I suppose you could sync the client to a known state before building
it, but I think that's a bit intrusive for a build to do in the
development situation.
I am not too familiar with P4V, but in P4WIN, you can add tools to the
tool menu. If there is a similar feature in P4V, then starting a
build from P4V can then supply the correct client name, etc.
just a thought,
dave

Post by Steve M. Robbins
Hi,
I should clarify a few things.
1) It is perfectly possible to use p4v without setting anything in
the environment. Not the workspace, not P4PORT, not even P4CONFIG.
This is how we operate today.
2) We typically want developers to be able to build on their machine.
3) The developer build is set off outside of p4v: from an IDE, or
command line "make", etc.
Item #2 implies that I don't just have a problem of setting up 1
p4config file for N workspaces on a build server, but an NxM problem
where M is the number of developers. (Alternatively, each developer
has to set up N config files.)
Granted, this can be done. It's not rocket science. But it gives you
NxM chances to make a mistake while setting up something that should
be mechanically generated (as is done by both CVS and Subversion).
When I get to a point like this I figure either I'm abusing the tool,
or the the tool is too limited.
So what you folks using p4v with large M do?
Thanks,
-Steve

Post by Steve M. Robbins
Hi,
A recent thread on this list concerns adding a changelist number to
C++ code, to which Robert Cowham responded with a suggestion to run a
couple of p4 commands in the root of the workspace [1]. This is easy
to script, but it assumes that the workspace name is available to the
script.
As a build manager, I would prefer to write one script to be used by
all developers. Each developer has their own workspace, so the
workspace name cannot be embedded in the script. Therefore it seems
that the script has to obtain it from the environment. So either you
have to have it set in the environment (but then who uses just one
client?) or you have to have a p4config file properly set up.
Is that the case -- or is there another possibility that I'm
overlooking? Is p4config therefore mandatory even for a shop that
otherwise uses p4v exclusively?
Now, if p4config is mandatory, is there a way to generate them
automatically? I have been crafting each of mine by hand, which is
a real nuisance. It strikes me that the first "p4 sync" could write
the config file for me.
Thanks,
-Steve
[1]

http://maillist.perforce.com/pipermail/perforce-user/2008-February/023342.html

Post by Steve M. Robbins

Post by Steve M. Robbins
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHv1V/0i2bPSHbMcURArqWAJ9kLMHz9VdS6CMdMu1YNl7QxfNBDACffqOx
6wxWqLKl3c88Xq4QjFuAW50=
=0z+C
-----END PGP SIGNATURE-----
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Ivey, William]

#1 is true only because P4V is its own environment with the
appropriate settings. You had to make them at some point for
P4V to operate, so making them a second time for a different
environment makes sense.

#2 Nothing prevents that.

#3 Make is the perfect environment to do this. That was our
first method and is still in use seven years later.

Post by Steve M. Robbins
Item #2 implies that I don't just have a problem of setting
up 1 p4config file for N workspaces on a build server, but
an NxM problem where M is the number of developers.

No, your problem is creating one, incredibly simple, template
file which the developer renames and modifies once per workspace,
and probably never has to deal with again. All they have to fill
in is the user ID (once for all workspaces) and the client
(which could also be once for all branches if you only have
a single client covering all the branches).

Of course they will have to set P4CONFIG in their environment,
but it's strictly cut and paste from a common prototype. (Put
the instructions in the template file as comments.)

If you don't trust the developers to get that much right, how
did you trust them to install and configure P4V?

-Wm

-----Original Message-----
From: perforce-user-***@perforce.com
[mailto:perforce-user-***@perforce.com] On Behalf Of Steve M.
Robbins


Hi,

I should clarify a few things.

1) It is perfectly possible to use p4v without setting anything in
the environment. Not the workspace, not P4PORT, not even P4CONFIG.
This is how we operate today.

2) We typically want developers to be able to build on their machine.

3) The developer build is set off outside of p4v: from an IDE, or
command line "make", etc.


Item #2 implies that I don't just have a problem of setting up 1
p4config file for N workspaces on a build server, but an NxM problem
where M is the number of developers. (Alternatively, each developer
has to set up N config files.)

Granted, this can be done. It's not rocket science. But it gives you
NxM chances to make a mistake while setting up something that should
be mechanically generated (as is done by both CVS and Subversion).
When I get to a point like this I figure either I'm abusing the tool,
or the the tool is too limited.

So what you folks using p4v with large M do?

Thanks,
-Steve

Post by Steve M. Robbins
Hi,
A recent thread on this list concerns adding a changelist number to
C++ code, to which Robert Cowham responded with a suggestion to run a
couple of p4 commands in the root of the workspace [1]. This is easy
to script, but it assumes that the workspace name is available to the
script.
As a build manager, I would prefer to write one script to be used by
all developers. Each developer has their own workspace, so the
workspace name cannot be embedded in the script. Therefore it seems
that the script has to obtain it from the environment. So either you
have to have it set in the environment (but then who uses just one
client?) or you have to have a p4config file properly set up.
Is that the case -- or is there another possibility that I'm
overlooking? Is p4config therefore mandatory even for a shop that
otherwise uses p4v exclusively?
Now, if p4config is mandatory, is there a way to generate them
automatically? I have been crafting each of mine by hand, which is
a real nuisance. It strikes me that the first "p4 sync" could write
the config file for me.
Thanks,
-Steve
[1]

http://maillist.perforce.com/pipermail/perforce-user/2008-February/02334
2.html

Post by Steve M. Robbins
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user