Difference between revisions of "Git Migration"

From OpenEMR Project Wiki
m (39 revisions: Git_Migration)
 
(29 intermediate revisions by the same user not shown)
Line 9: Line 9:
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/3894279
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/3894279


Plan to put more details on the migration, git settings, and mirroring mechanism here.
Summary of the conversion process and the planned commit work flow discussed here:
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/3943377


==Items still left to do==
==Items still left to do==
*PROBLEM: When compared the cvs and git repositories, all tags/branches were identical, except for the v3_1_0 tag and the rel-310 branch.
*PROBLEM: When compared the cvs and git repositories, all tags/branches were identical, except for the v3_1_0 tag and the rel-310 branch.
:*SOLUTION: Did not include the rel-310 branch in the migration. Will rebuild it after the migration. While rebuilding rel-310 will also add a v3_1_0_FIXED tag with appropriate code. So will require following steps:
:*SOLUTION: Did not include the rel-310 branch in the migration. Will rebuild it after the migration. While rebuilding rel-310 will also add a v3_1_0_FIXED tag with appropriate code. So will require following steps:
::# Create a rel-310 branch off the rel-320 branch in the git repo.
::# Create a rel-310 branch off the v3_0_1 tag in the git repo.
::# Create a diff patch between rel-320 and v3_1_0 in cvs; use the cvs diff which can be used to ignore differences in EOL and not include cvs versioning lines. Apply this patch and commit to rel-310 branch, and then tag this with v3_1_0_FIXED.
::# Create a diff patch between v3_0_1 and v3_1_0 in cvs; use the cvs diff which can be used to ignore differences in EOL and not include cvs versioning lines. Apply this patch in the new rel-310 branch, and then tag this with v3_1_0_FIXED.
::# Create a diff patch between rel-310 and v3_1_0 in cvs; use the cvs diff which can be used to ignore differences in EOL and not include cvs versioning lines. Apply this patch and commit to rel-310 branch.
::# Create a diff patch between v3_1_0 and rel-310 in cvs; use the cvs diff which can be used to ignore differences in EOL and not include cvs versioning lines. Apply this patch and commit to rel-310 branch.


==Official git Mirrors==
==Official git Mirrors==
* github
This content has been moved here to the following wiki page : [[Repository_work_flow_structure|Repository work flow structure]]
:* repository link: git://github.com/openemr/openemr.git
:* web page link: http://github.com/openemr/openemr
:* mirrors from Sourceforge repository every 30 minutes via an external script
*gitorious
:* repository link: git://gitorious.org/openemr/openemr.git
:* web page link: http://gitorious.org/openemr/openemr
:* mirrors from Sourceforge repository every 30 minutes via an external script
*repo.or.cz
:* repository link: git://repo.or.cz/openemr.git
:* web page link: http://repo.or.cz/w/openemr.git
:* Supposed to mirror from the Sourceforge repository every 60 minutes automatically by the repo.or.cz site (sometimes it takes up to 24 hours).


==Proposed Developer Structure==
==Proposed Developer Structure==
===Overview===
Migrated this section to [[Repository_work_flow_structure|Repository work flow structure]] page.
Considering a different developer model/structure in order to avoid breaking the git repository on sourceforge. This is important to avoid because of the downstream mirrors that the main sourceforge repository feeds. Propose the following structure:
* <b>Integrators</b>
** These are developers with physical commit access to the sourceforge repository.
** They have demonstrated common sense and proficiency in git and OpenEMR development.
** They are responsible for committing their own code.
** They are willing to commit the code of the "Privileged" developers (when requested).
* <b>Privileged</b>
** These are developers that have demonstrated common sense and proficiency in OpenEMR development.
** They do not have physical commit access to the sourceforge repository.
** Their code will be directly committed to the sourceforge repository upon request by an "Integrator", no questions asked and within 24 hours.
*** Best way to do this is to submit code via a public git branch. (instructions on how to do this can be found here)
* <b>Near-Privileged</b>
** These are developers that have demonstrated common sense and proficiency in OpenEMR development, however still need to see a little more work before they are considered a "Near-Privileged" developer.
** They do not have physical commit access to the sourceforge repository.
** Their code needs to be reviewed before committing to the sourceforge repository.


===Integrators===
[[Category:Repository]]
:bradymiller
:stephen-smith
:sunsetsystems
:tmccormi
 
===Privileged===
:acmoore
:andres_paglayan
:cfapress
:drbowen
:larrylart
:markleeds
:rachoac
:tekknogenius
:visolve-selvi
:whimmel
:zhhealthcare
 
===Near-Privileged===
:coleedo
:mmfsystems

Latest revision as of 22:59, 20 April 2012

Overview

On 10/30/2010, the official OpenEMR repository was moved from cvs to git on Sourceforge.

Migration Details

The massive sourceforge thread that discussed this migration can be found here: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/1412511

Also some discussion on this thread: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/3894279

Summary of the conversion process and the planned commit work flow discussed here: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/3943377

Items still left to do

  • PROBLEM: When compared the cvs and git repositories, all tags/branches were identical, except for the v3_1_0 tag and the rel-310 branch.
  • SOLUTION: Did not include the rel-310 branch in the migration. Will rebuild it after the migration. While rebuilding rel-310 will also add a v3_1_0_FIXED tag with appropriate code. So will require following steps:
  1. Create a rel-310 branch off the v3_0_1 tag in the git repo.
  2. Create a diff patch between v3_0_1 and v3_1_0 in cvs; use the cvs diff which can be used to ignore differences in EOL and not include cvs versioning lines. Apply this patch in the new rel-310 branch, and then tag this with v3_1_0_FIXED.
  3. Create a diff patch between v3_1_0 and rel-310 in cvs; use the cvs diff which can be used to ignore differences in EOL and not include cvs versioning lines. Apply this patch and commit to rel-310 branch.

Official git Mirrors

This content has been moved here to the following wiki page : Repository work flow structure

Proposed Developer Structure

Migrated this section to Repository work flow structure page.