Basically, I have two separate repositories. They're both running FeathersJS, and are slightly different. I was wondering if there was a way to update both repositories if one of the services in one repository is updated, if that service is shared in common with both repositories. Thanks!
Option One: Git
You don't specify the version control system you're using but I'll assume it's Git since that is by far the most popular.
When using Git, there's a way to "embed" repositories within one another so they can be used as-if the code is saved directly in the parent, but is really under it's wn version control. This is called git submodules and whilst it's a great solution, it's also quite complex and may be overkill for what you want.
Basically, you would go from a structure like this:
| - repo1
| - shared file
| - repo2
| - shared file
To this:
| - repo1
| - git submodule: repo3
| - repo2
| - git submodule: repo3
| - repo3
| - shared code
Option Two: NPM
Since you specified you're working with Javascript, you could also use the Javascript package manager; NPM. NPM allows you to "package" code up and then import it into other projects.
NPM is by far more popular than git submodules and learning how to use it will be a valuable skill if you intend to work with modern JS.
In this case, you would move the shared code to a new repo (as you would with Git submodules, above) and then package it and publish it.
Then, you can import this packaged code into your two existing repos.
NPM requires you to have NodeJS installed and that you have a build process in place to import the NPM package and pack everything up in a way your browser can handle it.
Check out the NPM getting started guide for more info.
Feel free to ask any questions in the comments 👍
Related
There is a github repository that is no longer actively maintained. I want to use the code and move it into my project's components but that is tedious and not sure if that is the best approach.
I just want to bump the version of draftjs used by the repository.
Here is the repo and it uses draft js version 0.10.0
https://github.com/brijeshb42/medium-draft
My local project uses draft js version 0.11.7
This causes errors and incompatibility issues.
What is the best approach when a repository uses an outdated version of a repository used by local project?
Before forking and publishing to npm your own version of that dependencies, you might consider using the package/patch-package
Patches created by patch-package are automatically and gracefully applied when you use npm(>=5) or yarn.
No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.
# fix a bug in one of your dependencies
vim node_modules/some-package/brokenFile.js
# run patch-package to create a .patch file
npx patch-package some-package
# commit the patch file to share the fix with your team
git add patches/some-package+3.14.15.patch
git commit -m "fix brokenFile.js in some-package"
In your case, you would be patching the brijeshb42/medium-draft/package.json file.
I've been looking for a solution how to manage my project with git for quite some time now. I want to have one instance as the main repo for connecting the entire project. Each app should be its own git instance.
During my search I found both git submodule and git subtree. For both tools I found an instruction how to insert an existing reppo. However, I am interested in how to proceed from the beginning. I mean here from the command $ django-admin startproject myproject Where do I enter the git init? When I create a new app
$ django-admin startapp new-app and how do I use this as subtree/submodule?
Until now I have always found instructions that refer to a remote repo. Is this always necessary? I am not sure if I want to publish every Django app on Github. But I want a version control system just for me. Is this possible?
I have to say that so far it has been enough to manage my "projects" locally. Now I want to work together with others and I don't want to install the whole Django Project locally but only provide me with single functions or modules.
It would be a great help if you could explain to me how that works.
TL;DR
How to manage (start and expand) a Django Project with git. The apps should be their own git repos.
The purpose of submodules is to allow you to graft an existing repo/library into your git. Rarely do you want to do this. Instead you want to use PIP tools to install your libraries as part of library management.
This is essentially a git question. If you don't have a remote repository, you can still use git. With that said, the reason you want a remote repository is so that you can collaborate with others, and have a stored version of the code separate from your workstation.
There are services that let you have private repos even without a paid account. Bitbucket is the most well known of these services and is comparable to Github in most ways.
I've got Composer installed and I've used it to download HTMLPurifier locally. Now I'd like to push that download to my OpenShift Git repo. So, in a Git Bash window, I run the following...
git add -A :/
git commit -a -m "Uploading HTML Purifier"
git push origin master
At this point Git reports that the push was successful but when I ls the directory through SSH, it shows that the HTMLPurifier directory is empty. Why is that? How do I get Git to push those files?
Additional Info: I noticed that the HTMLPurifier directory is indeed a Git repo itself and contains a .gitignore file in its root directory. I tried deleting it and re-running the above commands but to no avail...
You should try to avoid pushing downloaded dependencies into a repository. It is recommended to add the vendor directory into the .gitignore file at top level. But what you must do instead is commit and push both composer.json and composer.lock.
Here's why: The vendor directory is managed by Composer. Running Composer will probably do minor things during an update, but may also be doing heavy stuff if the Composer team decides to optimize things.
Also, if you require a branch of a package, and Composer knows the repository of that package, it will default to cloning a Git repo or do a SVN checkout instead of trying to grab a ZIP package of that branch (often there is no way to get such a package for branches, and even tagged versions in a plain Git repository do not have such download ability. Composer knows that Github offers such downloads, and detects Github by looking at the repo URL.)
So you can assume that Composer will put a lot of repository meta data into the vendor file, and if you blindly commit these, things will get ugly. First of all, you are committing way too many files, increasing your repository by an unnecessary amount, which will slow down things. Then, if cloning Git repositories, these will be treated as submodules, and that has another bunch of nastiness I am told. If you are just learning Git, it probably isn't a good idea to start with these. And if you are sufficiently known to the tools (Git and Composer), you probably won't need them either.
There really is only one reason why you'd try to commit a modified version of the vendor directory: If your release process is completely depending on all files being present in your one repository, without any way to run a composer install during the release to make these files appear on the target server.
In such cases, you'd install or update the packages with Composer, and then go through all created directories and delete any .git and .svn (and probably also .hg for Mercurial) folders you encounter. Only then you'd be able to commit the files into your own repository.
But note that this step might be a tedious step to do manually - you probably want to create an update script that does all that work for you. You also might run into issues when updating dependencies because Composer expects files to simply go away when deleted, and not be in the way when being written. I cannot tell you exactly what you'd be experiencing because it depends on how you'd do stuff, but I expect you stumbling upon random puzzling issues.
Bottom line: Avoid committing the dependencies into your own repository if possible.
Try using the -force option, you will also most likely need to delete the .git directory inside the HTMLPurifier directory too.
What are the best practices for using one mercurial project in another? I've got a django app that I'm working on, but I'm also using mercurial to version control a website that uses that app. I've looked at mercurial subrepositories, but apparently this is considered a "feature of last resort". Is there a good way of doing what I want to do, or do I just have to copy the code from my app into my website repo when I want to update to a new version of my app?
In your specific case I like to let pip handle my django application dependencies: http://guide.python-distribute.org/pip.html#installing-from-a-vcs
We have in our "website" repo a requirements.txt and our deploy does a pip install --upgrade -r requirements.txt That pulls the latest from the repo and installes it into the application's virtual env. This gives nice flexibility and separation while leaving the package management up to pip. With those VCS urls in pip you can point to a specific tag or branch too if you want different sites using different revisions from the same underlying repo.
pip also has a -e /path/to/file mode for pointing to an "editable" clone that's outside the website repo, which would work too, but I've not tried it.
That said, if you think subrepos fit your workflow better by all means use them. They work just fine, but people often get hung up on the workflow constraints ("What do you mean I can't commit my parent repo w/o also committing in the subrepo?!")
I want to store a project in Mercurial that contains external code (which can be modified by me) coming from Git and SVN repositories. In SVN I would solve this with vendor branches and copy the code around, but I understood that in Mercurial it's better to have different repositories for different projects, and pull between them when needed.
The project layout will be like this:
- externalLibraryA [comes from a SVN repo]
- ...with some extra files from me
- externalLibraryB [comes from a SVN repo]
- ...with some extra files from me
- externalPluginForExternalLibraryB [comes from a Git repo]
In Subversion I would create vendor dir and a trunk dir, copy all external libraries first in vendor, and then in the right place in trunk. (I think) I can do this in Mercurial too, with subrepositories, but is this the best way to do this?
I tried setting up different repositories for the external libraries, but then it seems I can't pull the externalLibraryARepo into the externalLibraryA directory of my main repository? It goes in the main directory, which is not what I want. I can also create a Mercurial mirror repository and include it as a subrepo in my main repository, but then the changes in this subdirectory go to the mirror repository, while I want them to stay in the main repository.
I'd probably just store this in one repository - note that in the link you give they are using their build system in the end to bring together the binary output from the different repos. I'm not clear on their rationale there.
If the underlying problem you're trying to solve is how to update the externals in a clean way, I'd probably use anonymous branching for that.
I.e. add the external lib to your project, and your modifications. Make sure it works. Tag with ExternalA-v1.0. Hack away on your actual project. Now ExternalA, Inc. has a new version of their stuff. Update your repo to ExternalA-v1.0 tag. Import their new version and apply your modifications on top. Commit. Now you have two heads: one with the latest version of your code (that works with ExternalA-v1.0) and one with the latest version of ExternalA (that does not work with your code, maybe). So then you merge and reconcile the two. Tag again, now with ExternalA-v2.0. Repeat as needed.
You can still keep your externals in separate repositories, but I assume that the project that is using those does not need to be up to date with changes there all the time - looks like the whole point of vendor branches is to have some point of isolation between dependee and dependants. Of course, moving the changes from the externalA project to the project that is using that will then be a manual affair (well, a copy, much like in SVN really).
It depends on whether your vendor code is going to be customized by your team or not. Our teams have had a great deal of success maintaining a named "vendor" branch on repositories with our own customizations on branches named by project name. This vendor code is then easily included in a project as a subrepository.
A caveat to this approach: if active development is going on in the subrepository, best keep it to directly editing the subrepository as a separate clone, otherwise it becomes necessary to pay close attention to the top-level repository so you don't inadvertantly bump your .hgsubstate forward to the wrong revision and break your build.
Watch out for merges of the top-level repository (your project) between versions which point to different named branches of your subrepository, as this can result in a merge between the "vendor" and "project" branches in the subrepository as it recurses, which may not be desirable.
Note that this functionality may change in the future as well, as some "warm" discussions have been taking place in recent months on the mercurial-devel mailing lists about the future of subrepository recursion.
edit:
I just saw this discussion in the related links as well, which seems relevant: https://stackoverflow.com/a/3998791/1186771