After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 116948 - subtree files patch for markup backend
subtree files patch for markup backend
Status: RESOLVED FIXED
Product: GConf
Classification: Deprecated
Component: Markup backend
CVS HEAD
Other Linux
: High normal
: GNOME2.6
Assigned To: GConf Maintainers
GConf Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-07-08 08:17 UTC by Mark McLoughlin
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (47.63 KB, patch)
2003-07-08 08:19 UTC, Mark McLoughlin
none Details | Review

Description Mark McLoughlin 2003-07-08 08:17:49 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 :/
Comment 1 Mark McLoughlin 2003-07-08 08:19:09 UTC
Created attachment 18125 [details] [review]
patch
Comment 2 Havoc Pennington 2003-10-23 18:22:14 UTC
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.
Comment 3 Mark McLoughlin 2003-10-24 11:20:47 UTC
I can't guarantee I have the time, but I'll see what I can do this
weekend ..
Comment 4 Mark McLoughlin 2003-10-27 18:13:20 UTC
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 ...