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

Thu May 3 18:54:41 PDT 2007

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 