On Sat, 20 Oct 2001, Manuel Teira wrote: > OK. Mine is 'mteira'. So we need to tag a new branch from the trunk: > > cvs rtag -b mach64-0-0-2-branch > > Checkout it again: > > cvs co -b mach64-0-0-2-branch > > Apply our patch over this checkouted branch. > > patch -p0 < here-the-patch-name > > And finally, update the branch with this code: > > cvs update -r mach64-0-0-2-branch
The update command fetches changes from the repository so that you can merge in changes from other developers before checking in your working tree. In this case the -r option sets the sticky tag with the branch tag (this can be verified with 'cvs status [filename]'). That means that subsequent commands will operate on the branch specified. To commit the patch to the branch, you need to check it in: cvs commit -m 'Log message goes here' I'm pretty sure (can someone verify this?) that after the first update with the branch tag specified, you can omit it thereafter since the sticky tag will apply. So from this point you just: 1. Make changes in your working tree 2. When you're ready to commit, first run "cvs update", test any merged changes from other developers and then "cvs commit -m 'log message'" (if you omit the log message cvs will open the editor specified in the EDITOR environment var). If you forget to update first, commit will notify you if there is a new revision in the repository, but it's up to you to then run update and merge the changes. Then periodically, we'll need to merge changes from the trunk into our branch (which is described in the cvs policies doc). > Perhaps the first task, as I said before, will be taking out the MACH64_WRITE > accesses made from the Mesa library. For that, I suppose that we have to > setup some DMA buffers from the DRI driver (there is already a DRI framework > to deal with this issues, I think). I'm studing the R128 DRI driver and > Mesa part to see how to made this. > > Anyway, I'm not ready yet to make this work. If any other person feel more > qualified or with the needed knowledge to make it, please, go for it. Maybe Frank can help with this. Do you think we should keep the notion of pseudo DMA and the different levels of driver support from Utah -- that is: use the DMA macros and have two flush functions: one real DMA and one that does batched register writes? -- Leif Delgass _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
