On Jul 1, 2013, at 5:08 PM, Isaac Kamga wrote: > Hello mentors and developers, > > I am editing header files to accommodate the heart primitive.In order to > group changes together into complete patch submissions,I would like you to > view the files I grouped together and would appreciate your corrections. > > 1 . For magic numbers, include/magic.h and src/libbu/magic.c > 2 . For version 5 of database , include/db5.h and src/librt/db5_types.c > 3 . For raytracing , src/librt/primitives/table.c , > src/librt/primitives/mirror.c and src/libged/mirror.c > 4 . For ray trace geometry header, include/rtgeom.h
Note that you can (and should) be using svn to group sets of changes to files into a single patch file (not tar or zip or some other grouping method). For example: svn diff include/magic.h src/libbu > magic.patch It's hard to say whether the changes you made to those files should be grouped that way without seeing the patch, but I see at least one problem. Adding a new primitive requires incrementing ID_MAX_SOLID, which you don't list, ... but you cannot increment that without creating a new entry in table.c so those two changes should definitely be grouped together in a patch (probably along with your new primitive ID as well). I suspect 2+3+4 go together but without the mirror work, so you end up with three patches. One adding magic numbers, one stubbing in an empty primitive, another adding in mirror support. You should be able to succinctly describe them like that however you organize and group the changes, NOT based on files changed. Most importantly ... You will need test your patch file since it needs to apply independently, cleanly, and without any unintended side effects. Basically, if you test your patch before you submit it, you should be able to tell whether it applied or can be applied cleanly. To do that: -2) Get a trunk svn checkout (svn co https://svn.code.....) -1) Make a set of changes that logically go together 0) Create your patch file (svn diff .... > my.patch) 1) Get a fresh svn checkout (to a tmp directory) 2) Make sure the patch applies cleanly (e.g., "patch -p0 -i my.patch"). So many fail this step... 3) Make sure it compiles! 4) Make sure it runs. Run "TIMEFRAME=1 benchmark", run "mged". Exercise the code you changed. 5) If it's all good, submit that patch (and let us know that you tested it). This applies to everyone, check your patches. ;-) Cheers! Sean ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
