[p4] Adding new file to changelist file set using a trigger?
jeff grant
t.swat.consulting at gmail.com
Wed Jan 17 10:25:14 PST 2007
What this "really" means is that we have to have a tar ball of our
repository that will be replicated to a machine that doesn't have network
access to the P4 server nor will it have a P4 client on it. (Security
issues, remote locations, etc).
So, just by having a tar ball of any check out from any of our 60
developers, or our 3 CIT machines (continuous integration testing) we have
to be able to have ANT figure out exactly what version it is.
It's confusing, I know, but trust me when I tell you that I've done
everything I can to eliminate this requirement and deal with it in other
ways. The most effective solution for us is what I've described.
As it is right now, we have no branching. Eventually we will, but it will
be trivial to include that information within that file using the same
mechanism that this version number process will use. We can build it out
then if/when we have to. For now, all we need is this number, in a file,
that is managed/updated by the server, without requiring any client-side
configuration or process changes.
As to the builds/releases that will be audited, etc., those are getting
deposited into a totally different repository, as part of our deployment
mechanism. (Sun's N1 System Provisioning Service).
We have clear separation between our development and testing/deployment
environments, and this version number system is assisting us in some
integration issues we're having, specifically with keeping numbering
conventions/etc consistent across disparate systems.
...jeff
On 1/17/07, Matthew Janulewicz <MJanulewicz at greendotcorp.com> wrote:
>
> Might I ask what this really means?:
>
> "... determine the perforce changelist/revision number of the
> currently sync'd
> workspace, WITHOUT having access to the P4 client or server."
>
> If the workspace is synced, then p4 had to do that, right? Is a
> workspace being synced then copied somewhere else?
>
> Ass the other Matt mentioned, the changelist number is *really*
> determined at submission time, so there is no way to guarantee 100% what
> the number is going to be.
>
> Also, to get truly accurate information, you need more data, like what
> branch you're looking at. The changelist number alone does not indicate
> anything but a point in time. If you have, say, a 'dev' branch and a
> 'stable' branch and your build tool doesn't note which one you're
> building from, the changelist number will not accurately (necessarily)
> reflect what code you built from, anyway.
>
> At my current job we're not so stringent about it, but at the last place
> I worked the FDA could audit us and accurate record keeping was a must.
> Every official build we did contained the changelist number, the
> client/workspace that was used, plus what the workspace definition
> looked like at the time the build occurred (since it can change over
> time.)
>
> During the start of the build, can't you just output the results of the
> sync command, then do a 'p4 client -o' to capture the environment?
>
>
> -Matt
>
>
> -----Original Message-----
> From: Albrecht, Matt [mailto:matt.albrecht at zilliant.com]
> Sent: Wednesday, January 17, 2007 8:48 AM
> To: jeff grant; perforce-user at perforce.com
> Subject: Re: [p4] Adding new file to changelist file set using a
> trigger?
>
> Even if you can get the trigger to work well, a problem with this
> technique is that, as soon as you add a new file / updated file into
> Perforce, the current changelist number changes. This may not be a
> problem for you, however, since the only delta would be a single text
> file containing the changelist number.
>
> For an alternative answer, perhaps you could put a "p4" wrapper script
> on the client machines that would generate this file on sync. May not
> be the most optimal way, as it doesn't really work well for tools like
> p4v and p4win.
>
>
>
> > -----Original Message-----
> > From: perforce-user-bounces at perforce.com
> > [mailto:perforce-user-bounces at perforce.com] On Behalf Of jeff grant
> > Sent: Wednesday, January 17, 2007 10:33 AM
> > To: perforce-user at perforce.com
> > Subject: [p4] Adding new file to changelist file set using a trigger?
> >
> > Hello everyone-
> >
> > I am working on some integration issues with ANT and our
> > deployment system
> > (Sun System Provisioning Service) and have come up with the need to
> > determine the perforce changelist/revision number of the
> > currently sync'd
> > workspace, WITHOUT having access to the P4 client or server.
> >
> > The way I see it, I need some sort of file that is
> > automatically maintained
> > by Perforce that only contains a line similar to:
> >
> > perforce.changelist=XXXX
> >
> > where XXXX is the changelist/revision number of the last sync
> > that was done.
> >
> >
> >
> > I've figured out that I need to use either a change-submit or
> > change-content
> > trigger, but the trick is that I want this trigger to add a
> > file (the one
> > containing the above information) to the newly created
> > changelist file set,
> > as I don't see this as being a file that I'd want anyone
> > modifying. Even if
> > they did, it'd get overwritten by the trigger.
> >
> > The process would be something like this:
> >
> > user submits file changes
> > trigger is fired before changelist is committed/saved
> > trigger knows the new changelist number via the %change% variable
> > (arbitrarily = 1234 for this example)
> > trigger creates new version of "p4_rev.txt" with contents of "
> > perforce.changelist=1234"
> > trigger includes new p4_rev.txt as part of the about-to-be-subitted
> > changelist file set
> > changelist files are committed, including new p4_rev.txt
> > --- after some period of time ---
> > someone/something performs a sync, gets changed files,
> > including new version
> > of p4_rev.txt, which SHOULD contain the same value as #HAVE
> > on that client,
> > in this case 1234.
> >
> >
> >
> > Anyone know how to do this? The only way I've figured out
> > how to do this is
> > to have it create a new changelist right after the
> > check-in/submission,
> > meaning your change log would look like this:
> >
> > "real" files included in # 1234
> > pr_rev.txt (containing 1235) in #1235
> > "real" files included in # 1236
> > pr_rev.txt (containing 1237) in #1237
> >
> >
> > Less than ideal, IMO.
> >
> > Anyone have any thoughts/ideas? I haven't seen any examples
> > on how to do
> > that in any of the Perforce documentation or via any Googling, etc.
> >
> >
> > Thanks...
> >
> >
> > ...jeff
> > _______________________________________________
> > 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