[p4] Obtain a clean workspace [Re: Is there a way to audit aworkspace?]
rickmacd at shaw.ca
Tue Aug 18 10:53:54 PDT 2009
I've always assumed this clean workspace issue is because they don't
trust their build tools and environment and/or the people who have
access to them. I too am interested in hearing what people say. Are
there known Perforce problems?
I don't think I've wiped an entire system build workspace clean (on 8
different platforms) in over 10 years. I have nightly incremental
builds. I'm not in a critical environment though, and I do appreciate
that there are situations where a zero-tolerance for a messed-up build
is required such that the sync and build time is accepted.
Matt Janulewicz wrote:
> I'm still wondering why people 'distrust' Perforce so much and want
> clean workspaces so often. The tool was obviously purchased to feel a
> need and I still think there are enough facilities built in to
> Perforce to not *have* to do clean syncs all the time.
> Our build processes rarely do clean syncs for day-to-day continuous
> builds. In the games industry, for instance, you might be talking
> about dozens of gigs of syncing for a build. Why bother? Leverage the
> tool, re-educate, play to the strengths of Perforce instead of working
> around perceived weaknesses.
> Paul-Marc Bougharios wrote:
>> Another way of having a "clean" workspace is to delete and recreate
>> it from
>> Perforce side only.
>> It can be done by doing:
>> p4 have > have.log
>> p4 client -o > client.log
>> p4 client -d
>> p4 client -i < client.log
>> p4 -x have.log flush
>> If there is a portion not needed, one would "un-sync" the path concerned
>> before executing the above commands.
>> As a reminder, "un-syncing" can be done by:
>> p4 sync //PATH/...#0
>> Paul-Marc Bougharios
>> On Tue, Aug 18, 2009 at 6:53 PM, Richard Kistruck
>> <rhsk at ravenbrook.com>wrote:
>> > (Note change of topic, from auditing an existing workspace, to
>> obtaining a
>> > new clean one).
>> > On 2009-08-18Tue, at 04:31, Slava Imeshev wrote:
>> >> p4 sync -f a bullet-proof way of having a clean build
>> >>> workspace, which is a good idea for release/QA builds.
>> >> I should have mentioned that "bullet-proof" implied emptying
>> >> the build workspace before running p4 sync -f.
>> > "sync -f" DOES NOT overwrite open files. If you want to obtain a
>> > workspace, you must revert all open files first, or no amount of
>> > will help you.
>> > <
>> > (And, even worse, when you have an open file, "p4 sync -f" gives a
>> > potentially misleading report of "myfile.txt - file(s) up-to-date."
>> -- try
>> > it! Your p4 version may differ...)
>> > To obtain a clean workspace, starting from nothing, one suitable
>> > is:
>> > 1. p4 revert mywork/...
>> > 2. rm -rf mywork
>> > 3. p4 sync -f mywork/... at NNN
>> > Discussion: The "revert" is necessary to close any p4-opened
>> files. You
>> > probably want to check for them with "p4 opened mywork/..." before
>> > reverting them all! For anyone who doesn't speak Unix, the "rm
>> -rf" removes
>> > the "mywork" directory and everything it contains.
>> > (One more note: If you are doing this from a script, and relying on
>> it for
>> > a product that carries your reputation, then you had better also
>> make sure
>> > your script checks for and halts if there are any errors from the p4
>> > commands, such as from the network going down!)
>> > Again: this is the procedure I use, to obtain a small clean
>> workspace from
>> > scratch; corrections or improvements are welcomed.
>> > Richard Kistruck
>> > Ravenbrook Limited
>> > _______________________________________________
>> > 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
> perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user