Question
· Jan 17, 2019

Studio source control hooks

Hi there,

I've been busy setting up Perforce source control on a Cache 2017.2.2.865.0 instance. Everything is mostly done and working through studio hooks. Checking out, modifying and checking back in works correctly but I would like to know what the hook, override, setting is to force studio to check if the class needs to be checked out or is already checked out by another user before you are allowed to edit it.

Scenario is a user opens a class, perforce serves the latest version. The user then starts to edit but before anything is done on the code there should be a check if the class has been checked out. If not prompt the user to checkout and if it has already been checked out display an error message.

Discussion (3)1
Log in or sign up to continue

Adrian - are you writing your own Perforce hooks or use the sample Perforce hooks that ship with Caché? (%Studio.SourceControl.ISC.cls).

In %Studio.SourceControl.ISC.cls it checks to see if the file in the local workspace is Readonly or ReadWrite.  If Readonly it assumes it is not checked out and prompts the user to check out.  If ReadWrite it will see if it is a multi-developer or single-developer instance.  if single developer it can just edit it.  If multi-developer it will check in %Studio.SourceControl.Change to see if the current user is the one who checked it out - if so they can edit, if not they can a message of who is editing it in the Output window and the item is treated as ReadOnly to them.

Thank you Benjamin, I'm using my own class for the hooks but I'm extending %Studio.SourceControl.ISC.cls.

I'm overriding some of the methods (GetStatus for instance) I noticed that if I add a new class to source control, check it in and then open it again I can't check it out again. It only gives me check in or undo options. After I check it in, %Studio.SourceControl.Change still shows it as Committed=0 but even if I manually change it to committed it still doesn't show the check out option. 

I have set up the shared workspaces so it should pick it up as a multi-developer instance, that's the criteria as far as I can see in the code.

I can only comment on the original functionality in %Studio.SourceControl.ISC - if you're extending it you will need to do some debugging to see exactly why you are seeing the behavior that you are.

In the original %Studio.SourceControl.ISC class, when working in Connected mode (ie, Caché can issue p4 commands in real time to the Perforce server), the p4 command should take care of changing the file back to ReadOnly, which is what triggers GetStatus() to see it is uneditable and therefore not checked out.  It may be that your GetStatus() isn't correctly interpretting  the Reaonly state of the file, or if you are on UNIX, it may be that Caché doesn't see it properly as Readonly (this can happen if you are running your instance as Root).    Note - I think there may be a bug where after checking the %Studio.SourceControl.Change table isn't updated appropriately, but the primary indicator of checked  out/ checked in should be that Readonly bit on the file.

Hopefully this is enough to get you moving on this, and if not then I suggest you call Support to have them take a look with you and debug.  If there are any other questions I can answer in this forum I am happy to try.

Best of luck!