**Contents** [[!toc ]] **OUT OF DATE: CURRENTLY GIT IS USED: [[http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=summary|http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=summary]] - mesa includes the DRI drivers [[http://gitweb.freedesktop.org/?p=mesa/drm.git;a=summary|http://gitweb.freedesktop.org/?p=mesa/drm.git;a=summary]] - own repository for DRM (Direct Rendering Manager) kernel drivers ** ## Overview The DRI project has several development policies which all developers are required to observe: 1. All code development is to be done on CVS branches, not the trunk. 1. Branches are not merged into the trunk until the code as been well tested. 1. CVS tags follow a consistant naming convention. 1. Merges to the trunk must be timed so that they do not upset scheduled releases. Potential developers must accept these policies before joining the project. Anyone who does not follow these policies and causes problems will lose their CVS write privileges immediately, and probably forever. ## Introduction The DRI CVS tree is a subset of the XFree86 development tree. The DRI tree omits documentation and font directories which are outside the scope of the DRI project. When XFree86 releases a new public snapshot we will update the DRI tree to match the snapshot. Prior to XFree86 releases we generate a patch file in order to submit our latest DRI code back to XFree86. Since the DRI developers each have specific development projects, it's imperative that the check-ins which one developer commits does not interfere with the work of the others. Also, it's very important that the main DRI trunk be a stable code base so that users can download and use it successfully at any time. For these reasons, all code development is to be done on branches. The rest of this document explains in detail how branches are to be managed. We do make exceptions to this rule, however, when making one or two-line bug fixes. It seems overkill to make a branch in order to commit a trivial bug fix. Finally, the DRI project is tied to the schedules and deadlines of the XFree86 project and corporate contracts. For that reason, merges into the trunk must be timed so that schedules aren't upset. We will try to keep the DRI developers informed of these schedules. ## Branch tag naming scheme Branches are symbolic tags that are used to anchor a branch as a specific tree revision. We'll use the following format for branch tags: * `--branch` where: * ` ::= { tdfx, ati, i740, dri, smt, glxmisc, ... }` * ` ::= --` (e.g., `0-0-1`) Note that hyphens (`-`) are used, not underscores. Periods (`.`) are never used because they upset CVS's branch naming. ## Non-branch tag naming scheme We use non-branch tags for three things: 1. syncing with XFree86, Mesa, etc. 1. merging branches 1. miscellaneous tags (e.g., to remember a specific stopping point) ### Format for syncing -- ::= { xfree, mesa, ... } ::= project-specific revision (e.g., 3-9-16e) ::= (e.g., 19991206) ### Format for merges On the branch, **before the merge**, use the following tag: -- On the main trunk, **after the merge**, use the following tag: ---merge ### Format for miscellaneous tags --- ## How to check out the main trunk export CVS_RSH=ssh cvs -z3 -dDEVELOPERNAME@cvs.dri.sourceforge.net:/cvsroot/dri co xc ## How to check out a branch cvs co -r --branch xc ## How to make a branch ### You have no checked out trees If you want to use the main trunk as the anchor for your branch: cvs rtag -b --branch cvs co -b --branch If you want to use some other tag as the anchor for your branch: cvs rtag -b -r --branch cvs co -b --branch ### You have a checked out trunk, and you want to tag it and start using it as a branch cd cvs tag -b --branch cvs update -r --branch This makes the `--branch` tag sticky. You can verify this by using `cvs status`, for example in `XFree39/xc`, do this: cvs status Makefile or cvs status -v Makefile ## How to merge the trunk into your branch Before you merge your code into the trunk you should first merge the latest trunk code into your branch. After merged code has been tested on your branch, merging into the trunk should be simple. 1. Be sure all the changes on your branch are checked in. 1. Tag your branch with a 'freeze' tag: * `cvs tag ---freeze` 1. Merge from the trunk: * `cvs update -d -j HEAD` 1. Resolve any conflicts from the merge. 1. Recompile and build your branch. Test it. 1. Check in your changes from the merge. 1. Tag your branch with a merge tag: * `cvs tag --` ## How to merge your branch to the main trunk 1. Be sure your ---merge tag (on the branch) is up to date (i.e., in case you changed some files from between the time you merged the trunk onto the branch until you merged the branch onto the trunk). You can make the tag with: * `cvs tag --` 1. Revert your working tree to the main trunk: * `cvs update -A` (Alternatively, you can just check out a new copy of the main trunk.) 1. Merge in the changes from your branch: * `cvs update -j --branch` 1. Test your merged tree 1. Check in your merged tree to the main branch; * `cvs commit -m 'Merged -'` 1. Tag your merge so we can find it again: * `cvs tag ---merge` 1. Now you can make diffs to send to XFree86 Say you keep hacking on your branch after the merge to test a few extra things and you want to merge again. You get the main trunk checked out, as in step 1, then you merge only those changes between your last merge and the most recent revision in your branch: * `cvs update -j -- -j --branch` ### How to turn off logging of large check-ins to the mailing list * `cvs co CVSROOT` * edit loginfo to comment out the mail notification line * check in loginfo * do your merge * undo the change to loginfo