[p4] Erasing sync history?

[Jeff A. Bowles]

When I write build scripts, the "remove the old build tree" sequence is
always:
    (1)  "*p4    sync   //whatever/area/it/was/...#none*"
and then, now that the perforce-managed files are gone...
    (2)  "*rm    -fr     /my/workspace/root/dir/area/it/was*"

*That way, at every moment the physical contents of my workspace are
consistent with the db.have / db.working view of my workspace.* (If there's
caching of updates to the database, well, this strategy ignores them. Not a
lot I can do to second-guess that, anyhow!)

In the event of a disk or net surprise, there are fewer assumptions that I'm
relying on.

  -Jeff Bowles


ps. Java users have it good - they have cleaner build processes and can,
usually, just remove a "classes/" directory.  Still, for the formal builds,
I'd recommend the ultimate in caution: start from an empty tree and a fresh
'sync' of the source. (Compilers have been known to corrupt source files, in
the history of the industry. Why guess, when you can retrieve a fresh copy?)


On 9/4/07, Tony Sweeney <sweeney at addr.com> wrote:
>
> Roy Smith wrote:
> > A colleague recently removed a workspace by doing "rm -rf" on the
> > root directory.  He thought he was done working on that branch and
> > wanted to free us some disk space.
> >
> > Some time later, he had to work on that branch again and so he just
> > did a "p4 sync" on that client, and was surprised when only a small
> > number of files appeared.  The answer, of course, is that perforce
> > didn't know he had removed the directory and only updated the files
> > that had changed since his last sync.
> >
> > I know you can do a "sync -f", and told him to do that, but he's
> > looking for something more.  He's looking for a way to tell perforce
> > that the files no longer exist on local storage, so the next time he
> > does a "p4 sync", (without the -f), they come back.
> >
> > Is the answer to do the "rm -rf", and then do a "p4 flush"?  It
> > sounds promising, but it's not really clear from the help text what
> > this is supposed to do.
> >
> > I'm not exactly sure what's motivating him to find something better
> > than "p4 sync -f", but I told him I would research it.  I think he
> > may be worried that keeping track of the metadata about what files
> > he's got in his workspace may be wasting resources on the server.  I
> > told him I thought the storage needed to that was pretty minimal, but
> > that's just a guess.  Is it?
> >
> I can't speak for your colleague, of course, but some of us just don't
> like loose ends.  I believe the technical term is 'anal-retentive'.  You
> can use 'p4 flush' with the #none (or equivalent #0) revision in the
> client to tell Perforce that you no longer have the files.  Just 'p4
> sync ...#none' would do this too, and is the preferred way of purging a
> client in the regular case where you still have the files, since it also
> removes them in the same operation.  In this case, though, the local
> files are already gone, so you only want to update the metadata, which
> is exactly what 'p4 flush' is for.  Clients can vanish for many reasons
> -- overzealous cleanup, failed hard drives and re-imaged machines being
> fairly common cases.  Orphaned have list data bloats the db.have file to
> no good purpose, potentially slows down the server, and increases both
> the size and duration of checkpoint and backup operations, so it
> certainly doesn't hurt to keep on top of it.  But an orphaned client
> have list takes only the same server space as any similar extant client,
> so it isn't necessarily critical...
>
> Tony.
> > -------------------
> > Roy Smith <smith_roy at emc.com>
> > Software Guy, EMC Common Management Group
> > 44 South Broadway, 7th floor
> > White Plains, NY 10601
> > (914) 580-3427
> > AIM: roysmith649
> >
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
> >
> >
>
>
> --
> quis custodiet ipsos custodes? -- Juvenal VI, 347-8
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com