Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running a file intensive operation in workspace leads to lots of duplicate changelists #62

Closed
ihalip opened this issue Apr 20, 2017 · 14 comments
Assignees

Comments

@ihalip
Copy link
Contributor

ihalip commented Apr 20, 2017

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.

Example:
image

In this screenshot, the only changelist that has an opened file is the actual default changelist, all the other ones are "ghosts".

@jel-massih
Copy link
Collaborator

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.

@nomaed
Copy link

nomaed commented Jun 22, 2017

I've been seeing these too quite often.
Is there any update about this issue?

@stef-levesque
Copy link
Owner

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);
        }
    });
}

@nomaed
Copy link

nomaed commented Jun 22, 2017

I'm getting this behavior on a Mac

@stef-levesque
Copy link
Owner

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);

@stef-levesque
Copy link
Owner

Please update to version 2.1.1 and see if you get more detailed errors in Perforce Logs

@nomaed
Copy link

nomaed commented Jul 2, 2017

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 ;)

@stef-levesque
Copy link
Owner

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, ...)

@nomaed
Copy link

nomaed commented Jul 4, 2017

What sort of settings would you like to see? The output from p4 info?

@stef-levesque
Copy link
Owner

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,

@nomaed
Copy link

nomaed commented Jul 7, 2017

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.

@stef-levesque
Copy link
Owner

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.

@nomaed
Copy link

nomaed commented Jul 25, 2017

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.

@nomaed
Copy link

nomaed commented Aug 27, 2017

After testing for some more and working without the flag, it doesn't happen as often.
However, I still do see this behavior after a while.
screen shot 2017-08-27 at 20 59 31

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants
@jel-massih @ihalip @stef-levesque @nomaed and others