MarmotBlog

Tim pointed out to me today that the last merge from the 1.2 branch to the trunk did not include John’s cool Marmot theme. John added and committed the theme on the branch, not the trunk, so I assumed it would be merged.

Whether this is a failing CVS or that I’m using and old version (thanks Apple) remains to be seen. In any event it appears that while files added to the branch can be merged, there is no method by which directories added to the branch are merged.

After some trial and error (I love sandboxes), I found that I could checkout the trunk and then checkout the specific directory in question from the branch into the trunk sandbox.

The next step was to update just that directory the current trunk HEAD (update -A), which removes the branch sticky tag. It also removed all the files from the directory, but left the directory in place.

From there, I was able to perform a normal merge from the branch to the trunk for just that directory which correctly merged the files. I committed that and all is well.

I updated (make sure to update -d) my trunk sandbox and it got the new theme.

There has to be a better way.

Marmot 1.2.1 has now been tagged and all bug fixes and enhancements to the release have been merged back to the trunk. The development cycle for 1.3 can start now. Any additional bug fixes, etc. to the 1.2 branch will be merged back as necessary.

Make sure to checkout or update to the trunk in your sandbox before undertaking any new development.

This happened with UBB and has come up again as I start working on a email class. It is obviously just short of suicidal to try and recreate every wheel, so we start with existing classes. But how do we include those in Marmot?

I don’t think that cluttering the libraries/mu directory with other include files is a good idea. I’ve now created a libraries/vendor directory at the same location and added it to my include path. My thought is we can include versions of any include files that we might use in Marmot here, but any installation site can decide to use this directory or they can install different versions of the required files in other locations.

I’m not going to commit any of the vendor or Marmot email files yet. I want to wait and see how this works. I’m also waiting for us to merge all the 1.2 branch bug fixes to the trunk, since these are new features that belong on the trunk in 1.3.

First off, all of the Marmot pages except CVS Monitor should have John’s new Marmot favicon. Safari seems to lose the icon when you switch tabs, so it’s not as cool as it could be. And it looks like IE doesn’t like it either. Oh, well.

Also, CVS Monitor has been updated to the final release of 0.6.3 (was 0.6.3b3). They say 0.7 will have :ext support and possibly Subversion and arch support as well.

My new update to the documentation should finally work right in Safari, Mozilla, and IE. Those changes will get moved over sometime later today if they work.

CVSMonitor hadn’t been updating since John added templates/mu/marmot/ because that directory wasn’t owned by the cvsphp group in the repository. I have added a cron job at :59 to make sure group permissions are right so the :00 CVSMonitor updates should go without a hitch.

Finally, I have three RSS feeds for Bugzilla. I hope to someday replace them with one fancy script and maybe even better integration with Bugzilla’s query tools and saved queries. Until then, we have feeds for:
30 recently updated bugs
30 recently closed bugs
all open bugs

I think that’s all for now. All these little changes made for a big post.

The Marmot 1.2 branch has been created in the CVS repository. John and I finished some last minute tweaks today in Tim’s absence, but we believe we would have had his support for the changes eventually.

Time to update to the branch on our development machines and see what bugs make themselves known.

cvs update -r marmot_1-2_branch

I just noticed that the database class documentation is well underway, but the chapter on datasources and databases is really lacking. We need to spend some time on this before we can finalize 1.1. We’re billing this as reference release, after all.