What is the better place to locate manually created plugins:
a) C:\Users\{UserName}\AppData\Roaming\Sublime Text 3\Packages
or
b) C:\Users\{UserName}\AppData\Roaming\Sublime Text 3\Packages\User
I have read several articles about ST folders structure, and it is suggested to place such plugins in User (option b) folder, because it will prevent them from overwriting during program updates. However, I am wondering if there some risks and disadvantages of using just Packages (option a).
I'm using ST3.
It's important to know that there is a distinction between a Sublime Text package and a plugin. A package can contain plugin (Python) files..
To answer your question, it is worth bearing the following in mind:
Packages/User is a catch-all directory for custom plugins, snippets, macros, etc. Consider it your personal area in the packages folder.
Keeping plugins directly under the Packages folder is discouraged.
Keeping plugins directly under Packages is discouraged. Sublime Text sorts packages in a predefined way before loading them, so if you save plugin files directly under Packages you might get confusing results.
Having plugins in a subfolder under Packages/User (Packages/User/Foo) will prevent them from working, because ST won't load them automatically.
You could, however, create subfolders in the Packages folder (Packages/Foo), and organize your custom package contents without lumping everything together in the User package folder. As long as the name doesn't conflict with a plugin you have installed from Package Control, updates to other packages won't affect it. This is the technique package authors use while developing their packages.
Related
File templates for WebStorm can be placed in the config/fileTemplates directory of the local WebStorm settings folder.
In addition to the templates stored there, I have a couple of file templates for our project that are in the project SVN repository. I want WebStorm to also offer me these templates.
Is there a way to tell WebStorm to use a specific folder in my working copy on top of the usual fileTemplates directory?
I could find some hints, but they appear to be dead-ends (or maybe I'm missing something):
The documentation on sharing templates makes this sound very manual (as in, moving files around). This is not a viable approach, as the template files might be updated any time. I do not want to preemptively copy the files around after each of my daily working copy updates, just in case on of them has changed (nor do I want to watch out for changes to the templates folder - I want WebStorm to catch up on these udpates on its own).
The article on file and code templates refers to per-project templates that "can be shared among the team members". This sounds like the right thing, except that they have to be placed in the .idea folder (the folder with the project file(s)). As I'm working on a huge project with many submodules, each team member (of several dozen devs) is only interested in a different subset of the overall project, so everyone has their own .idea folder that is not committed to version control.
The article on project and IDE settings indicates that (only?) "Locations of the config, system, plugins directories can be modified in idea.properties file."
I need to work on a repository which is in a Git, I want to know how to work with a project inside the repo in the vivado? I googled it and found that I need to address ".tcl" file in command terminal but, in my "sample project" folder there are multiple ".tcl" files so I got confused if I need to add all of them or not.
Vivado is NOT git friendly and you will need to go several hoops to get it even tolerable.
First, generate tcl script to regenerate the project:
write_project_tcl create_project.tcl
This file can go to git and can be used to generate the project after a clean clone. To be noted that this is not the project file, it's a script that can re-generate the project. So running it every time a project parameter changes is quite cumbersome, and often leads to situation where local projects veers off from the "template" project in git.
Another problem is Vivado generated IP. Fortunately most often you need only the .xci file from the generated files to be stored in git. Unfortunately, by default these are generated as part of the project files, which should not go to git. I would recommend putting the generated IP to some other folder outside the project-structure. Vivado will fight against you on this, but mostly it's worth it.
We have a Mercurial repository with many projects, each resides in its own directory:
- Main Repo
- Project A
- Project B
- ...
Each of the projects is self contained and must reside in it's own directory, but there are some common files that should be similar between projects.
For example, some projects are websites, and they share a common javascript library we develop. When changing the library in one project, we would like it to change in other projects too, but the file must reside in each of the projects.
I read about sub-repos but they don't seem a good solution for this.
Is there a way to accomplish this in Mercurial?
You are looking for a feature for keeping the same file version in multiple places, also known as file cloning or file sharing in other types of source control, like Sourcesafe or Vault. There is no mechanism like this in Mercurial. Every file is a single entity with a single location.
The first solution you have is to keep the common libraries in a separate place. You need a single copy that can be accessed by all your projects. It does not matter if you use sub-repos or not, they can all be in the same repo, as long as your folder structure includes everything, but sub-repos can be easier to manage if your projects are not related.
The other solutions you have could be to state an internal policy to always sync and commit the common libraries manually (which I do not suggest as it is error-prone and requires effort), or to create a script, either as hook or not, to sync your files, before a commit or after an update (which is more tedious to establish and maintain anyway)...
Conclusion, go for the separation of your common libraries. You'll be glad you spent the extra time to set everything up correctly from the start.
Under Unix you could use soft-link (ln -s) for shared files and Mercurial will detect / save / create them. Just don't use absolute or empty path.
With Windows symbolic links won't work:
Tracking hard or symbolic links with mercurial on Windows
Bug 1825 - junction/parse point for windows directory symlinks
In my experience (local Linux repository) using symlinks to handle shared files works but it's usually better to create a library that contains the common files.
Even if you have one repository for all your projects, it is advised to have a separate library/tool/etc. repository(ies) for the common code(s).
The way you can "use" this code inside your project will then heavily depend on your technology and infrastructure: java/maven/ant world, linux distrib, ruby gems etc. You will generally have some kind of "dependencies specification" language where you can specify that you need such and such library. In a Gemfile for rails, using autoconf for C/C++ etc. Most of the time you can also specify a specific version (or greater than etc..) which allows taking care of API changes.
Basically it is not advised to solve this issue at SCM level but instead to use the right framework for decoupling your common code from the projects repositories.
There are one or two files, like .hgignore, which I generally want to be the same in each of a bunch of projects.
However, the nature of these files means that I can't simply move them to a common shared project and just make the other projects depend on that project. They have to be inside each project. Symbolic links are not an option either because some of our developers use Windows.
How can I share these files between repositories and have changes propagated across (on my local machine, at least)? I'm using Eclipse.
For your specific case of hgignore you can put an entry like this in each project's .hg/hgrc file:
[ui]
ignore.common = ~/hgignore-common
If you you know your common library will always the in the parent directory, as is often the case with a subrepo setup you could do:
[ui]
ignore.common = ../hgignore-common
or if you know it will always be in a sibling directory of project checkouts you could do:
[ui]
ignore.common = ../company-wide-defaults/hgignore-common
Unforunately there's no absolute way to reference a file that's valid everywhere, but you can at least to to a point where on your machine all your checkouts are referencing a common ignore.
Hardlinking instead of copying the relevant files sort of works with Eclipse - although you have to refresh each of the other projects to get it to pick up the change. However, you can configure Eclipse to watch the filesystem and automatically refresh whenever it needs to - I recommend this.
It does not work by default with Emacs, because Emacs breaks hard links (which is normally the right thing to do, but is not what you want in this case). However, you can disable this behaviour for multiply-linked files with (setq backup-by-copying-when-linked t).
We recently moved from Perforce to Mercurial and love it!
One little problem: after much research we can't figure out how to map a special directory in the repository to some special place on the client. Here is an example of our hg repo:
/foo/source files
/bar/source files
/build
/macosx/mac make files
/win/windows make files
With Perforce, we were using client spec mappings to map //depot/build/macosx/... to just /build/... on the Mac client, and //depot/build/win/... to /build/... on the Windows dev box. Directories foo and bar are synced as is. Makefiles in /foo and /bar assume that our build makefiles are located in /build and we would like to keep them as is. The final client set of files should look like this:
/foo/source files
/bar/source files
/build/client specific make files
I've read about subrepos, but this solution does not seem to be client specific.
Any idea how to solve this problem will be very much appreciated!
You can't check out only portions of a repository with Mercurial.
You always get a clone containing everything, and the working directory will also contain everything.
With Mercurial you should strive to have 1 repository for 1 project, so that everything you get logically belongs together, and then you shouldn't have much need for just a portion of it.
This also means that whatever directory structure you have in your Mercurial repository will always match exactly the structure you have on disk.
You can't do this with Mercurial as it doesn't have the concept of a client separate from a depot.
However, you can use a symlink on Mac OS X (ln -s) and a junction on windows (mklink on Vista and up using the junction tool on XP http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx) to solve this problem on the file system level.
Alternatively you can use a variable in the Makefiles to refer to the build directory (eg $(BUILD)/something.ext instead of build/something.ext).
This sort of mapping cannot be done in Mercurial. There is an outstanding TODO item for 'narrow' clones so you can check out just a subdirectory. And I could see an implementation of that supporting that sort of functionality. But then again, I know that something like this would be considered a little too 'clever' (read complex) and there would be a lot of push-back on the idea.
In the meantime, I would suggest one of these two solutions.
Symbolic links. Put the symbolic link to your build directory in your .hgignore file. Then each person can make their own symbolic link to the appropriate directory of build files. This has the disadvantage of not working on a platform without symbolic links.
An environment variable that's used in a top level makefile to construct the path to the platform specific makefile it should be calling.