[p4] Managing administrative tasks

[Jeff A. Bowles]

A workspace need not be "sync'ed" to be useful for reporting commands.
Yes, you might find that you need to run:
   p4 integ -n   //depot/branch1/...   //depot/main/...
   (process that output)
   p4 integ -n  //depot/branch2/...   //depot/main/...
   (process that output)
   ...
but that's just scripting work, not that hard, and easily done in
Perl/Python/Ruby.

The P4Perl/P4Python/P4Ruby hooks are pretty terrific, by the way, also. Do
not bother to script in the DOS command language; the effort (and
maintenance issues) for that language (for scripting) make it high-cost for
low-return.

Also, it's worth remembering: if you have write access to the physical disk
area for a workspace (and it's the exact same pathname to the workspace),
and you want to "sync" the workspace to bring it up-to-date, you do NOT have
to run the 'sync' as the owner of the workspace.  This might alleviate the
"token" issues you refer to.

I still wonder at the notion of updating a user workspace in the
middle-of-the-night, possibly interrupting the static environment the user
is relying on for developing some code. That seems to work against some of
the nifty Perforce behavior (Laura Wingerd's advice, "do not use 'jello'
views", comes to mind).

   -Jeff Bowles


On Nov 22, 2007 10:41 PM, Ildefonzo Arocha <ilde.web at gmail.com> wrote:

> > Are you using Linux/Unix/Mac or Windows for this?
> >
> > Also, it might be useful (mandatory) to ask if you really want to
> > update/sync the developer workspaces.  One of the cool things about
> Perforce
> > is that your workspace and environment do not change unless / until you
> ask
> > for it to.  This might be a feature worth using and exploiting, instead
> of
> > overriding.
>
> We have a central build and developers build, the central build is run
> automatically at night, the developers build is ran on demand.
>
> > Lastly, reread the "integrate -n" documentation. It works on direct
> > arguments (//depot/xxx/... to //depot/yyy/...) in addition to
> branch-specs.
>
> I am aware of that, but how does this solve my problem? I still need a
> workspace that maps all branches for which I want to use "integrate
> -n" ... or not?
>
> Thanks,
> Ildefonzo
> _______________________________________________
> 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