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

Wed Jan 17 12:20:00 PST 2007

That is exactly what I AM trying to do... but just not from a client-side
process.  We have 60+ developers, and it's not worth the pain of trying to
get them all to configure/setup their environment or follow a new process to
do this.

Most of the P4 work is done via Eclipse or Idea, and adding that client-side
process is not an option... it just won't get done.

I appreciate you trying to analyze the situation to eliminate or change the
requirements, but regardless, those ARE the requirements and the solution
has to fit into them.

I've found a solution that will do what I need, and I am testing it a bit
more to ensure it works as I expect, and will post when it's finalized.

Thanks...

...jeff

On 1/17/07, Matthew Janulewicz <MJanulewicz at greendotcorp.com> wrote:
>
>  So then ant doesn't actually pull the code?
>
>
>
> If 'twere me, I'd provide a mechanism for indicating what was pulled at
> the time it was pulled/synced. At some point someone, or some thing, has to
> run a 'p4 sync' command. What arguments do you use? Do you pull the latest
> code? Or do you pull a specific changelist? Either way, a script, or a
> human, can dump the results to a file that's included in the tarball as a
> manifest. I guess I don't understand why the output of the sync command
> can't be included in a file at the time the sync actually happens, wherever
> or whenever that happens.
>
>
>
> Do the dev's make the tarball themselves on the commandline, or does ant
> do it? I think it would be rather difficult to guarantee the integrity of
> the tarball unless ant pulled the code and built it at the same time. If ant
> pulls the latest code, then add a call to 'p4 counter change', then 'p4 sync
> …' to that change number, do the build, create tarball. All the info should
> end up in the build log, which I would presume is in the tarball from dev's
> …? Or somewhere?
>
>
>
>
>
> -Matt
>
>
>  ------------------------------
>
> *From:* jeff grant [mailto:t.swat.consulting at gmail.com]
> *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
>
>
>