Running a file intensive operation in workspace leads to lots of duplicate changelists
ihalip opened this issue · 14 comments
vscode: 1.11.2
vscode-perforce: 2.0.1
Running an operation that creates a large number of files (for example a local build) inside the perforce workspace causes the extension to rapidly refresh the pending changelists. What I think happens is that multiple refreshes are done in parallel and this leads to lots of duplicate changelists that don't disappear when manually refreshing.
In this screenshot, the only changelist that has an opened file is the actual default changelist, all the other ones are "ghosts".
I have been getting a fair number of reports about this as well.
I will try and take a look at this sooner rather than later.
I've been seeing these too quite often.
Is there any update about this issue?
We might be hitting an issue on Windows, were we bust the command line limitation
(see https://support.microsoft.com/en-us/help/830473/command-prompt-cmd.-exe-command-line-string-limitation)
Splitting the refresh of fstat for opened files should help (here, with an arbitraty value of 32 filepaths per command line)
const depotOpenedFilePaths = await this.getDepotOpenedFilePaths();
for (let i = 0; i < depotOpenedFilePaths.length; i+=32) {
const fstatInfo = await this.getFstatInfoForFiles(depotOpenedFilePaths.slice(i, i+32));
fstatInfo.forEach(info => {
const clientFile = info['clientFile'];
const change = info['change'];
const action = info['action'];
const uri = Uri.file(clientFile);
const resource: Resource = new Resource(uri, change, action);
if (change.startsWith('default')) {
defaults.push(resource);
} else {
let chnum: number = parseInt( change );
if (!pendings.has(chnum)) {
pendings.set(chnum, []);
}
pendings.get(chnum).push(resource);
}
});
}
I'm getting this behavior on a Mac
Are you sure you are logged in? Any error in the Perforce Log
?
The following should output more info:
Utils.ts
import { Display } from './Display';
...
PerforceService.execute(command, (err, stdout, stderr) => {
err && Display.showError(err.toString());
stderr && Display.showError(stderr.toString());
if (err) {
reject(err);
} else if (stderr) {
reject(stderr);
} else {
resolve(stdout);
}
}, args, null, input);
Please update to version 2.1.1 and see if you get more detailed errors in Perforce Logs
Updated to 2.1.1, still massive duplications of changelists, not only the default.
The only "error" occurrences in the log are several of:
ERROR:
file marked for delete
(also there is no \n
at the end so the next command appears right after the string)
I ran p4 unshelve
on one of the CLs from CLI and noticed the duplications after.
Will try to reproduce this again and will post exact steps if I manage.
As a side note, if no files are opened, p4 opened
displays an error in the log ("File(s) not opened on this client.") but it probably shouldn't be considered an error. It's a perfectly legit state to be in ;)
Thanks for the valuable information, we will eventually nail this one :)
Could you provide here all your perforce
config settings?
You are right about the side note, I've still to implement a proper grading in the the logs (error, warning, debug, ...)
What sort of settings would you like to see? The output from p4 info
?
Did you set any perforce
setting in you user or workspace config? (like .vscode/settings.json)
I wonder if the following settings could trigger the issue:
// Automatically open a file for edit when saved
"perforce.editOnFileSave": true,
// Automatically open a file for edit when Modified
"perforce.editOnFileModified": true,
// Automatically Add a file to depot when Created
"perforce.addOnFileCreate": true,
// Automatically delete a file from depot when deleted
"perforce.deleteOnFileDelete": true,
// Try to resolve real file path before executing command.
"perforce.realpath": true,
Yes, there are several custom user settings:
{
"perforce.command": "/usr/local/bin/p4",
"perforce.addOnFileCreate": true,
"perforce.editOnFileSave": true,
"perforce.deleteOnFileDelete": true,
}
No special perforce stuff in workspace settings.
If you have a solid way to reproduce it, try to disable each 3 last settings, to see if it could come from the file watches.
Just wanted to update that for now I haven't observed this behavior without the 3 flag. However, I also hadn't had the chance to do work for long with VSCode on the usual stuff where I saw the bug.