Visual Studio Code - Why Use Workspaces over Standard Folders? - visual-studio-code

I've been searching and searching for what the purpose is for a workspace. I've asked this question in stack chats but no one seems to know.
I know workspaces are local copies of solutions and you can switch between them when testing different things on the same projects but with different branches but I can do that with standard folders as well. So I can't figure out what the advantages and disadvantages are of using workspaces over normal folders. Is having different settings for each workspace the only advantage?
The only other obvious thing I see is shown in the screenshot but that a workspace is shown as a single "Code Workspace" file with no folder structure even though it does have one while standard folders have the structure and shows all contents.
I found this article on stack and it's kinda relevant but not as specific and it's unanswered. So instead of setting a bounty I thought I'd ask exactly what I was looking for. Asking about workspaces with settings vs user settings.

Two things which makes Workspace different from standard folders -
Like the other answer you linked to, you can have workspace based settings
In one Workspace you can open different folders which are not necessarily in the root folder which you open first.

In addition to workspace-based settings, workspaces can act like aliases that can link to a root folder (sort of like Dreamweaver's Sites feature). So you can keep a centralized folder/collection of all your workspaces in one place for easy navigation (a folder named VSC-Workspaces for example), yet they can point to and open work folders that may be saved in different locations on your hard drive, since they might be websites or python files, etc.

Related

Where are the information about each workspace stored?

I know that some settings such as imported folders are store on the workspace file such as my-worskapce.code-workspace and some others such as python interpreter are stored in the root folder(s?) such as .vscode/settings.json but these do not include information about opened editors or which extensions are disabled for each workspace etc. Where can I find those information?
I need that information because I started storing all my *.code-workspace files in ~/ and now it's getting cluttered and I want to move them to a different folder, when I do, and reopen my workspace, I see that all open editors are gone! This hurts my productivity as I will have to reopen them and recall which files were being worked on. And another issue is that previously added folders are gone too! I have to re-add them which is merely a redo of work that already has been done, since imported folders are imported as relative paths. If I move the *.code-workspace file to it's original location with the same name however, everything is back to normal, so this tells me VSCode is storing information about each workspace somewhere and it's bound to each *.code-workspace absolute path. I have checked ~/.config/Code/User but couldn't find anything. I've googled a lot using different keywords but seems it's nowhere documented or asked about. I usually make backups of my workspace files and I'd like to make back up of these information as well.
In windows you can find them in
C:\Users\<username>\AppData\Roaming\Code\User\workspaceStorage
VS Code 1.75 introduced a new Profiles feature, summarised here.
Profiles store information such as user settings, installed extensions and the current layout of panels etc.
You can export/import profiles to/from a Github gist or a local file. Different profiles are associated with each workspace.
Profiles won't resolve all your immediate issues, but may give you more flexibility in the future.

How can I search for a file in just one specific folder in VSCode when using a workspace with multiple folders?

I'm using the workspace feature of VSCode, with two projects, but it's annoying to search for a file in the front-end project and need to pass by back-end files to find the one I want.
I'm using ctrl + p to search for files.
How can I search for a file in just one folder with multiple projects opened in the workspace?
Yes thats possible: use a relative path: ./mySearchedProjectName in "files to include"-input
from HERE!
UPDATED answer to UPDATED question
The fuzzy file finder (CTRL+P or ⌘+P) somehow supports prefixing the filename with a folder, such as folder/filename to locate a file from a specific folder:
But, in my experience, the search is a bit lacking. For example, I find it usually can only find files this way if that file has been recently opened in your workspace. It also does not support regex.
The best thing that can be done is to enable including recently opened files by adding this to the workspace settings:
"settings": {
"search.quickOpen.includeHistory": true,
AFAIK, there is no other built-in way to filter the results. There are (still) open feature requests for this, like this Allow quick open to filter on folder names by typing folder name after the file. You can thumbs-up them to hopefully get them noticed.
ORIGINAL answer to ORIGINAL question
I don't know what you mean by "projects" since VS Code only has "workspaces" and "folders", such that you add folders to a workspace. I think you're already doing this, where each folder contains a separate set of codes.
With that said, the Search/Find panel has an area to specify files to include, where you can limit your search to a specific folder. For example:
Here I have 3 folders (proj 1-3) added to a workspace. I have 3 sample files with the same text.
When searching, you can set files to include to a specific folder (./proj2), so that the search results will be limited to that folder.
I've found the best solution to this for me (though it's still a sub-optimal one) is simply to run multiple VS Code instances, one for each folder.
It's a pain to start up, but once you get things going (and hopefully you're not restarting often on your dev machine, so this is less of an issue) it works perfectly: you can search for files with only the relevant ones showing up.
Also, if you want to reduce the start-up pain you can make a shortcut/alias/etc. in your operating system that starts both at once.

Multiple sub-workspaces in Eclipse

I write code in several languages (Python, C, C++, and Java) using Eclipse. Is it possible to designate a directory on my machine (say /home/workspace/) as the "primary" workspace for any Eclipse session, but then to have subfolders, /home/workspace/python, /home/workspace/java, etc., in which I can create new Eclipse projects.
I don't want to have to navigate menus and select different workspaces for each session of Eclipse that I start up. I would rather just always have permission to manipulate any projects from a variety of folders at any time, but I can't find a clear answer about whether this can be done and how to do it.
As I understand your question; You want to have one workspace, but be able to code in several different languages without switching workspace but at the same time keep the projects separated?
First I would suggest you consider several workspaces, I find it convenient to keep settings and projects in separate workspaces. I rarely have to switch language that often.
But. I think what you want to do is to keep several working sets. You create one java working set, one C++ set and associate your different projects with a working set. Then you can minimize the java working set when you are running C++. For working sets you dont need any subfolders on the harddrive.
You might also want to look into Mylyn. Its a great tool for those who often are switching context. It saves the context (eclipse perspective, open files, etc) as associated with a task.
How about setting Eclipse to prompt for the workspace at launch? It wouldn't allow you to work in two languages at once, but should do the trick otherwise.
An Eclipse workspace can contain projects slated for different languages and those projects can live anywhere on your hard drive. There are at least two ways to do what you want. When creating a new project, uncheck the Use default location checkbox and browse to or specify the folder where you want your project to live. If a project already exists import the project into the workspace using the File->Import menu option and then select Existing Projects into workspace. In the next screen make sure the checkbox for Copy projects into workspace is not selected. This will leave the source files in the original folder.
In the Project explorer view, all the projects are going to look like they live at the root level. However you can group related projects into working sets. Then select just the working set you're interested in and all the others will disappear from view.
A warning is in order if you make use of eclipse variables in external tools (and possibly elsewhere). The syntax you use for paths needs to be adjusted. For example with projects outside the workspace this syntax ${workspace_loc:/MyProject/MyFile.txt} is no longer the same as this syntax ${workspace_loc}/MyProject/MyFile.txt

eclipse (eclipse distribution/projects/workspaces) synched over several stations with Dropbox/SVN

I am trying to setup eclipse and the project/workspaces to works smoothly and efficiently over 3 different computers (not in the same LAN).
Right now I have to do this in every computer:
install a plugin
customize eclipse.ini
customize prefs (I'll keep prefs.epf inside \eclipse folder and keep it synched with care)
I would like to avoid it so I won't end up with different versions of plugins etc in different computers. In order to achieve this, I have decided the following:
\eclipse distribution
I intend to put my \eclipse distribution under Dropbox. The reason for that is to use the exact same eclipse install in the 3 computers I use.
Projects
Projects (src and all resources etc) are synched by using SVN/Hg (I keep some projects under one, others in the other). No problem here. But the same project is stored in different drive/path in different computers (C:\projects\projectA and D:\projectA for example).
Workspaces
I use a different workspace for each project (or group of related projects). So I run eclipse with
-data \path-to-.metadata
My question is, where do I put worskpace folders, and do I synch them?? I have two options:
I keep workspaces inside Dropbox, this way they are synched automaticaly. But will it work?? As pointed out previously the same project can be in diff drive/path in two computers. This is the approach taken by this stackoverflow guy, but not sure if he had diff. drives etc.
I keep workspaces outside Dropbox, they are NOT synched. My question here is whether the same \eclipse will open -data \workspaceAInComputerA and then later open -data workspaceAInComputerB having both same names, projects etc but being totally separate workspaces.
It sounds a bit convoluted maybe but I think it's worth setting it right for long term usage. Anyone can recommend a setup??
thanks
ps: I don't want to keep taking a usb with me so don't suggest any 'portable eclipse' thing please!
This guy seems to have put his workspaces in Dropbox and it seems to be working for him. Personally, I'm putting the Entire eclipse directory + some sdk's in dropbox - we'll see how that goes!
UPDATE: This went horribly wrong for me - just going to use svn/git

Starteam shortcut file

Is it possible to create StarTeam shortcut, opening project and overriding working directory?
Is it possible to create one StarTeam shortcut, opening several projects at a time?
Problem is: I have several solutions, which use the same StarTeam project, and I have to manually change working folder very often (View -> Properties -> Working folder). It is not possible to share data between solutions: local view should be located in separate place for each solution.
You could create different views for each project. Different views can have different working folders; in fact, they do by default. Keep in mind, a view can be set to behave pretty much the same as the default view, with regards to which revisions of files you see. But they can have their own working folders. The downside of this technique is that Change Requests and the like will also be "in the view," so moving them will not necessarily affect other views. But given that you are working on an entirely separate projects, that might not be all such a bad thing. As usual, you should experiment with this in a test project, and make sure you're happy with the behavior, before using it on your "life" repository.
The override/alternate directory for each project and folder is maintained inside a local file - not on the server. The default working folder is kept on the server, and any time you update it the changes are propigating to all other users.
The shortcut xml has no place to specify a working folder.
If you don't need the StarTeam GUI, stcmd allows you to specify a new working folder for most operations with the -rp and -fp flags.
If the projects that need this common library code are in their own views, you could also share the common project into a new subfolder within those other projects. You can use a relative path for this new subfolder that includes .. to move it outside the containing project's folder. This lets you use common code in many projects while allowing you to specify the location of that common code per project.
Shares come with some overhead, so be aware, but other than that it would probably work for what you're trying to do.