[p4] Managing administrative tasks

[Jeff A. Bowles]

Part #1:There was an answer to the "how do I update the workspaces without
using the user's tokens -- he/she might not be logged in -- in a
background/automated way," earlier in this thread.  Consider that I could,
from machine "zaphod", run a "p4 sync" to update the client rooted in drive
M:/stuff.
Nothing keeps "M:" from being the same drive - the same physical drive - for
your development machine and my server machine. Drive substitution could do
it, although I admit that I do not love this solution.

Think that one through; it would work.

Part #2:
Moreover, I am unsure why you would need to have a "batch" user that ran on
all machines. Give it permissions for 2-3 server/scripting/background
machines and be done with it. Restrict by IP address so that you don't
inadvertently create a security issue. Since it has "open" permission
(probably for that "p4 integ -n" operation), you don't want it everywhere.

Part #3:
Also, it's worth considering whether you want to have the copy-of-CVS pulled
over from CVS every night. I think it's a good idea, given the situation
you're in; don't get me wrong. I just think that it's worth considering how
it is done.

If you have ZERO development of the server done in Perforce, at the moment,
then just copy the CVS stuff in. I think that's slightly optimistic, but
it's a good way to start:
      on a workspace specific to this task, probably on a controlled
machine:
      p4 sync (to head revision) of //depot/main/servercode/...
      Probably a "p4 diff -se / -sd" to look for surprises.
      p4 edit the entire server code.
      Copy the CVS servercode/... tree into the workspace.
      p4 revert the things that did not change
      # comment: files added/deleted from CVS development might need to be
noticed here
      p4 submit -d "latest dump from CVS" //depot/main/servercode/...
To my mind, it makes more sense to check that in as a branch that no one
except the
import script touches. It makes it easier to notice surprises, to
update-in-Perforce-on-emergency, and so on.

In many ways, you're describing the pattern of "development of third-party
software that I receive code drops from, every so often".  It might make
sense to imitate that.

Comment:
You have a number of very specific questions, and they're good ones. I admit
that I might choose different solutions from you, but that's sorta expected.

I'd give Tech Support an email (cite this thread) and then call 'em. Ask the
engineer you get, to put on a headset and to get a coke, and do the same.
Then start a good, long conversation. Take notes, but touch each of these
things.  Nothing you're trying is impossible, a few of the things are
already-solved problems for some other customer and it's no use to reinvent
strategies if you don't have to.

If you want to work with one of the [very good] Perforce Consulting
Partners, there are many to choose from. But first hit the solutions you've
already paid for.

    -Jeff Bowles
    Perforce Consulting Partner



On Nov 23, 2007 1:29 PM, Ildefonzo Arocha <ilde.web at gmail.com> wrote:

> > A workspace need not be "sync'ed" to be useful for reporting commands.
>
> Sure, I can create a workspace "batch" only for these means, problem
> is how to stop developersfrom using it, the only way I can think off
> is by setting the host name of the client "batch" to something else
> than the development server, but since the scripts run in the
> development server I have then another problem.  IMHO "p4 integrate
> -n" should not require a client.  Any suggestions?
>
> > 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.
>
> I am using Powershell as scripting language, which is very flexible
> (yes, it only runs on Windows)
>
> > 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.
>
> This is not a problem at the moment, I am using the additional license
> from Perforce for this.
>
> > 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).
>
> This sync is done on demand (developer double clicks on a update icon
> which kicks off a sync and a rebuild process
>
> 1. The "missing changes" report (p4 integrate -n) could by executed by
> any user by using the "batch" user: "p4 -c batch -u batch intetegrate
> -n", for this I have to grant the "batch" user "open" rights.  I am
> not very happy about this, but since nobody can submit changes, lets
> say I can live with it.
>
> 2. I could solve some of my issues by only allowing the users to kick
> off the "on-demand update" by a Custom Tool from P4V, in that case I
> don't need the user "batch" for that.  However some of the developers
> want their workspaces to be updated automatically  (as insane as that
> sounds), any ideas on how to run this process without the user been
> logged in Perforce? that is,  without non-expiring tickets?  As a
> first thought: I could use user "batch" for this: assign non expiring
> tickets for the "batch" user, save the ticket on each of the
> developers Windows local profile and since user "batch" has already
> "open" rights (1), nobody can fiddle with the repository by using the
> "batch" user.  But read on ...
>
> 3. The server side of our application is developed under Unix and is
> source controlled in CVS (will be migrate later on to Perforce), the
> client side (GUI) of the application is managed with Perforce.  What I
> need to do, is every night copy the changes made in the server (cvs)
> into the main line in Perforce.  I know this is WRONG and very, very,
> very bad thing to do, but lets stay on topic here for a while.  I need
> to do this process automatically (Windows Scheduled Task), but I can't
> use the user "batch" as I will need to grant him "write" rights over a
> huge part of the Perforce repository; and if you remember points (1)
> and (2) each developer will have the "batch" user's non-expiring
> ticket at reach.  It seems that my only options are:
>
> a. Setup another machine (Virtual PC or whatever), and in the
> protections table grant the "batch" user "write" rights only for the
> IP of that machine ... overkill
>
> b. Buy an additional Perforce license, create a new Perforce user and
> give this user a non-expiring ticket, save the ticket file in the
> Administrator profile of our Windows Server and run the script from
> there ... expensive.
>
> c. Do the this update within the Perforce Server (Linux), virtually
> same as (a) ... this one seems the right one to me. However my Linux
> know-how is very limited, I would like to see if there are any other
> options you guys could think about.
>
> Sorry for the long post.
>
> Thanks again,
> Ildefonzo
>



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