[p4] normdir ???

[Jeff A. Bowles]

The important thing is:
   "If the person has set 'rmdir' on the workspace, then Perforce will
   consider removing the directory when files are removed-from-workspace.
   The directory must be devoid of files - no emacs .bak files, no Mac OS X
   .DS_Store files, no spare .class files, nothing - for the directory
to go away."

That makes it pretty safe.

It's easy to say "that is a punt", but the Perforce rule has been -
forever - that
Perforce will try its best to avoid removing your only copy of
non-stored content.
That includes the .bak file, the .class file, the modified-not-checked-in file.

  -Jeff Bowles


On 12/13/07, Tony Sweeney <sweeney at addr.com> wrote:
> Rick Macdonald wrote:
> > Tony Sweeney wrote:
> >
> >> Roy Smith wrote:
> >>
> >>
> >>> By default, the "normdir" option is set in new client specs.  Why?
> >>> This seems counter-intuitive.  Is there some non-obvious problem I'm
> >>> going to encounter if I set "rmdir" on all my clients?
> >>>
> >>>
> >>>
> >> Consider the case where you sync some source to a directory and run a
> >> build that leaves derived objects such as .o or .class files laying
> >> around.  Now sync the #0 revision of all the files that came from
> >> Perforce.  What should Perforce do with the directory?  The derived objects?
> >>
> >> Tony.
> >>
> >>
> > Tony - in the example you've given, Perforce will do nothing regardless
> > of the setting. The Perforce client "rmdir" option only removes the
> > directory if it's empty. I've used the rmdir option for 10 years now
> > with no ill effects. I appreciate Roy's question. I've never thought of
> > a case where I wouldn't use the rmdir setting, but I assume there are some.
> >
> > ...RickM...
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
> >
> >
> Rick,
>
> as Paul Goffin points out, this option wasn't there in early Perforce
> releases.  The default matches the original behaviour.  Next you have to
> consider the extent to which Perforce "controls" directories it
> creates.  Clearly somebody wanted it to remove them on sync #none or the
> feature wouldn't have been implemented.  But what to do if there are
> non-Perforce files present?  It seems that the answer is the
> time-honoured "punt".  Finally, as Biswajit points out, there is the
> cost; at minimum Perforce must run at least one stat system call on
> removing the final managed file from a directory.  It might be
> instructive to run some timings to see if this is significant.  And it
> might not remove the directory anyway depending on what it finds, so you
> still have to code for this case anyway if you really need to make the
> directory go away (if you are trying to clean up a build client or
> whatever).  Getting back to the original question, is there ever any
> case where setting rmdir could be considered harmful?  Probably not.
> How useful is it?  Discuss.
>
> Tony.
> _______________________________________________
> 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