Bug 376789 - Drop P4CONFIG check
Summary: Drop P4CONFIG check
Status: RESOLVED WORKSFORME
Alias: None
Product: kdevplatform
Classification: Developer tools
Component: perforce (show other bugs)
Version: 5.0.80
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-22 10:24 UTC by Massimo Burcheri
Modified: 2022-11-30 05:16 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Massimo Burcheri 2017-02-22 10:24:10 UTC
Please don't rely on P4CONFIG.

We never used that before, I just learned about that variable after debug output of KDevelop mentioned that the plugin was not enabled due to missing P4CONFIG.

P4 works also without P4CONFIG and so should the plugin.

There are 2 pitfalls:

* The plugin was not loaded if the variable isn't set
* Files on my project don't have the perforce context menu

The latter I was able to fix. I had a P4CONFIG=.p4config and some .p4config in my $HOME seting P4CLIENT. After leaving home and going to /workspace the context menu disappeared. I learned the P4CONFIG only applies to the current folder. This can be powerful but confusing. Got that fixed by moving the .p4config to the parent directory /workspace, but would prefer to not use a $PWD related configuration.
I know git and hg are doing that as well, but there every clone has the metadata on top, while things would be more confusing when submitting a .p4config to Perforce, chicken-and-egg problem.
Comment 1 Morten Danielsen Volden 2017-02-22 11:35:26 UTC
P4CONFIG only points to the filename that the plugin should search a given directory structure for.

So if you have a project folder structure like this:

MyCoolProject
     Foo
     Bar
     Baz

Then you would only need to place your .p4config (or whatever you choose to call it) in the top-level directory of your project (Like Git and Hg.)
Comment 2 Massimo Burcheri 2017-02-22 11:37:21 UTC
Having P4CONFIG unset is a valid P4 environment. But the perforce plugin refuses to load.
Comment 3 Morten Danielsen Volden 2017-02-22 12:57:03 UTC
(In reply to Massimo Burcheri from comment #2)
> Having P4CONFIG unset is a valid P4 environment. 
True.

IIRC, older p4 clients needs the P4CONFIG to be set - no?

Also. If you P4 environment does not rely on the P4Config to be set what does it rely on to e.g. read the server address for a specific project?
Comment 4 Massimo Burcheri 2017-02-22 13:32:29 UTC
I had some old clients from 2007 that did not need P4CONFIG to be set, and the current from 2017 doesn't either.

afaik the default always was to configure all in the environment:
P4LOC
P4CLIENT
P4PORT
P4USER

Having a P4CONFIG and some file found this can overwrite these settings while superseeding with parent directories $P4CONFIG. So p4 on some /workspace/file would be different if your $PWD is $HOME or /workspace/file as that $P4CONFIG there could switch your $P4CLIENT. It could even switch your server $P4PORT.
It's more a git way but we don't use it as things get more obfuscated by this.

Anyway the perforce plugin should not rely on it. p4 will use the feature if configured. You could better add some local environment settings to set P4CLIENT per KDevelop project or just inherit the system environment. Look at qtcreator, they have some P4CLIENT and P4PORT settings in the dialog replacing the system environment settings.

Usually on shell we switch the "project" by scripts exporting P4CLIENT to a subshell. While working in KDevelop don't have that option anymore so I would need to set these per project, but could also be done by the project generic environment settings of KDevelop.
Comment 5 Justin Zobel 2022-10-31 04:31:54 UTC
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 6 Bug Janitor Service 2022-11-15 05:15:25 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 7 Bug Janitor Service 2022-11-30 05:16:53 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!