Thanks Keith for providing a good summary of the problem space and the possible ways that restore could work.
My initial thought was that a restore would be a pure overwrite. However as you point out that might not actually be useful because it could quite easily create a "broken" configuration. The merging cases certainly look complex and possibly equally prone to not giving the admin quite what they would expect. Maybe we need to take a step back and work out exactly what the usage cases are for why you would need to restore a backup of of the repository independently from a normal full system dump/restore. At this time I can't work out when I'd ever want to do a full repository restore. Exactly what type of situations do we expect the system to get into that the admin would need to be concerned with a previous state of the whole repository independently from the current or enhanced profile systems. I can see a usage case for cloning a repository configuration between multiple installations but currently that feels more like a job for the enhanced profiles work than a dump/restore. Particularly if you consider that the admin intent of a set of configuration changes might be at "high level" services but the clone happens between to machines of different types (say x86 to SPARC or between different SPARC platforms) where there are critical platform specific services (this is where your merge comments come into play). -- Darren J Moffat
