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

Just as a reminder, the cvs that comes with Xcode Tools is an old version (1.10, 1998) that doesn’t support useful features like update -C. DarwinPorts has 1.11.13, and Fink has 1.11.5-1.

I’m still intrigued by arch, maybe I’ll give it a try sometime…

Bug 105 started with two similar problems John and Tim had with <goofytext> making its way into their applications, in and out of a database, and back out to the presentation layer, either causing an XML parsing error or a very mangled output stream.

The root of the problem was Marmot’s questionably-intelligent encoding practices. In 1.0.x, Marmot’s add_element would try to encode < and > signs in content, unless it resembled a tag. This was to allow the developer to insert Marmot tags directly in a content string. The two big uses of this were <break /> and <link> tags inserted into paragraphs or other block-level elements. (Also any of the style tags like <bold>.) The problem with this is that it wasn’t any more intelligent than this, so bits of the string’s contents that were not valid tags but somewhat resembled tags, like <user@host.org> or <www.host.com> were not being encoded, causing these non-tags to end up in the XML stream at build time.

This problem was further compounded by 1.1’s new mu_insert_element() function, which would return a stringified representation of a tag. We decided on this as a way to allow developers to insert elements into another element’s content without typing the tags themselves. Today we realized that this only pushed the problem around and didn’t solve anything. The content of one element still contained a stringified representation of another element, which made our encoding decisions even more difficult.

At the same time mu_insert_element() was created, MU_Presentation::make_element() was added to return an unattached element object, exactly like mu_insert_element() returned a string. add_element() was already modified to accept either a string or one of these objects, so it was only logical that we further extend add_element() to accept a string, an object, or an array made of strings and objects. This finally solved our embedded-element issue that plagued us since the beginning. Now, developers do not write tags for Marmot elements by hand, nor do they even have access to string representations of those elements.

The remaining issue is handling cases where this is already being done the wrong way. We are moving forward to document the UBB features to allow developers and users the ability to represent test styles, links, and other basic formatting within strings, for user editing or storage in a database.

Changes for Bug 105 include:
Expanding add_element()’s functionality
Deprecating text2xml(), mu_insert_element(), and the use of tags in a content string

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.

First off, the Blog, Bugzilla, and official Documentation are now all on naslnx05. naslnx07 will redirect for a while, but I’ll probably clean that junk off in the next week or two.

Secondly, we’re going to try to have a much bigger focus on Bugzilla. Previously, it was just a way for Dirk to have a checklist. Now, we are going to try to use Bugzilla as the single collection point for all change tracking. This also changes the way we deal with CVS.

• Any changes you make in CVS should be associated with a Bugzilla entry.
• CVS changelogs should still be used, but do not have to be overly lengthy. They should at least contain a Bug ID.
• CVS commits should all be associated with a small number of bugs (preferably 1) and a small number of files. This is to prevent “Tim Syndrome”, where a developer makes tons of unrelated changes over a 2-week period before remembering to commit. This will also make it much easier to track changes.

Anything we feel we need to discuss before the roll-out of 1.2

Changes made since the merge

Since we seem to be talking about more and more new features we want, it would probably be a good idea to collect them. Post away!

…describes everything we do in CVS, it seems. Dirk had tons of fun today learning the right way to merge branches back to the trunk.

With any luck, everything will be in good shape today and we’ll be back on track for the plan I mentioned previously.

Starting today, Marmot will move to the “basically unstable” strategy of branching. All development will be done on the trunk, and releases will be branched off when appropriate. This should make it much easier to manage releases, bug fixes, and development simultaneously.

The major advantages here are:

• Deployment is done from a tested branch. Changes on this branch will be only bugfixes.
• Development is back to a single stream, on the trunk. Release bugfixes will be merged back to the trunk.
• Switching between branches is only done for upgrades on deployment servers. Such upgrades are only as common as releases and are well-planned.

The current schedule is somewhat close to:

• Today - commit any remaining changes in Marmot development sandboxes, merge dev_1-1_branch back to the trunk, update Marmot development sandboxes with -A to switch them back to the trunk
• March 1 - branch off 1.1 to a release branch, deploy to application development servers, begin testing and QA
• March 15? - 1.1 Release (probably up to 1.1.1 by this point). Update application deployment servers to the new 1.1 release branch.