Ive been looking on the the internet for answer but none comes close to what i was looking for. What is the folder for?
and inside is this json file:
What happen if i delete the folder and do i really need that to be in the folder? Thank you
Short answer:
If you delete it, probably nothing much bad will happen. It'll probably get created again. Your live server may or may not end up on the same port. Probably don't commit it to source control (but maybe you want to).
Longer answer:
.vscode as a folder name has a few clues:
the leading . kind of means "hide this folder". It comes from *nix operating systems where by default if you name a file or folder .anything it'll get hidden.
being called .vscode, which is the name of the editor you're using, suggests it relates specifically to using vscode.
The fact that it gets created when you "do something" suggests that it'll cope if it's not there, but probably the way it'll cope is to re-create it. That's a pretty common thing too.
One use for a settings.json file in a folder is for settings that are specific to that folder. Often you'd have settings that you want to apply to vscode wherever you're using it. But sometimes you have settings that apply to a specific bit of code.
The people that wrote the LiveServer extension seem to think that what port the live server runs on is one of those "per project" settings. I'd agree. You may want to run 2 or 3 live servers (e.g. a PHP web-site and another one that just does API, maybe), or the port that they chose might be in use by something completely else. So to deal with that, they create this settings file. I'd take a stab that if you edit that, then the LiveServer is going to show up on a different port.
But you can probably find the code and check it. Probably this document will tell you what to know.
https://github.com/ritwickdey/vscode-live-server/blob/HEAD/docs/settings.md
(A possibility here that I've chosen the wrong extension, but most vscode extensions are open source, so you should be able to follow the trail to a github repo, and then to either some docs or some code).
Editor settings are that border-line with source control - whether to check in or not. Lots of projects have defined editor settings, such as tabs vs spaces or linting engines. Lots don't. Possibly in this case, if you're part of a large project, the specific ports to use are defined, so it'd go into source control. If it's just you, do what feels good.
I'm using VS code (v1.74.3),Live Server (v5.7.9). There is no settings.json in .vscode folder of my JS project. Instead the settings.json is created in the folder "C:\Users\USER NAME\AppData\Roaming\Code\User" and it is a global settings file to specify extension properties. Most of the Live Server configuration settings mentioned in the documentation can be applied at global level.
My source files are divided into multiple repositories and they are located in different directories. I've created separate PhpStorm projects for each repository. So I'd like the PhpStorm search functions work across some of the projects. How can get this done? How can I mark dependent projects in PhpStorm?
Note: I've tried making the top folder as "Project Root". But that project root contains many other projects which I don't need so it's little bit inefficient from my point of view.
I've used Netbeans and I can do this by going to project properties and setting include path. I found similar option in PhpStorm at File > Default Settings > Language & Frameworks > PHP and set include path. But PhpStorm search functions/file open doesn't work for the include path.
Or at least how can I open multiple projects in same window.
My PhpStorm info
PhpStorm 2016.2.1
Build #PS-162.1889.1, built on August 23, 2016
Licensed to PhpStorm Evaluator
Expiration date: October 10, 2016
JRE: 1.8.0_76-release-b216 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Depending on who says it, it is either a MYTH or a LIE that PHPStorm really supports working with multiple projects in the same window.
It allows you to open multiple projects in one window, but it doesn't really support working with them in any meaningful way.
There is no way to indicate which of the many opened projects you have in mind whenever you invoke any operation that involves the notion of "current project". The "current project" choice is immutable for the lifetime of the "workspace": it is precisely the first project that was opened/created in it, and there is no way to mark any other project as current / active / "the one you have in mind".
All supposedly "per-project" configuration settings are in fact the settings of this "main" or "host" project, the first one that was added to the workspace. There is no way to configure anything per any of the further projects that you attached to the workspace later. Those further projects are not first-class citizens in the workspace.
This design has been thus broken since the beginning, and there have been FURTHER breakages that exacerbated this problem. For example, PHPUnit run configurations used to have some awareness of the project in which the relevant phpunit.xml is located, and it was possible, albeit hackily, to customize some configurables per project. This ability has since been removed by developer's conscious, actively user-hostile decision.
Open your project
Settings/Preferences | Directories
Use Add Content Root button and point to a desired folder
Once settings are saved -- those newly added Content Root(s) will become part of the project and will be listed as additional nodes in Project View.
Basically -- the main project folder is a Content Root by itself; using the above you are just adding additional folders to the project-- they will be treated in the same way as main Content Root.
Obviously, since those extra folders will become part of this project, current project settings will be applied to those folders as well.
PHP | Include paths are for the 3rd party code/libraries which you just use in your project but not edit them.
In PhpStorm 2016.3 (currently in EAP stage) it will be possible to open additional projects as part of the current one. This allows cross-project search/refactoring etc.
Once opened like that .. such additional projects will use settings from current project -- just like additional Content Roots do (basically, a bit easier0to-use version of the above). It will NOT work like NetBeans does where you have a "workspace" and can manage multiple projects with separate settings.
Some links:
Actual ticket with important details: https://youtrack.jetbrains.com/issue/WI-15187#comment=27-1590927
Latest public EAP builds: https://confluence.jetbrains.com/display/PhpStorm/PhpStorm+Early+Access+Program
Follow PhpStorm's Blog to be notified about new EAP releases and changes made: https://blog.jetbrains.com/phpstorm/
I found similar option in PhpStorm at File > Default Settings > Language & Frameworks > PHP and set include path.
Default Settings affect future new projects ONLY -- they do not affect existing projects in any way.
If anything -- it should have been done via just File | Settings (Windows/Linux) or PhpStorm | Preferences on Mac.
But PhpStorm search functions/file open doesn't work for the include path.
Not exactly.
They "do not work" because files from such folders are not intended for editing -- they are just for reference purposes. You still can search/open them .. but you have to use additional options (e.g. in Find in Path it could be including "Libraries" scope; in Navigate | File and similar -- "include non-project files" or so).
You can also ignore files/folders per project too from the Project Structure window.
Yesterday I tried updating from MATE 1.4 to MATE 1.6. I didn't like some things about it, and I decided to switch back, at least for now. One of the changes was a switch from the mateconf configuration system to GNOME 3's GSettings. As I understand this is a frontend to a system called dconf (or connected some other way).
This rendered many of my settings viod. I figured I could try to migrate them, but unlike gconf and mateconf, which created convenient folders in my home directory and filled them with XML I could edit or copy, I wasn't able to find any trace of dconf's settings storage.
A new Control Center is provided (and mandatory to install) but I don't want to be clicking through dozens of dialogs just to restore settings I already have. The Configuration Editor utility might be okay, but it only works with mateconf.
So what I want to know is where I can find the files created by dconf and how I can modify them directly, without relying on special tools.
I almost forgot that I asked this, until abo-abo commented on it. I now see that this is a SuperUser question, but for some reason I can't flag it. I would if I was able to.
The best solution I found was to install dconf-tools, which is like the old conf-editors.
As for the actual location of the data on disk, it seems to be stored in /var/etc/dconf as Gzipped text files, but I'm not entirely sure because I'm not using Mate 1.6 right now. I wouldn't advise editing them directly.
I've been having another issue with dconf, and I checked the folder that I mentioned above. It doesn't even exist. There now seems to be a single configuration file at ~/.config/dconf/[USERNAME]. It isn't in text format, so special tools are required to edit it.
This might be the result to an update to dconf.
I had a similar problem (was trying to back up keyboard custom shortcuts). The path for that was:
dconf dump /org/gnome/desktop/wm/keybindings/ > wm-keybindings.dconf.bak
dconf dump /org/gnome/settings-daemon/plugins/media-keys/ > media-keys-keybindings.dconf.bak
This thanks to redionb's answer on Reddit.
I'm working on a project with two other developers that's built on FireBreath. So far, I've been able to get things working perfectly on my machine, but we need to coordinate our development via Mercurial. So I pushed my files to the repository and thought all was well.
Unfortunately, that doesn't work.
The various .vcproj files that make up the solution all contain hard-coded references to my local file system. This works fine for me, because I'm not moving the project around. But when you try to build the solution on another machine with a different file structure (different drive letter, different folder location, etc.) everything breaks.
I used FireBreath's standard project generation script (Python) and then the Visual Studio CMake script (prep2008.cmd) to generate the solution files. What can I do to tweak things so that other developers can use the same code base?
If your developers are not using the same build/make/project files, this could quickly become a maintenance nightmare. So you should definitively all use the same .vcproj files. (An exception to this would be if the project files were generated from some other files. In that case treat those other files in the way described above.)
there's two ways to deal with the problem of differing setups on different machines. One is to make all paths relative to the project's path. The other is to use environment variables to refer to files/tools/libraries/whatever. IME it's best to use relative paths for everything that can be checked out with the project, and use environment variables for the rest. Add a script that checks for the existence of all necessary environment variable, pointing out the meaning of any missing ones, and run this as a build prerequisite, so whoever tries to get a new build machine up and running gets hints at what to do.
To make sure that everyone caught the updated comments from sbi's answer, let me give you the "definitive" answer from the FireBreath devs.
Your build directory is disposable; you should never share .vcproj files. Instead, you should regenerate your build/ directory any time you change the project and on each new computer, just like any project that uses CMake.
For more information, see http://colonelpanic.net/2010/11/firebreath-tips-working-with-source-control/
For reference, I am the primary author of FireBreath and I wrote the article.
I'm not familiar with FireBreath, but you need to make the references relative, and then recreate that relative structure on every machine. That is, if your project sits in "c:\myprojects\thisproject" and has an additional include directory "c:\mydir\mylib\include", then the latter path needs to be replaced with "....\mydir\mylib\include".
EDIT: I rewrote my anyswer to make it clearer. When I got you correctly, your problem is that FireBreath generates those .vcproj files with absolute paths in it, and you want to use this .vcproj files on a different developer machine.
I see 3 options:
Live with it. That means, make sure, every team member has the same file structure / view to the file system, tools installed in the same place.
Ask the authors of FireBreath to change their .vcproj generator to allow relative paths, use of environment variables etc.
If 1 or 2 does not work, write a program or script for changing the absolute path to relatives in those .vcproj files. Run this script whenever you have to regenerate your FireBreath project.
What you should not do due to the FireBreath FAQ: don't change the .vcproj manually, those changes will be lost next time the project is regenerated.
EDIT: seems that "option 4." turned out to be the best solution: generating those .vcproj files for each developer individually. Hope my suggestions were helpful, either.
It would be nice to have a more or less complete list over what files and/or directories that shouldn't (in most cases) be under source control. What do you think should be excluded?
Suggestion so far:
In general
Config files with sensitive information (passwords, private keys etc.)
Thumbs.db, .DS_Store and desktop.ini
Editor backups: *~ (emacs)
Generated files (for instance DoxyGen output)
C#
bin\*
obj\*
*.exe
Visual Studio
*.suo
*.ncb
*.user
*.aps
*.cachefile
*.backup
_UpgradeReport_Files
Java
*.class
Eclipse
I don't know, and this is what I'm looking for right now :-)
Python
*.pyc
Temporary files
- .*.sw?
- *~
Anything that is generated. Binary, bytecode, code/documents generated from XML.
From my commenters, exclude:
Anything generated by the build, including code documentations (doxygen, javadoc, pydoc, etc.)
But include:
3rd party libraries that you don't have the source for OR don't build.
FWIW, at my work for a very large project, we have the following under ClearCase:
All original code
Qt source AND built debug/release
(Terribly outdated) specs
We do not have built modules for our software. A complete binary is distributed every couple weeks with the latest updates.
OS specific files, generated by their file browsers such as
Thumbs.db and .DS_Store
Some other Visual Studio typical files/folders are
*.cachefile
*.backup
_UpgradeReport_Files
My tortoise global ignore pattern for example looks like this
bin obj *.suo *.user *.cachefile *.backup _UpgradeReport_Files
files that get built should not be checked in
I would approach the problem a different way; what things should be included in source control? You should only source control those files that:
( need revision history OR are created outside of your build but are part of the build, install, or media ) AND
can't be generated by the build process you control AND
are common to all users that build the product (no user config)
The list includes things like:
source files
make, project, and solution files
other build tool configuration files (not user related)
3rd party libraries
pre-built files that go on the media like PDFs & documents
documentation
images, videos, sounds
description files like WSDL, XSL
Sometimes a build output can be a build input. For example, an obfuscation rename file may be an output and an input to keep the same renaming scheme. In this case, use the checked-in file as the build input and put the output in a different file. After the build, check out the input file and copy the output file into it and check it in.
The problem with using an exclusion list is that you will never know all the right exclusions and might end up source controlling something that shouldn't be source controlled.
Like Corey D has said anything that is generated, specifically anything that is generated by the build process and development environment are good candidates. For instance:
Binaries and installers
Bytecode and archives
Documents generated from XML and code
Code generated by templates and code generators
IDE settings files
Backup files generated by your IDE or editor
Some exceptions to the above could be:
Images and video
Third party libraries
Team specific IDE settings files
Take third party libraries, if you need to ship or your build depends on a third party library it wouldn't be unreasonable to put it under source control, especially if you don't have the source. Also consider some source control systems aren't very efficient at storing binary blobs and you probably will not be able to take advantage of the systems diff tools for those files.
Paul also makes a great comment about generated files and you should check out his answer:
Basically, if you can't reasonably
expect a developer to have the exact
version of the exact tool they need,
there is a case for putting the
generated files in version control.
With all that being said ultimately you'll need to consider what you put under source control on a case by case basis. Defining a hard list of what and what not to put under it will only work for some and only probably for so long. And of course the more files you add to source control the longer it will take to update your working copy.
Anything that can be generated by the IDE, build process or binary executable process.
An exception:
4 or 5 different answers have said that generated files should not go under source control. Thats not quite true.
Files generated by specialist tools may belong in source control, especially if particular versions of those tools are necessary.
Examples:
parsers generated by bison/yacc/antlr,
autotools files such as configure or Makefile.in, created by autoconf, automake, libtool etc,
translation or localization files,
files may be generated by expensive tools, and it might be cheaper to only install them on a few machines.
Basically, if you can't reasonably expect a developer to have the exact version of the exact tool they need, there is a case for putting the generated files in version control.
This exception is discussed by the svn guys in their best practices talk.
Temp files from editors.
.*.sw?
*~
etc.
desktop.ini is another windows file I've seen sneak in.
Config files that contain passwords or any other sensitive information.
Actual config files such a web.config in asp.net because people can have different settings. Usually the way I handle this is by having a web.config.template that is on SVN. People get it, make the changes they want and rename it as web.config.
Aside from this and what you said, be careful of sensitive files containing passwords (for instance).
Avoid all the annoying files generated by Windows (thumb) or Mac OS (.ds_store)
*.bak produced by WinMerge.
additionally:
Visual Studio
*.ncb
The best way I've found to think about it is as follows:
Pretend you've got a brand-new, store-bought computer. You install the OS and updates; you install all your development tools including the source control client; you create an empty directory to be the root of your local sources; you do a "get latest" or whatever your source control system calls it to fetch out clean copies of the release you want to build; you then run the build (fetched from source control), and everything builds.
This thought process tells you why certain files have to be in source control: all of those necessary for the build to work on a clean system. This includes .designer.cs files, the outputs of T4 templates, and any other artifact that the build will not create.
Temp files, config for anything other than global development and sensitive information
Things that don't go into source control come in 3 classes
Things totally unrelated to the project (obviously)
Things that can be found on installation media, and are never changed (eg: 3rd-party APIs).
Things that can be mechanically generated, via your build process, from things that are in source control (or from things in class 2).
Whatever the language :
cache files
generally, imported files should not either (like images uploaded by users, on a web application)
temporary files ; even the ones generated by your OS (like thumbs.db under windows) or IDE
config files with passwords ? Depends on who has access to the repository
And for those who don't know about it : svn:ignore is great!
If you have a runtime environment for your code (e.g. dependency libraries, specific compiler versions etc.) do not put the packages into the source control. My approach is brutal, but effective. I commit a makefile, whose role is to downloads (via wget) the stuff, unpack it, and build my runtime environment.
I have a particular .c file that does not go in source control.
The rule is nothing in source control that is generated during the build process.
The only known exception is if a tool requires an older version of itself to build (bootstrap problem). In that case you will need a known good bootstrap copy in source control so you can build from blank.
Going out on a limb here, but I believe that if you use task lists in Visual Studio, they are kept in the .suo file. This may not be a reason to keep them in source control, but it is a reason to keep a backup somewhere, just in case...
A lot of time has passed since this question was asked, and I think a lot of the answers, while relevant, don't have hard details on .gitignore on a per language or IDE level.
Github came out with a very useful, community collaborated list of .gitignore files for all sorts of projects and IDEs that is worth taking a look.
Here's a link to that git repo: https://github.com/github/gitignore
To answer the question, here are the related examples for:
C# -> see Visual Studio
Visual Studio
Java
Eclipse
Python
There are also OS-specific .gitignore files. Following:
Windows
OS X
Linux
So, assuming you're running Windows and using Eclipse, you can just concatenate Eclipse.gitignore and Windows.gitignore to a .gitignore file in the top level directory of your project. Very nifty stuff.
Don't forget to add the .gitignore to your repo and commit it!
Chances are, your IDE already handles this for you. Visual Studio does anyway.
And for the .gitignore files, If you see any files or patterns missing in a particular .gitignore, you can open a PR on that file with the proposed change. Take a look at the commit and pull request trackers for ideas.
I am always using www.gitignore.io to generate a proper one .ignore file.
Opinion: everything can be in source control, if you need to, unless it brings significant repository overhead such as frequently changing or large blobs.
3rd party binaries, hard-to-generate (in terms of time) generated files to speed up your deployment process, all are ok.
The main purpose of source control is to match one coherent system state to a revision number. If it would be possible, I'd freeze the entire universe with the code - build tools and the target operating system.