You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
[NEW] add a new/private file to source control #434
Hi! Unfortunately from our side there isn't any VSCode plugin work planned for this quarter. Are you interested in contributing to the repo? If that's the case, I can give you some references to get you on track 🙂
In that case, you can take a look at how menus are built for Source Control extensions in the VS Code Extension docs. It would be a matter of adding a "+" button that triggers a Plastic SCM Add command. After that command runs, the extension will reload the status to acknowledge the changes in the workspace. The targeted file should now be controlled (i.e. "Added" instead of "Private") and subject to checkin.
Said command would ultimately call cm add via the cm shell that is up and running for the workspace. You can have a look at other commands (e.g. checkin) for reference.
In the future we might want to separate by categories (controlled vs. local changes, or even more fine-grained) and have the "+" button perform an "add" or "checkout" action depending on the item status, but I think this is a good first pass for now.
Hi, I started developing the vscode plastic plugin last friday, and today I continue to start working on.
If only to implement add a new/private file to source control, we only need to do commit.
But I think this is not good, because many times we don't need to commit all the changes (modify, add, delete, move...)
So I want to use cm to implement two workspaces Changes / Staged Changes We only CheckIn what is in the Staged Changes workspace. But I have some problems:
If it is added/moved change, we can click + to call cm add/undo to judge the status of TypeVerbose Private <=> Added/Moved, and realize workspace Changes / Staged Changes.
But if it's a deleted/modify change, I can't mark it with cm...
Is there any other way for CM to support this behavior? Should I create a separate variable to store the changed state?
The key here would be to get private files under control. That's achieved by running a cm add command to the file. That way, it will be included in the checkin along with any other change in the workspace.
What you're referring to is a desired functionality (being able to explicitly select what's included in the checkin), but it falls out of the scope of this particular issue 😃 We'd need to address that in a separate one.
I tried usingcm addto solve this, but I don't know how to indicate that the file has been "added" (ui design), so I want to implement workspace Changes / Staged Changes ie (being able to explicitly select what's included in the checkin)
For the function of the plug-in, we can quickly solve it by calling plastic-client-core through js, I can't think of a good solution for the plastic plugin ui design... Do you have any good suggestions? I think this is my biggest difficulty
I tried usingcm addto solve this, but I don't know how to indicate that the file has been "added" (ui design), so I want to implement workspace Changes / Staged Changes ie (being able to explicitly select what's included in the checkin)
I'm not against this at all! Just saying that it's a different issue and it should be handled as such.
Added files are represented differently from private files. They're different changes, as private files aren't controlled by version control, whereas added files are. You can try that by using a Plastic client (GUI or CLI) to add a private file in your workspace and then refreshing the Plastic Version Control section inside Visual Studio Code.
For the function of the plug-in, we can quickly solve it by calling plastic-client-core through js, I can't think of a good solution for the plastic plugin ui design... Do you have any good suggestions? I think this is my biggest difficulty
I'm not sure what you mean by that. Could you clarify?
This PR is currently in WIP status (the code is a bit messy, there is no error handling), just to verify whether the way to implement the function is correct.
Activity
givetimetolife commentedon Feb 2, 2023
Hello, is there any progress on this issue? I'm interested in solving this problem, can you provide some plastic advice? @SRombautsU
mig42 commentedon Feb 2, 2023
Hi! Unfortunately from our side there isn't any VSCode plugin work planned for this quarter. Are you interested in contributing to the repo? If that's the case, I can give you some references to get you on track 🙂
givetimetolife commentedon Feb 3, 2023
Thanks for your reply! I'm interested in solving this problem and plan to start working today 🍻
mig42 commentedon Feb 3, 2023
In that case, you can take a look at how menus are built for Source Control extensions in the VS Code Extension docs. It would be a matter of adding a "+" button that triggers a Plastic SCM Add command. After that command runs, the extension will reload the status to acknowledge the changes in the workspace. The targeted file should now be controlled (i.e. "Added" instead of "Private") and subject to checkin.
Said command would ultimately call
cm addvia thecm shellthat is up and running for the workspace. You can have a look at other commands (e.g. checkin) for reference.In the future we might want to separate by categories (controlled vs. local changes, or even more fine-grained) and have the "+" button perform an "add" or "checkout" action depending on the item status, but I think this is a good first pass for now.
givetimetolife commentedon Feb 6, 2023
Hi, I started developing the vscode plastic plugin last friday, and today I continue to start working on.
If only to implement
add a new/private file to source control, we only need to do commit.But I think this is not good, because many times we don't need to commit all the changes (modify, add, delete, move...)
So I want to use cm to implement two workspaces Changes / Staged Changes We only CheckIn what is in the Staged Changes workspace. But I have some problems:
If it is added/moved change, we can click + to call
cm add/undoto judge the status ofTypeVerbose Private <=> Added/Moved, and realize workspace Changes / Staged Changes.But if it's a deleted/modify change, I can't mark it with cm...
Is there any other way for CM to support this behavior? Should I create a separate variable to store the changed state?
@mig42
mig42 commentedon Feb 7, 2023
The key here would be to get private files under control. That's achieved by running a
cm addcommand to the file. That way, it will be included in the checkin along with any other change in the workspace.What you're referring to is a desired functionality (being able to explicitly select what's included in the checkin), but it falls out of the scope of this particular issue 😃 We'd need to address that in a separate one.
givetimetolife commentedon Feb 8, 2023
I tried using
cm addto solve this, but I don't know how to indicate that the file has been "added" (ui design), so I want to implement workspace Changes / Staged Changes ie (being able to explicitly select what's included in the checkin)givetimetolife commentedon Feb 8, 2023
For the function of the plug-in, we can quickly solve it by calling plastic-client-core through js, I can't think of a good solution for the plastic plugin ui design... Do you have any good suggestions? I think this is my biggest difficulty
mig42 commentedon Feb 8, 2023
I'm not against this at all! Just saying that it's a different issue and it should be handled as such.
Added files are represented differently from private files. They're different changes, as private files aren't controlled by version control, whereas added files are. You can try that by using a Plastic client (GUI or CLI) to add a private file in your workspace and then refreshing the Plastic Version Control section inside Visual Studio Code.
I'm not sure what you mean by that. Could you clarify?
givetimetolife commentedon Feb 15, 2023
plastic-scm-0.1.3.vsix.zip
What do you think of this plugin design? @mig42
mig42 commentedon Feb 15, 2023
Do you have a branch or a PR that I can review?
givetimetolife commentedon Feb 15, 2023
This PR is currently in WIP status (the code is a bit messy, there is no error handling), just to verify whether the way to implement the function is correct.
#505