Table of Contents |
---|
Info |
---|
The OpenMRS community is currently in the process of evaluating Git as a replacement for SVN. |
...
Note |
---|
When creating a new module or contrib, please e-mail ?code@openmrs.org to request a module ID or contribution name, including your OpenMRS ID, a description of your module/contribution, and your proposed module ID or contribname. The conversation with the "code" e-mail group is used to avoid duplicates and maximize consistency of naming; you should expect a module ID to be decided within one day of your request. Eventually, we hope to create a more automated process for ensuring uniqueness of module identification & awareness of existing modules. |
...
Copy the list of authors from ?Github Authors txt/wiki/spaces/docs/pages/25520562 into an authors.txt file and from that folder, start with:
...
Info | |||||
---|---|---|---|---|---|
If you get an error from svn2git, it's possible that one or more users are missing from the authors.txt file. Checkout a local copy of the module from svn and list out all authors who contributed to the module:
Make sure each of these users has an entry in the authors.txt file. If anyone is missing, then find their corresponding git name and e-mail (if you cannot find these, e-mail the dev mailing list and ask for help). NB Other alternatives to svn2git include;
Git comes with a pre-installed tool called svn-git see https://aboullaite.me/migration-from-svn-to-git-a-developer-guide/ svn2git is just a wrap up tool around git's svn-git , and it makes using svn-git more easier and flexible .However in some cases , it may be better to use svn-git directly 2. The github Importer The github Importer is also a great and easy to use tool to use for conversion and migration of repos from svn to git see https://help.github.com/en/articles/importing-a-repository-with-github-importer |
Once the complete project is converted from svn to git format, you need to get it up to GitHub.
- Create a new repo in Github (or ask for one for the OpenMRS org from code@openmrs.org)
- Name: openmrs-module-yourmoduleid
- Description: a one-line description of what the module does (look at others for examples)
- Make it public
- Initialize with a README
- Add .gitignore for maven
Edit the module's pom.xml to use the github address
No Format <scm> <connection>scm:git:https://github.com/openmrs/openmrs-module-yourmoduleid/</connection> <developerConnection>scm:git:https://github.com/openmrs/openmrs-module-yourmoduleid/</developerConnection> <url>https://github.com/openmrs/openmrs-module-yourmoduleid/</url> </scm>
Change the local repo you just converted to point at that one github repo "origin" (below)
Code Block language bash $ git remote add origin https://github.com/openmrs/openmrs-module-yourmoduleid.git
Code Block language bash $ git pull origin master
Assuming that your module uses the OpenMRS license and it wasn't already in subversion's root, add it:
Code Block language bash wget https://raw.github.com/openmrs/openmrs-core/master/license.txt
Commit your changes locally
Code Block language bash $ git add . $ git commit -m "migrating from svn to github"
Push the code to github (below)
Code Block language bash $ git push
Push the tags manually using the following command.
Code Block language bash $ git push --tags
- Add default teams to the new github repository:
- Full Committers
- Partial Committers
- Repo Owners
- Under the Admin section for the new github repository, make sure Wiki & Issues are unchecked (we don't want wiki & issues going into github; rather, we want people using wiki.openmrs.org and jira.openmrs.org)
...
It's preferable that older modules be mavenized prior to migrating to git, since it significantly reduces the size of the repository, making it easier for low-bandwidth developers to clone the repository locally. If your module is not yet mavenized, see ?Converting old code to Maven.
...
We have a shared authors file. Please use and add to this as needed: Github Authors txt /wiki/spaces/docs/pages/25520562!
IDE integration
Include Page | ||||
---|---|---|---|---|
|
Best Practices
Here's the set of best practices to follow in distributed OpenSource projects.