[p4] Adding new file to changelist file set using a trigger?

Wed Jan 17 14:25:25 PST 2007

Hi Jeff,
Does the tar ball get created within a Perforce workspace, before it is
sent to the secure machine?  If so, you could simply ask Perforce to
which changelist the workspace is synced (Tech Note 51), then do what
you want with that info.  More specifically, this could all be done in a
target--creating the tar ball and the performing the query.

Ed

> -----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:25 AM
> To: Matthew Janulewicz
> Cc: Albrecht, Matt; perforce-user at perforce.com
> Subject: Re: [p4] Adding new file to changelist file set 
> using a trigger?
> 
> 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
> >
> >
> >
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> 