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

[Rick Macdonald]

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
>
>