Requirements and pre-analysis for a cross desktop configuration infrastructure

[Philip Van Hoof]

On Mon, 2005-03-21 at 11:06 -0500, Avery Pennarun wrote:
> On Mon, Mar 21, 2005 at 04:31:11PM +0100, Philip Van Hoof wrote:
> 
> > The backup-format shouldn't only be XML. XML isn't a  very  good  format
> > for  source-control.  An  example  backup-format  that  is  suitable for
> > source-control are ini-files or  ini-file  style  backups. Since  binary
> > data isn't going to be supported, it's doable to use that.
> 
> Again, ini-style files aren't the best choice if you really want this. 


Yes well, an example backup-format could also be something totally
different and very suitable for source control systems. I don't think
one-line per record formats are always a good idea. Simply because a lot
configuration values will have newlines. 

Even the comma separated value format isn't truly one-line per record,
since it's legal to put newlines in quotes.

Thats and because it's possible the configuration options should be
localisable (UTF-16) is why XML is a suitable solution for the default
backend.

Perhaps using a source-code like format is best suited for source
control management.

section {
	section-value = "value";

	section-key = "value";
	section-key = "value";

	subsection
	{
		section-value = "value";

		section-key = "value";
		section-key = "value";

		subsubsection {
			section-value = "value";
		}

	}

}

But then without the indentations. Generated indentations are indeed
less suitable for source control systems and diff algorithms.

Also note that any source control system should (and does) use unified
diff (-like) formats for exchanging differences. It keeps (at least)
three unmodified lines above and below each block of changes along with
the exact line-numbers or the originals. That way merges are possible
between different versions (but we all knew that). So ini-files would
only be unusable for very specific situations.

For example when a specific block is very near another block and both
blocks are the same. Only one of both blocks is changed and there three
new lines in the result already. Otherwise even the most difficult
looking merges would perfectly succeed. Because you keep both the line
numbers of the originals and the three extra lines above and below each
block of changes. Our diff algorithms work pretty good and are proven in
the field.




-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org