The file is not on the client

I get a very strange problem with P4Python since I started to implement workspace awareness.

The situation is as follows:

I have a module "P4Commands" that inherits from P4 and connects to __init__()

Then I have the following classes respectively:

  • P4user
  • P4workspace
  • P4changelist

The P4Commands module inherits P4 and calls its parent "run" method, and also injects some custom caching that I implemented to speed up a large number of calls. The run method is called as such:

 result = super(P4Commands, self).run(*args, **kwargs) 

Then it registers and returns.

When I invoke a file operation, I first look at P4User to find out what workspace the file is in. Then I do the following in an instance of the workspace that I find that it matches:

 def run(self, *args, **kwargs): # run whatever commands have to be run, with client temporarily set # to this instance client setting. with self.FUNCS.saved_context(client=self.client) as _: return self.FUNCS.run(*args, **kwargs) 

Where FUNCS is an instance of the P4Commands module.

The problem I get is that for a file that returns information when I call fstat , I get "files not on the client" as an error when I call the "edit" command . It seems that any other command (add, fstat, where, etc.) is working fine. This happens ONLY on the editing team.

Strange, I do not get an error when starting a method with the same arguments, but outside the context manager of the workspace (directly in the P4User module).

It gets weirder: I tried to disable the context manager, but still no joy.

One more thing to add to the oddity when you read this, you might think, "Oh, the client is not configured properly." I tried to register the client workspace, and it installs correctly and does not install. As I said, all the other teams work, they simply are not edited.

The only remaining scenario is that multiple connection instances of the P4 module interfered. I tried to make P4Commands static global, and only one instance was available for each module. This also did not end.

I tried different approaches, but now I'm a bit stuck. Does anyone know how to solve this?

+7
python p4python
source share
1 answer

After a big search, I managed to solve this:

I started the P4 connection as a member of the class that was messing with the instance since each P4Workspace instance used the same connection and tried to take responsibility. Despite the fact that most of the commands work, it seems that this is due to the connection as the cause of the problem mentioned above.

The way I decided to solve this was to make an instance of the P4 class an inherited instance of the P4Workspace class. It used to be a class.

So the structure that finished the job:

  • A member of the P4User class called FUNCS that specifies the connection for non-workspace calls. Contains multiple instances of P4Workspace.
  • P4Workspace is an instance variable called β€œconnection” that creates an example connection to a specific workspace.
+3
source share

All Articles