[p4] Determining which files a user has checked in between twodates
Tetrick, Cary
ctetrick at midway.com
Fri May 4 10:28:44 PDT 2007
Hey Mark,
Here is how we solved that problem -
We have a separate branch that we call "PublishedApps"
The branch contains the executables, and anything closely tied to it
like config files, compiled scripts, ect.
Artists and designers get this branch merged into their workspace in
place of the current working version of the tech.
So artists are always working with a known, stable version of the code
while tech changes are being made.
When there is a need to "publish" code there may need to be some
coordination between tech and design, but most of the time, artists
don't need to worry that their work no longer fits the current code.
We have this built into our continuous integration system, but you could
do it with some scripts.
-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Mark Allender
Sent: Thursday, May 03, 2007 8:55 PM
To: Rick Macdonald; perforce-user at perforce.com
Subject: Re: [p4] Determining which files a user has checked in between
twodates
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
More information about the perforce-user
mailing list