We know that we are moving to a distributed versioning tool. We haven't committed to Git (e.g., vs. Mercurial) at this time. |
The OpenMRS Developer Community is anticipating migrating to distributed versioning of our code. This page serves as a point of communication about the process.
Background
Distributed code versioning has become a more popular form of sharing code in place of the centralized model.
Need to pull pros/cons, etc. from notes up here |
Requirements
- A clear understanding of how the new versioning system will effect our developers
- Branching
- Merging changes
- Submitting patches
- Releases
- A way (through APIs at code-hosting sites and/or conventions for repositories) for OpenMRS to find and organize existing repositories for the community's benefit
- Tutorials for developers to ease the transition
Road Map
Links
Session: Migrating to Git/DVCS - Wednesday 11:00 11:17 - 12:30
Facilitator: ~bmamlin
Note taker: ~michael
Timekeeper: ~mseaton
Pre-session questions:
- Do we want to change development models (i.e., distributed)?
- If we do, how do we get there?
Notes from session
- Who knows what Git is? (Most)
- Right now we are using Subversion. There are several distributed tools, the major ones being Git and Mercurial.
- Rather than discuss git or mercurial, let's talk about moving to distributed system (or not!).
- Using svn, there is some level of management overhead to manage the repository access. These restrictions also make it more difficult for newcomers.
- In the distributed model, everyone gets their own copy of the repository. The concept of pushing and pulling is how those changes get shared with others.
- Do we want to consider changing to a distributed coding style? Lots of projects are moving that way, and no one seems to be moving back (to centralized/svn model). What's the path to make the move?
- With semi-good internet (off and on), it's possible to work locally.
- What are the pros and cons of each?
- You still have an official version, but essentially it's forked infinite times.
- In DVCS, "forking" is encouraged as opposed to SVN.
- With semi-good internet (off and on), it's possible to work locally. Encourages committing (locally) more often. "Beneficial for sanity."
- Massive benefit of not needing constant network connectivity.
- Concern that if there's too much local committing behavior and not enough pushing to a server, stuff might be lost in accidents. (Could set up a shell script or automation to counter this problem.)
- Branching and merging is "seamless" compared to SVN, especially for devs that don't have access to the main repo.
- Common to have many branches for different work.
- Does this mean we don't have to deal with patch files any more?
- The git web UI will show changes in a rich view.
- Less oversight necessary with DVCS compared with our current SVN management.
- Who's using it for OpenMRS already? How's it working?
-
- Kishore is using git for his OpenMRS work. Has a tool to essentially mirror our svn repo. Several other people point to his git project and then he sends up patches to SVN. This is for branches/trunk but not for modules.
- How does the IDE support DVCS? What effects?
- POSIX-style terminal/command line for windows.
- Mac experience was better than Windows experience for one person.
- Kishore uses IntelliJ with good results. Comes integrated.
- Jeremy used CloudIDE
- Eclipse plugin is available (now at 1.0!). Eclipse Foundation is using git now so they need better tools for themselves!
- Conflict resolution is pretty good and merge tools are available. Netbeans has conflict resolution built in.
- Darius had to manually edit things in Notepad after trying to merge.
- What's the learning curve? Is this another Maven switch?
- Starting with a module or two should help.
- Maven has often taken more than it's given.
- How would our workflows change?
- A module owner (team or individual) would probably still own a master copy of their code somewhere.
- We would still want the module repository for binary downloads.
- Currently we ask module developers to contact us in advance to ensure module names are sensical and unique, and to "approve" their svn access.
- Who should maintain repositories/projects for modules? What modules should the OpenMRS core team maintain?
- A big change for us would be to "let go" and let the community drive things more than today.
- There's a concept of "collaborators" in git who can discuss pull requests.
- Revision numbers would be replaced with a commit hash. These are less intuitive. ThoughtWorks still uses the sequential build numbers for releases. Maven release plugin tracks the builds inside the project with a text file that's stored in the project.
- Have individuals added to a GitHub organization. They could then add their repositories to the OpenMRS org (particularly for bundled modules?).
- How will our tools and infrastructure work with DVCS?
- FishEye, Crucible, JIRA, etc., will still work with git, essentially as it does today. Git, i.e., would essentially replace svn's presence. The process would remain more or less the same.
- We need to make clearer the responsible parties for each module, most likely in the module repository. Right now there is no such ownership or control.
- Burke's idea: Lower the barrier to create modules. Allow people to make stuff and post it to github. Provide a wiki page (or something else) as a an "official" registry of recognized modules.
- What would it take to move? What would a migration timeline/roadmap look like?
- We would have several authoritative OpenMRS projects hosted on GitHub or something similar.
- Each module would be a git project, and labeled/tagged appropriately.
- Would SVN remain up for projects that don't migrate to git?
- Burke: Maybe take some core modules and move them to git. Mark suggests starting with HTML form entry.
- Rowan gets to teach svn, git, maven, and ant!
- We would need to consider github, Google Code project hosting, Bitbucket, etc.
- Should we trim out some of what's currently in SVN when importing it into a DVCS? Can we exclude specific files?
- We should move repos individually, e.g., trunk, modulex, moduley, individual items under openmrs-contrib, etc.
- We should have a resource on the wiki for moving to git, resources, learning, tools, etc.
http://git.or.cz/course/svn.html Here's a good tutorial which maps all the svn commands to git commands.
Outcome: We have committed to move forward to evaluate DVCS options. Burke, Ben, and Darius are the leaders of this initiative. After evaluating options we will move forward with specific plans to migrate.