Mule : CVS
This page last changed on May 31, 2006 by tcarlson.
A good way to keep up with the latest changes to Mule is to download the code from CVS, and subscribe to SCM mailing list (shown below). Here are some instructions for getting the code via CVS: Anonymous (read-only) CVS access:cvs -d :pserver:anonymous@cvs.mule.codehaus.org:/scm/mule login (no password) cvs -d :pserver:anonymous@cvs.mule.codehaus.org:/scm/mule co mule
Developer CVS access:export CVS_RSH=ssh cvs -d <USERNAME>@cvs.mule.codehaus.org:/scm/mule co mule
Browsing CVSYou can view the CVS repository online by going to http://cvs.mule.codehaus.org CVS via FisheyeFisheye provides links to download CVS HEAD in various archive formats:
Secure CVS for Windows UsersTo do development on windows you need to use a native CVS binary with plink for the SSH access and pageant to manage your keys and passphrase - you will also need to use puttygen to generate your keys.
Don't Use Cygwin's CVSDo not use the cygwin build of CVS. If you have cygwin installed make sure your new directory is in the classpath before cygwin's bin directory. The cygwin build of CVS does not work with Pageant. Named SessionsIf you create named sessions with Putty, you can then use these names with CVS. For instance, you can make a Putty session called "mule", set it to SSH and give it your preferred login. You can then access it with: cvs -d @mule:/home/projects/mule/scm co mule
Working on the Release Candidate BranchOnce we decide on a feature freeze in preperation for release candidates and the release, we branch the CVS repository. The release is always built from latest release-branch. Only high priority bug fixes should be committed to the release-branch. Whenever committing to the release-branch, you must at the same time merge those commits into the head. What follows are the procedures for common development use-cases. In these use cases, it is assumed that the latest release branch tag is named 'branch-2_0', and its corresponding merge-point tag is named 'mergepoint-2_0'. (More info on branching and merging) Create a release-branch$ cd $home/mule/head $ cvs update -C drools $ maven test-all $ cvs tag -b branch-2_0 $ cvs tag -r mergepoint-2_0
Checkout the branch$ cd $home/mule/branch-2_0 $ cvs checkout -r branch-2_0 drools $ cd $home/mule/branch-2_0/drools
Fix a bug in the release-branchFix the bug $ cd $home/mule/branch-2_0/mule $ cvs update # fix the bug
Commit to the branch, ensuring you have the lastest from the branch and that all tests pass $ cvs update $ maven test-all $ cvs commit
Prepare a clean check of head $ cd $home/mule/head/mule $ cvs update -C $ maven test-all
Merge from the branch io the trunk $ cd $home/mule/head/mule $ cvs update -j mergepoint-2_0 -j branch-2_0 # fix any conflicts $ maven test-all
Finally, move forward the mergepoint tag in the branch $ cd $home/mule/head/branch-2_0 $ cvs tag -c -F mergepoint-2_0
The reason for the mergepoint is to tell cvs not to consider for merging files that have already been merged previously. (This is where subversion shines. But the above is not difficult with CVS.) If you don't 'move forward' the mergepoint, and there were conflicts resolved during the last merge, you will have to resolve them again. Release a release-candidate or a full release$ cd $home/mule/branch-2_0/mule $ cvs update -C # invoke appropriate maven commands
The main point here is to be sure that you create the release from the release-branch. Additional CVS InfoYou can learn more about CVS at http://cvsbook.red-bean.com. |
![]() |
Document generated by Confluence on Oct 03, 2006 09:23 |