Problems with Perforce client

[jvert]

SlickEdit 2013 (v18.0.0.5 64-bit) on Ubuntu 12.04

The Perforce support seems broken if you have multiple clients on your machine. For instance, I have two clients, one under /source/foo and one under /source/bar. If I try to run the checkout command on a file like /source/foo/blah.c, I get an error that says "Path '/source/foo/blah.c' is not under client's root '/source/bar'."

I have P4CONFIG environment variable set to .p4config and a .p4config in both /source/foo and /source/bar that has the right P4CLIENT.

This worked right before my upgrade.

Also a nitpick - at the bottom of the Perforce options dialog, if you select "Perforce executable" it says "Specifies the path to the Subversion executable that you wish to use." at the bottom.
    -John

[Dan]

The nitpick one is fixed, thanks for the report.

What do you get when you run "p4 client -o" from a console?  Does it change depending on the current directory?

[jvert]

If I run "concur-command p4 client -o" from slickedit, I get the correct client for the current buffer. Running 'concur-command p4 edit blah.c" also works. So I don't see why checkout() is getting the wrong client.

I have "Set current directory when switching buffers" set to On, so the current directory is always correct.

[Dan]

How are you trying to check the file out?  We are just running the edit command, nothing specific to the client is happening there, so I am a little perplexed.

[Dan]

Can you try setting def_svc_logging to 1 (Macro>Set macro variable) and then send try the checkout, and send me your (config path)\18.0.0\logs\svc.log file?  You should probably set the variable back to 0 when you are done as it generates quite a bit of information.

[shadm]

I've been having similar problems with the Perforce integration.  I dug into it a bit this morning, and here is what I see happening:

When I open a file that is under Perforce control, SE does set the CWD.  However, inside the getPerforceInfo function, which in turn calls the perforceRunCommand, it appears that a new process/shell is created, which is set to the default directory I get when creating a new shell.  In my case, it is the Documents directory inside my home directory.  So my guess is that no matter what the current directory is for SE, the means by which the command is executed doesn't get that same environment, causing the command to be executed outside the context of the desired directory structure.

I initially tried my p4 commands by right clicking the file in the project explorer, so I thought perhaps my problem was that the CWD was set to some other file in the current buffer.  However, even if I add a call to chdir based on the localFilename parameter passed to getHistoryInformation, the Perforce CWD is set to the default shell directory.  After the context of the perforceRunCommand, the CWD is still set to what I manually set it to.

I am running B2 on Ubuntu 12.04 x86_64.  I hope this is helpful.

[Dan]

Are you sure the current directory is changing?  What happens if you type "cd" on the SlickEdit command line?

I just tested this on Windows and UNIX, and the directory and it seems to be OK, but I'm going to run another test.

[Dan]

Were you checking out by right-clicking on the Projects tool window and picking Check out on the menu?

[shadm]

I'm actually just attempting to just get the history of the file, not check it out.  The assumption being that checking out a file would seem to be an even steeper challenge.  I've tried both selecting from the project file, and while the file is open in the current buffer.  To try to eliminate any confusing conditions, and just demonstrate my initial observation, the following information is specifically related to attempting to get the file history from Perforce from a current buffer.  In addition, I restarted SE and immediately right clicked in the buffer and selected the history command from the context menu.  I've changed the actual paths for security purposes.

getPerforceInfo
CWD: /perforce_view/project
perforceRunCommand
CWD: /perforce_view/project
CMD: /path/p4 info
perforceInfo.currentDirectory: /home/user/Documents
perforceRunCommand
CWD: /perforce_view/project
CMD: /path/p4 -V
perforceRunCommand
CWD: /perforce_view/project
CMD: /path/p4 client -o
getHistoryInformation
initial CWD: /perforce_view/project
after chdir CWD: /perforce_view/project
perforceRunCommand
CWD: /perforce_view/project
CMD: /path/p4 filelog -t -l /perforce_view/project/file.cpp

Note that in all cases, the CWD is the path desired.  However, when inside the getPerforceInfo command, the currentDirectory member is set to /home/user/Documents.  This represents where Perforce thinks it is running, and in my testing on the raw command line is always (obviously?) set the the CWD from where I launched the command.

On a side note, I probably would have had this info sooner, but when attempting to use the file backup history to clean out extraneous debug statements I had added, the diff view was unusable.  The cursor is constantly flickering, whether trying to edit text or click the window buttons.  Not sure if someone has already mentioned this behavior yet or not.

[Dan]

Are you on Kubuntu?

[Dan]

Can you send me the log output (or did you trim this from it)?

I'm actually just attempting to just get the history of the file, not check it out.  The assumption being that checking out a file would seem to be an even steeper challenge.  I've tried both selecting from the project file, and while the file is open in the current buffer.  To try to eliminate any confusing conditions, and just demonstrate my initial observation, the following information is specifically related to attempting to get the file history from Perforce from a current buffer.  In addition, I restarted SE and immediately right clicked in the buffer and selected the history command from the context menu.  I've changed the actual paths for security purposes.

getPerforceInfo
CWD: /perforce_view/project
perforceRunCommand
CWD: /perforce_view/project
CMD: /path/p4 info
perforceInfo.currentDirectory: /home/user/Documents
perforceRunCommand
CWD: /perforce_view/project
CMD: /path/p4 -V
perforceRunCommand
CWD: /perforce_view/project
CMD: /path/p4 client -o
getHistoryInformation
initial CWD: /perforce_view/project
after chdir CWD: /perforce_view/project
perforceRunCommand
CWD: /perforce_view/project
CMD: /path/p4 filelog -t -l /perforce_view/project/file.cpp

Note that in all cases, the CWD is the path desired.  However, when inside the getPerforceInfo command, the currentDirectory member is set to /home/user/Documents.  This represents where Perforce thinks it is running, and in my testing on the raw command line is always (obviously?) set the the CWD from where I launched the command.

On a side note, I probably would have had this info sooner, but when attempting to use the file backup history to clean out extraneous debug statements I had added, the diff view was unusable.  The cursor is constantly flickering, whether trying to edit text or click the window buttons.  Not sure if someone has already mentioned this behavior yet or not.

[shadm]

I installed Ubuntu and then installed KDE because the new Ubuntu unity is not to my liking.  Not sure if that qualifies as Kubuntu or not.

The output I sent was from several "say" outputs that I entered in the Perforce.e file.  That is the complete output, just the specifics of the paths, were changed to be more generic.  Is there more info/another log I should provide?

[Dan]

I had one other report of the diff blinking on KDE, I will check it out.  I'm not sure what would be different about it.

You can set def_svc_logging to 1, but I think your output is complete enough.

[shadm]

I had that turned on earlier, and it provided me no more information than the error dialog.  Here is what it says, paths have been changed to track with previous post:



[T=1718158904] getHistoryInformation stdout
[T=1718158905] getHistoryInformation stderr
[T=1718158905]    getHistoryInformation stderr:/perforce_view/project/file.cpp - file(s) not on client.

[Dan]

Yes, I realized that I failed to include the current directory in the logging.  Your information is better.

I have a possible fix.  Can you PM me an email address?