[p4] Finding the workspace name: is p4config mandatory?
Jeff A. Bowles
jab at pobox.com
Sun Feb 24 17:29:46 PST 2008
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.)
Perforce Consulting Partner and Certified Trainer
On Fri, Feb 22, 2008 at 10:21 PM, Dave Lewis <dlewis78731 at gmail.com> wrote:
> 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,
> On Fri, Feb 22, 2008 at 5:06 PM, Steve M. Robbins <steve at sumost.ca> wrote:
> > 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
> > On Fri, Feb 22, 2008 at 09:43:24AM -0600, Steve M. Robbins wrote:
> > > 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 . 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
> > >
> > > 
> > >
> > > _______________________________________________
> > > perforce-user mailing list - perforce-user at perforce.com
> > > 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-----
> > _______________________________________________
> > 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
Jeff Bowles - jeff.a.bowles at gmail.com
More information about the perforce-user