GNOME Bugzilla – Bug 116948
subtree files patch for markup backend
Last modified: 2004-12-22 21:47:04 UTC
See: http://mail.gnome.org/archives/gconf-list/2003-July/msg00001.html Putting the patch here so it doesn't get lost. Havoc, this latest patch includes several fixes to make the test suite run fine against it. I could seperate the "single file" stuff out of the patch so you just have a bugfix patch, but it would be a fair bit of work :/
Created attachment 18125 [details] [review] patch
Mark - what I was trying to do was: - get the markup backend working/tested/debugged - then merge this patch So on my machine at home (not with me right now) I'd rediscovered and fixed several of the bugfixes from this patch, and have the default switched over to the markup backend. However, the backend is still broken; it sometimes writes out files it can't read again, it loses settings from the XML backend, etc. I may be missing some of your bug fixes. If you're willing to exhaustively test the whole patch at once, and fix the issues that get filed over the next couple months, you could go ahead and just apply this patch. That may be faster than waiting for me to test it myself. We need to make sure that a full set of existing user settings, including epiphany, evolution 1.4, etc. do not get lost with the new backend though. And that after using a session with the markup backend for a while, if you cut back to the XML backend you still don't lose settings. Need to test _very_ thoroughly... Anyway, if you have time to really bang on it I don't want to be the bottleneck, let's get it in. But please don't commit it unless you've really tested it with full GNOME sessions going back and forth between backends.
I can't guarantee I have the time, but I'll see what I can do this weekend ..
Okay, I've gone ahead and committed this. What I did was: + Reviewed the patch thoroughly again + Tested gconftool dumping the entire tree using both backends and comparing the result with diff. Made some changes to gconftool to sort entries and dirs before outputing. They seem to be outputting the exact same tree. + Loaded the output using the markup backend and again dumped with each backend and compared the result. + Logged in using the markup backend, created a pretty complicated panel with loads of stuff on it, logged out and logged back in with the XML backend. All is well. Deleted the panel, logged back in with the markup backend. All is well. + Blew away everything in /apps/panel and /schemas/apps/panel from gconf.xml.defaults and re-installed using the markup backend. Seems to work fine logging in as a new user with both backends. There are only two unresolved issues I have seen: + If a string value in the XML format is " " then the markup backend will output this as "". This seems to be a side effect of gmarkup's parsing. I can't see a way to fix this and I've made gconftool-2 always dump a " " value as "" so I could compare dumps. I don't think this is a huge issue, though. + If a short description contains a newline, libxml saves the attribute with the newline encoded as ... but gmarkup will save the newline. So if a short description containing a newline is saved with the markup backend and then later parsed by the XML backend, the XML backend discards the newline. I don't think this is a huge issue either, but I'll log a bug to track it. Maybe we could encode the newlines ourselves, but if its the right thing to do then gmarkup should do it. So, at this point I'm pretty confident we've got most of the issues with the backend sorted out. But I probably wouldn't have gone ahead and committed yet if it wasn't for the fact that the backend still won't be enabled by default. So we can get the patch in and at least you and I can test the same code. Also, note that the single-file stuff has no real impact here. The only way a %gconf-tree.xml file ever gets created at the moment is using gconf-merge-tree ...