I'll try to explain my situation as concise as possible:
I have a template project that I use as a template (duh) when starting a new project.
This template project evolves, and sometimes I update it as I am working on another project.
So imagine that:
Template project: template.file
Project A: template.file & projectA.file
Project B: template.file & projectB.file
(all projects are under revision control) Now when I change template.file in project A, I would like all other template.files in all other projects to update
I am on windows, using tortoisehg and I am relatively new at this versioning game. I suppose I would do this with branches? But then wouldn't the projectA.file and ProjectB.file also get added to the template project?
Here is something you could do:
Go into the template project and merge in project A, then prune everything you didn't want before committing. This is rather laborious and time consuming.
Then you can go into project be and pull from the template project and very carefully merge.
I would not do this for any number of reasons. First, it's messy and error prone. Secondly it results in both projects containing all the files of all the other projects, even if in the tip revisions those files are considered deleted. The history is still all there.
Here is another thing you could do:
Use hg export to export the change that modifies the template file from project A. Then use hg import to import that change into your template project.
Then pull from the template project into both project A and project B and merge.
This requires that you discipline yourself when modifying project A and always make modifications to template files their own change.
Alternatively, you can hand modify the exported change to remove extraneous changes.
Here is a third thing you could do:
Always modify template files only in the template project. Then you can pull from the template project into projects A and B and merge.
There's nothing in Mercurial that will you out of the box with this, cleanly.
You could:
Stuff everything inside one big repository, just separate them into different directories
Use sub-repositories, meaning that Project A and Project B would reference the template project as a sub-repository
Just make a copy of the file in question to all the other projects/repositories
In either of these 3, there's nothing that will help you make sure a file inside each repository is in sync.
In the first case, you would have 3 distinct copies of the template.file, and updating one will not update the other two, and there's nothing in Mercurial that will help you with that.
In the third case, the three repositories are completely distinct and separate, which means changes in one does not propagate into the other.
The second case, however, can be done, but if you need to have a copy of the file inside the Project A/B repositories, you're back to the third case.
However, you can make the template project a sub-repository of Project A, and instead of making a copy of the file, out of the template project and into Project A, you refer to the one you have in the sub-repository.
This is the way Mercurial handles such things.
Related
I was wondering if there is a way to search for keywords in the code through multiple code repositories at once? Preferably I would like to specify a subset of repositories i.e. only those with a marking or organization, and then for a given keyword it would return the matched line together with the source repository and file.
If not wrong, it is impossible inside Foundry, but...
I would suggest a workaround.
You could clone the repository locally in your machine and then, opening the synced folders using VS Code, use its search feature, that is able to go through different folders content.
Clone function is available inside each code-repo, and in order to proceed you will need both a git client and VS Code installed locally.
Due to security reasons, I have to split one project to divisions (client, admin, ...), and deploy them to different web servers. These divisions have one common script base, but each division has its own functions. As an IDE I use PhpStorm.
The question: what is the best way to organize project's structure and settings, so the common core part will be visible for IDE indexing in all project's divisions, but at the same time, being maintained from a single project (perhaps, standalone)?
In Java you can do lib jar files for further linking in various projects.
But how it can be done in PHP?
There are multiple ways of how to reference extra PHP code in a project.
If you plan to actively edit such extra code in the same project (and want to see their TODOs, code inspection warnings, include references in code refactoring etc):
You can just add it as an additional Content Root: Settings/Preferences | Directories. Folder added this way will be treated as a part of the project itself and will be shown as a separate node in the Project View panel (just as the main code, which is a Content Root as well).
Or you can open 2nd project while 1st one is already opened and when asked, just chose "Attach":
It's not going to be full 2 projects in one frame, more like something in between attaching Content Root and having 2 projects opened in separate frames.
https://www.jetbrains.com/help/phpstorm/opening-multiple-projects.html
Simple symlink will also do the job (but you need to place it somewhere in a project, e.g. PROJECT_ROOT/libs/my_symlinked_code). You then will need to provide a path mapping for that folder for debugger (if you will debug it of course) as PHP/Xdebug works with "final/resolved path" while IDE works with the path as is.
If you do not need to actively edit that extra code in the same window (and ignore any TODOs, code inspection warnings and other inspection results etc):
Do it as a composer package then? Composer can use custom sources (e.g. GitHub repo or a folder on a local filesystem).
Just add the path to that folder as a "Include Path" at Settings/Preferences | Languages & Frameworks | PHP --> Include Path tab. Code referenced this way is meant for 3rd party libraries (the code that you just use but not edit, e.g. framework code, your send mail/ORM library etc). Composer packages will also be included here by default.
https://www.jetbrains.com/help/phpstorm/php.html#include-path-tab
I opened my project on another computer, and the files where I'd been using a file watcher were expanded, like before they used to be nested like home.scss is now after I run the watcher once on that file.
Is there a way to automatically make all the files be nested?
Because when adding new files and folder with git, it would be quite troublesome to go into each and every file in order to make them become nested.
Like I have some minified JavaScript files that used to be nested, but now is expanded for some reason.
Hope you understand. Thank you.
Edit: Nested***
Is there a way to automatically make all the files go under a caret like that?
Unfortunately not. Such nesting information (to "go under a caret" as you are saying) is taken from "Output path to refresh" field of the corresponding File Watcher.
You have to run file watcher for such files at least once in order to see files nested like you have it on your another computer.
Here is how you can run File Watchers manually without the need to modify those files (so no extra history will appear in your git (or whatever VCS you may be using there)).
https://stackoverflow.com/a/20012655/783119
P.S.
In PhpStorm 2016.3 (the next version that will be released in 1.5-2 months or so) such nesting will be done automatically (the most common combinations) so there will be no need to have File Watchers for providing such info.
If you wish -- you can try EAP build right now (EAP means Early Access Program .. which is sort of Alpha/Beta builds (simply speaking).. and therefore some bugs for new functionality might be present and performance may not be optimal).
I am in the process of rebuilding a API documentation site for an open source project where we want to keep an archive of previous releases. I am wondering how I can configure Jekyll to generate the right hierarchy?
We have the following directory layout in our current /docs folder (which we would like to reuse in Jekyll somehow):
current/
v1/
v2/
v3/
Whenever we release a new version the current folder gets copied to a new folder (say v4). The contents of each folder is something like this:
introduction.md
testing.md
api-foo.md
api-bar.md
I'd like these to be available under the url domain.com/v3/testing/, domain.com/current/testing/, etc. I see that I could probably employ collections to do this, having one collection per version. To do this I see myself auto-updating the _config.yml as part of a build script (I made an example doing this here), but I am not sure how to progress from here, or if using collections for this is the wrong approach ...
This is too brief of an update to be of real quality, but thought I would mention that we solved this in the end in the Sinon project. Check out the repo at GitHub sinonjs/sinon and see the docs folder as well as the scripts called from package.json.
Feel free to improve on this answer by editing it and adding content and links.
I would like to keep two versions of a static html file in my git repository. Both are basically identical, except for links for scripts, media etc (dev version vs. live version).
Right now I keep the dev version in repo, and overwrite the live version values manually on the live machine (=I have local git changes there). I am not happy with this setup, because there's manual labour for each push/pull.
What is the best flow for managing files that cannot be split into config/rest sections (like HTML)?
You could...
Remove the file from your repository and just manually populate it. If it doesn't change very often, this works just fine.
Remove the file from your repository, and generate it from a template via a post-merge script in .git/hooks/post-merge (this hook is run, for example, after git pull).
Name the file after the branch or hostname or some other variable (e.g., static.master.html vs. static.develop.html, etc) and dynamically determine which one to use at runtime.
Those are some ideas. I imagine other folks will contribute additional suggestions.
Expanding on the 2nd bullet point by larsks:
You could keep two copies in the repo (say it were your homepage) index.dev.html and index.prod.html. On the remote, your post-merge script could do something like:
cp -a index.prod.html index.html
or
truncate -s 0 index.html
cat index.prod.html >> index.html
Another problem beside renaming is to keep the content of the both files in sync. So having dedicated files for the same reason only differing in one minor path is a lot of redundncy, if you change one, you have to think on updating the other as well.
OK, you stated that the HTML file is static, but here a line of PHP to generate the difference would solve our problem
Achim