[p4] deleting and renaming jobs...
Weintraub, David
david.weintraub at bofasecurities.com
Fri Sep 8 10:06:58 PDT 2006
It has to do with the way Perforce setup their database in the first
place. The Job ID is the primary key to the Job table. That means that
changelists are keyed on the Job ID, so if Perforce gave you the ability
to change Job IDs, they'd have to somehow go through all changelists,
find the ones with the old job ID, and change the job ID to the new one.
You could take down Perforce, create a checkpoint, parse through the
checkpoint to find all instances of your old job, and rename the job in
the checkpoint, then rebuild the database with the munged checkpoint
file. Probably not something you want to make part of your standard
development procedure.
It's even worse with User IDs. User IDs are used in the groups tables,
the protection table, changelists, etc. And, it is unfortunately quite
common to want to change user IDs. For example, you decide to integrate
Perforce with a defect tracking system that uses a different set of User
IDs, or corporate policy changes, or you keyed the user ID by user name,
and some one gets married and changes their name.
To get around this problem would means a major modification in the
database layout, so I doubt it will ever get fixed.
-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of G Barthelemy
Sent: Friday, September 08, 2006 12:06 PM
To: Perforce Users
Subject: [p4] deleting and renaming jobs...
Our development process relies heavily on jobs: we enforce that jobs be
associated with changelists when changes are submitted to the depot. Our
in-house developed bug tracking database actually generates the perforce
jobs, and the relation between a bug and the corresponding fix(es) in
Perforce is tracked using the job name, which must be the same as the
bug name. Not fancy but efficient.
Anyway, we have noticed that when deleting a job (job -d JOB-1234) the
job would be removed from all the changelists it was associated with.
Fine, it's easy to imagine how that would work in a relational database.
However, renaming a job by bringing up the form for a job (p4 job
JOB-1235) and changing the Job: field to rename it (say to JOB-1236)
just creates a new job (JOB-1236), leaving JOB-1235 in place (in other
words it duplicates it with a new name). Changelists are not affected,
and remain associated with JOB-1235.
Is it a feature or a bug ? Could it be considered that because the job
deletion is affecting associated changelists, renaming a job should do
the same ? Or can we rely on editing an existing job for a way of
duplicating a job (which we sometimes need to do for various reasons).
On a related note: amazingly it only recently struck us that any user
could delete any job. I would like to be able to prevent that from
happening while letting anyone creating jobs. What would be the best way
to do that ? I thought I read somewhere that protect could be used to
restrict the use of commands, but I can't find anything about this (I
must have been dreaming !).
--
Guillaume
_______________________________________________
perforce-user mailing list - perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user
More information about the perforce-user
mailing list