Comment empêcher les utilisateurs de modifier les options de l'espace de travail d'un autre utilisateur dans Perforce?

Question

Je suis nouveau à Perforce. Il semble y avoir une mauvaise configuration dans notre serveur actuel, car tout le monde peut modifier les options de l'espace de travail de quelqu'un d'autre.

Est-ce que quelqu'un sait comment résoudre rapidement ce problème?

Merci,

Thomas

Answer 1

Si vous définissez l'option 'locked' dans l'espace de travail, l'espace de travail ne peut être modifié que par son propriétaire (ou par un utilisateur avec 'admin' ou un niveau d'accès supérieur). Cela empêchera également les autres utilisateurs d'utiliser ou de supprimer cet espace de travail.

Answer 2

Je ne sais pas d'un moyen de corriger facilement ou rapidement le problème.

Cela étant dit, est-ce que la capacité est là vraiment un problème? Ou est-ce que différentes personnes pensent avoir la propriété de différentes configurations d'espace de travail? Ici, où je travaille, nous préfixons le nom d'utilisateur à tout espace de travail que nous voulons conserver comme étant le nôtre, et nous le laissons hors des espaces de travail partagés (ou utilisons un préfixe différent, parfois).

Si la propriété d'un espace de travail n'est pas claire et cause des problèmes, cela résoudra vos problèmes. Si c'est une situation où les collègues ignorent la propriété et intentionnellement apporter des changements, vous avez probablement d'autres problèmes à s'inquiéter.

Answer 3

pas une solution directe, mais vous pouvez suivre les modifications apportées aux spécifications des clients en mettant en place un « Spec Depot ». Voir KB article here.

Je dois avouer avant de lire votre question, je ne savais même pas que vous pouvez modifier la spécification du client d'un autre utilisateur sans droits d'administrateur. Au cours des 9 années d'utilisation de Perforce, je n'ai jamais rencontré cela comme étant un problème réel pour les gens.

La suggestion de cjhuitt de préfixer une spécification client avec un nom d'utilisateur/initiales est une bonne pratique, et est une pratique assez courante, en particulier dans les grandes installations.

Answer 4

Verrouiller l'espace de travail est la solution, merci Heath.

Je travaille sur un petit script PERL pour verrouiller tous les espaces de travail existants:

#******************************************************************************* 
# Module: LockClients.pl 
# Purpose: A perl script using the CLI to lock all clients on a server 
# 

# Debug Flag: 
$DEBUG_FLAG = 1 ; # 1 for TRUE, 0 for FALSE 

# Get the list of clients on the server: 
@list = `p4 clients`; 

foreach $client (@list) { 
    # Get client name: 
    $clientname = (split//,$client)[1]; 
    if ($DEBUG_FLAG) { print ("Client name: $clientname \n"); } 
    # Prepare temporary file name (will contain the new config spec of the client): 
    $filename = sprintf("tmp_%s.txt",$clientname); 
    if ($DEBUG_FLAG) { print ("Temporary file: $filename \n"); } 
    # Get client spec: 
    @clientspec = `p4 client -o $clientname`; 
    # Write client spec to file: 
    open (VIRTUAL , ">$filename") || die "ERROR: Could not create $filename \n"; 
    foreach $line (@clientspec) { 
     if ($line =~ m/^Options:.*$/m){ 
      if ($DEBUG_FLAG) { print ("Line before substitution: $line"); } 
      $line =~ s/unlocked/locked/; 
      if ($DEBUG_FLAG) { print ("Line after substitution: $line"); } 
     } 
    print VIRTUAL $line; 
    } 
    close (VIRTUAL); 
    # Import new config spec in client: 
    `p4 client -i -f < $filename`; 
    if ($DEBUG_FLAG) { print ("Workspace $clientname locked !\n\n"); } 
}  
exit 0; 

Je vais maintenant travailler pour essayer d'appliquer l'option de verrouillage avec un déclencheur après un espace de travail est créé ou modifié. :)

Thomas