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

Fri May 4 10:50:07 PDT 2007

Here's one way:
p4 sync //...#have, at goodbuild

That will only sync the files in the label 'goodbuild' if they're newer than
the have list.  There are some drawbacks though, if they inadvertently sync
to #head, there's no easy way to get back.

Another possibility would be to create a label for each user.  Then you
could use a scheduled task or a trigger to update everyone's label when a
new good build comes out or they submit a change.  The advantage being that
you'd full control over the script, and no need for a script on each user's
machine.  The downside is performance creating/updating all those labels.

On 5/3/07, Mark Allender <marka at volition-inc.com> wrote:
>
> I'm actually separating work by artists, not programmers.  For the
> purposes of this discussion, all of an artists work is not dependent on some
> other artist.  They'll work on some asset, level, or animation and check
> that in and move on to the next thing that they are doing.
>
> In fact, we are not replicating any kind of previous environment.   What
> I'm trying to solve is the issue of maintaining a stable build for 80+
> people, when 60+ of those people are non programmers.  Builds break.  That
> is a fact.  But when it's code, programmers are usually quick to fix and
> check in a fix.  With some of the types of assets that we work with (and
> asset flow through our pipelines), a change might work for an artist
> locally, but when combined with other assets and new code, it might
> break.  Asset fixes can take longer than code fixes to identify and fix.  So
> I'm basically trying to minimize downtime for 80+ people.
>
> We could do the branch route, but I'm worried about the size and number
> (branching 100K+ files across 40 or so people -- sounds like a management
> nightmare).  I understand that is probably the proper way to do what I'm
> trying to do, but I'm looking for, um, cheaper alternatives.  Ultimately
> though, what I want to do is scriptable, so I'll probably just go that
> route.
>
> I find this discussion interesting because I might be missing alternative,
> and plus, talking about process configuration is an interesting topic.  If
> anyone wants to talk at the conference about it, please find me.
>
> ________________________________
>
> From: perforce-user-bounces at perforce.com on behalf of Rick Macdonald
> Sent: Thu 5/3/2007 6:52 PM
> To: perforce-user at perforce.com
> Subject: Re: [p4] Determining which files a user has checked in between
> two dates
>
>
>
> Mark -
>
> Sounds like a difficult way to separate work-in-progress by dozens of
> programmers. What if more than one programmer changes the same file with
> dependencies on other files? Isolating files changed by any individual
> programmer might not give a working set of files.
>
> Did you by any chance load up a Perforce depot to mimic a development
> and build system from some other environment? What you are asking for
> seems un-Perforce-like to me.
>
> A common way to isolate a user's work is to make a branch from Label A,
> and the user works in that branch. If notice comes that Label B is now
> the latest known build, the user pulls down the files from Label B into
> his branch. This way, he always has the latest known good build along
> with his most up-to-date work in his branch, which is exactly what you
> asked for. When his work is done, he integrates his work back to the
> parent to become part of the next known good build.
>
> ...RickM...
>
> Mark Allender wrote:
> > 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
> >>
> >>
> >
> > _______________________________________________
> > 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
>