I was recently motivated by a forum post by Davide Cervone (http://webwork.maa.org/moodle/mod/forum/discuss.php?d=1619) to try to customize how our university's webwork server lists the available courses, sorting by semester. I believe that I've found how to do this, but it involves making some changes to a number of existing webwork source files as well as adding my own perl file that generates the page (a modified copy of WeBWorK::ContentGenerator::Home).
I am just trying to learn what I need to do to deal with future upgrades. I can easily keep track of the changes that need to occur to go from the standard installation. But this seems to be a suboptimal approach.
Those of you with more experience in WeBWorK development, what is the best way for me to keep track of the modifications required to implement my customization?
Thanks,
- Brian
D. Brian Walton
James Madison University
Hi Brian,
The two approaches that come to mind are:
(1) make copies of the files you changed (Home.pm, URLPath.pm, others?) under new names that are not under version control. Configure WeBWorK to use your custom renamed versions, and then just remember to look for updates to the standard versions when you update the code and incorporate those changes into your versions.
Approach (1) is essentially what you do for the config files already when you copy global.conf.dist to global.conf, database.conf.dist to database.conf, etc.
(2) don't make new copies of the files you changed, leave the names the same, and leave them under version control. Then, when you run svn update to update the code, svn will complain to you about those files you've changed if it sees that there are conflicts between the distributed version and your version. Then you can resolve those conflicts as explained here:
http://svnbook.red-bean.com/en/1.5/svn.tour.cycle.html#svn.tour.cycle.resolve
I would probably opt for (2) because I would expect myself to eventually forget exactly what I changed, and svn will never forget. Never.
I don't know of any option where you can "set it and forget it." It would be nice to have such an option; for example, bugzilla does a nice job of handling this problem.
Hope this helps,
Jason
The two approaches that come to mind are:
(1) make copies of the files you changed (Home.pm, URLPath.pm, others?) under new names that are not under version control. Configure WeBWorK to use your custom renamed versions, and then just remember to look for updates to the standard versions when you update the code and incorporate those changes into your versions.
Approach (1) is essentially what you do for the config files already when you copy global.conf.dist to global.conf, database.conf.dist to database.conf, etc.
(2) don't make new copies of the files you changed, leave the names the same, and leave them under version control. Then, when you run svn update to update the code, svn will complain to you about those files you've changed if it sees that there are conflicts between the distributed version and your version. Then you can resolve those conflicts as explained here:
http://svnbook.red-bean.com/en/1.5/svn.tour.cycle.html#svn.tour.cycle.resolve
I would probably opt for (2) because I would expect myself to eventually forget exactly what I changed, and svn will never forget. Never.
I don't know of any option where you can "set it and forget it." It would be nice to have such an option; for example, bugzilla does a nice job of handling this problem.
Hope this helps,
Jason