[p4] deleting and renaming jobs...

[G Barthelemy]

On 9/8/06, Shawn Hladky <p4shawn at gmail.com> wrote:
> There is no way to rename directly.  You'd have to script it:
>    create new job
>    p4 fix -d for each fix on the old job
>    p4 fix for each change on the new job
>    p4 job -d old job
>

Yes, this is roughly what we thought we'd do:

- p4 fixes -j OLD_JOB which lists all the changelists associated to that job
- for each changelist, p4 fix -c <changelist> NEW_JOB
- p4 job -d OLD_JOB

I didn't think p4 fix -d was necessary. I assumed the relation would
be removed when the OLD_JOB is: I'll have to test that.


> It seems a little strange that you'd want to re-name a job anyway.  The job
> name should be some sort of an identifier.  And in general relational
> database sense, you don't ever change an identifier.

Our defect tracking system has multiple instances (at multiple sites),
each managing local or global software projects (modules). They can
all talk to the central Perforce server, and they can also talk to
local Perforce servers (if any) at the same time: the Perforce server
that the defect tracking is going to talk to is determined by the job
name prefix that is unique to the software module. So we deal with
multiple modules by using different job identifiers (and bug ids). In
this case we have a site that had to have its software module job
identifier prefix renamed because it was set the same as a global one
by mistake.

> As for deleting jobs, you should be able to prevent that with a form-delete
> trigger.  What bothers me more, is that there is no way to prevent a user
> from deleting a fix record... and there's no traceability to even know that
> the fix was deleted.

OK, I just read the help for p4 jobs and when a job is deleted the
associated fixes are deleted too (which is reassuring). However you
raise a point which is that deleting a fix should also be prevented
(in our job dependent bug tracking scheme)...

If you have p4d logging at level 3 (and keep your logs), you should be
able to trace that a fix has been deleted. You would have had to
suspect it in the first place, though...

I'll look at the trigger option, but it would be so nice to be able to
specify access control for running commands (with arguments) in the
protect table !

Thanks,
-- 
Guillaume