Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Tracking Moodle CVS with git.

Obsolete:Tracking Moodle CVS with git: Difference between revisions

From MoodleDocs
(Added: tricks for merging patches upstream)
Line 31: Line 31:
  -m ?
  -m ?


This will run for a '''very''' long time as it checks out every revision of each file (including all branches).  However, if you run the command after a successful initial run it will simply get the new revisions since it was last run.  This creates a new git repository which can then be cloned and worked upon. At the time of writing the size of a new Moodle git repository was approximately 866MB.
This will run for a '''very''' long time as it checks out every revision of each file (including all branches).  However, if you run the command after a successful initial run it will simply get the new revisions since it was last run.  This creates a new git repository which can then be cloned and worked upon.  


TODO: investigate the utility of downloading a CVS repo tarball from SourceForge as demonstrated in [http://www.progsoc.org/~wildfire/git/update-repo.sh this script].
At the time of writing the size of a new Moodle git repository was approximately 866MB ''unpacked'', and 100MB packed. Newer versions of git pack the project during import, so your resulting repository should be a bit over 100MB.
 
==Importing CVS Faster==
 
For initial imports, it is highly recommended that you fetch the CVS repo from SourceForge.net (note! this has switched from being a tarball to the full unpacked repo via rsync) and run the initial cvsimport against your local copy of the repo.
 
:: For the more adventurous: Keith Packard wrote another importer that does a better job at the initial import, called parsecvs. I use parsecvs for the initial import and then git-cvsimport daily for the incremental imports. --[[User:Martin Langhoff|Martin Langhoff]] 15:04, 19 July 2006 (WST)
 
After the initial import, you can run git-cvsimport against the SF.net repo, or update your local copy via rsync as sas demonstrated in [http://www.progsoc.org/~wildfire/git/update-repo.sh this script].


==Creating a Working Copy==
==Creating a Working Copy==

Revision as of 07:04, 19 July 2006

Note: Work in progress. The information in the document has thus far been compiled by an individual who knows nothing of git or tracking Moodle CVS. The information has not been verified by an authoritative source. Do not follow these instructions. But do work to make them better.

Introduction

If you plan on doing complicated or sustained development on Moodle, you will benefit from a local revision control system. Centralized systems like CVS and SVN have limitied capabilities for tracking vendor branches. For the ultimate experience you will want to use a system with distributed capabilities, like SVK or (as covered in this article) git. Note: While it is possible to use git on Win32 via cygwin, the performance will suffer.

Obtaining git

You'll want:

  • Git (and its deps)
  • cvsps (a dependency of git-cvsimport)
  • an additional git porcelain (frontend)
    • Cogito (offers an interface more familiar to CVS/SVN users)
    • stgit (what's this do?)

Git is very heavily still in development at this time and using Git to track the changes to the Git sourcecode is highly recommended. Debian has packages available but they are very outdated compared with the latest stable version of Git. If you are actually using Git as a tool that you depend on you will want to get the latest changes and fixes as soon as they are released.

Importing CVS

To begin we must import the CVS repository into a local git filesystem using git-cvsimport.

#!/bin/bash
CVSROOT=:pserver:anonymous@cvs.sourceforge.net:/cvsroot/moodle
MODULE=moodle
INSTALLDIR=moodle
git-cvsimport -p x -v -k -d $CVSROOT -C $INSTALLDIR $MODULE &> cvsimport.log

(When might one want to use the -m -u and -s flags?)

-u purely cosmetic
-s slashes can cause problems but this doesn't seem to be the case with moodle
-m ?

This will run for a very long time as it checks out every revision of each file (including all branches). However, if you run the command after a successful initial run it will simply get the new revisions since it was last run. This creates a new git repository which can then be cloned and worked upon.

At the time of writing the size of a new Moodle git repository was approximately 866MB unpacked, and 100MB packed. Newer versions of git pack the project during import, so your resulting repository should be a bit over 100MB.

Importing CVS Faster

For initial imports, it is highly recommended that you fetch the CVS repo from SourceForge.net (note! this has switched from being a tarball to the full unpacked repo via rsync) and run the initial cvsimport against your local copy of the repo.

For the more adventurous: Keith Packard wrote another importer that does a better job at the initial import, called parsecvs. I use parsecvs for the initial import and then git-cvsimport daily for the incremental imports. --Martin Langhoff 15:04, 19 July 2006 (WST)

After the initial import, you can run git-cvsimport against the SF.net repo, or update your local copy via rsync as sas demonstrated in this script.

Creating a Working Copy

In order to use your repository you must clone yourself a working copy using git-clone-pack.

(Let's assume your destination directory above was /pub/scm/moodle)

mkdir ~/git/moodle
cd ~/git/moodle
git clone-pack /pub/scm/moodle.git

This will clone the git filesystem you created from the CVS import into a working copy that you may make changes to and commit to. You can then get updates from the main git repository that will be merged in amongst the changes to your local copy.

If you are using the Cogito tools, you can use cg-clone to do this instead:

cg-clone /pub/scm/moodle.git ~/git/moodle

Merging a patch from GIT into CVS

If you have cvs access, you can use the git-cvsexportcommit command to merge or cherry pick individual patches into upstream.

git-cvsexportcommit was initially written to do merges of NZOSVLE bugfixes into Moodle --Martin Langhoff 14:55, 19 July 2006 (WST)

If the patches merge cleanly, future updates will recognise the already-applied patch. In that sense the merger in git is smarter than the merger in Cogito, consider using git-pull rather than cg-update. Note that if you see conflicts using git-pull you will have to work a bit harder to resolve them. Make sure you are familiar with handling merge conflicts with pure git before trying this.

Preparing to merge large patch series or porting over to the next Moodle release

When you have a large set of patches to apply to CVS, or a large set of custom patches to apply on top of the next release of Moodle, you can use git-format-patch to see what are your unmerged patches. git-format-patch tries hard to spot already-merged patches and skip them.

If you are applying patches to CVS, you can then use git-cvsexportcommit or plain old patch -p1 filename. If you are applying them to a new git branch (as you would to merge them on top of a new Moodle release) then you want to be on that new branch, and use git-am -3 -k filename.

Helpful Documentation

Moodle Forum Discussions