[p4] Determining which files a user has checked in between two dates

[Mark Allender]

Right -- but what I'm after is getting a specific set of changes
inbetween dates -- i.e. those changes that a particular user submitted.
We can (and will) use the newer label feature (and have used it in other
automatic build processes here).

Say we make a label after the known good build.  We might get 100's of
changes in between that good build and the next one.  I need to cherry
pick out a particular users changes between those points, not just every
changelist.

Builds that fail wouldn't get a label.  Whether or not I look for
changes between labels (or changelist numbers as David suggested) that
still doesn't really get me to where I _think_ I'd like to be.

Here is some basic timeline of what I'd like:

- Known Good build (labeled A)
- 100's of changelists (from dozens of users)
- A particular user syncs to label A (to get a working build on his
machine).  This sync could put older versions of files on his client
than he had -- it would be like removing his work from his local machine
even though his changes are in the depot
- This user should then be able to sync his changes and only his back to
his workspace so that he can work with a good build (along with his most
up-to-date work).



> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Jeff 
> A. Bowles
> Sent: Thursday, May 03, 2007 2:02 PM
> To: geir.myrestrand at falconstor.com
> Cc: perforce-user at perforce.com
> Subject: Re: [p4] Determining which files a user has checked 
> in between two dates
> 
> "What he said."
> 
> I would use the newer label spec feature, so that you could say
> "the label project1_build96_Mar15 is //depot/main/... up to change
> 12381". It's a small amount of programming (the "Revision:" field
> and the "View:" section of the label spec - perhaps 10-12 lines of
> Unix shell script at most) and has very low database storage overhead
> compared to using "p4 labelsync" for this situation.
> 
> "Normal-folk" remember names like project1_build96_Mar15 a lot more
> than they remember "main up to 12381."
> 
> (Of course, all important labels are "locked" and perhaps even
> owned by a system id, right?)
> 
>    -Jeff Bowles
>    Perforce Consulting Partner
> 
> On 5/3/07, Geir A. Myrestrand <geir.myrestrand at falconstor.com> wrote:
> > I would recommend that you rather label your builds, then 
> you can easily
> > generate a list of changes between the two labels.
> >
> > I used this approach for an automated change log. This also makes it
> > trivial to reproduce a build, as you can just sync to that label. It
> > also makes it easier for whoever is going to debug an issue in the
> > product if they easily can find out what source file 
> revisions went into
> > a particular build. An approach is to use a label name 
> consisting of the
> > product name, version and build number. Of course, if you insist on
> > using a date then you can create a label name using the 
> date as the name
> > (but include the time if you may run more than one build per day).
> >
> >
> > --
> >
> > Geir A. Myrestrand
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
> 
> 
> -- 
> ---
> Jeff Bowles - jab at piccoloeng.com
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>