[Chandler-dev] Backup/Restore preferred feature name over Dump/Reload

[Andi Vajda]

On Mon, 26 Feb 2007, Mike Taylor wrote:

> I've been reading the design list and following along in questions during 
> meetings and would like to suggest that from this point on we use Backup and 
> Restore in place of the various phrases when describing the following:
>
> Allow the user to create a complete backup of their Chandler data in a manner 
> that is cross-platform and schema-version independent.

Disagree:

While having this capability would be very desirable, the name "Backup and 
Restore" is already taken. The existing "Backup and Restore" functionality is 
a complete, non-lossy, cross-plaform backup of the user's repository. It is, 
however, *not* schema- or format- independant and *cannot* be used alone 
during a schema upgrade.

It is my understanding that the planned "Dump and Reload" feature, on the 
other hand, is much more schema- or format- independant and is intended to be 
used for user data migration during schema or format upgrades. Because it is a 
translation from one format to another, "Dump and Reload" is likely to be:

   - lossy: until all data in the repository is translated, it is lossy.

   - slower: "Backup and Restore" essentially makes a copy the repository data
             files and is inherently faster than a format translation.

   - hard to implement: the usual 80-20 rule is very applicable here.

Until "Dump and Reload" can do all of the above (including what Backup and 
Restore does), using the word "Backup and Restore" is misleading.

Now, it has been said before, with reason, that the name "Backup and 
Restore" is also misleading because it doesn't include the schema/format 
portability feature and users are bound to expect that.

It is up to us to present (and name) these features in such a way that they 
don't confuse things and set user expectations correctly. There are several 
solutions to this, of varying difficulty:

   - Conflate the two (what bear is proposing, apparently) and is hardest.

   - Rename "Dump and Restore" to "Migrate User Data" so as to not confuse
     things. It could be renamed to "Migrate Repository" once it's no longer
     lossy. This has the advantage of being easier to implement and improve
     over time. The boundaries of what consititutes "migratable user data" can
     be shifted one stage at a time without lying too much about expectations.

   - Rename "Backup and Restore". I can't think of a good different name,
     something with "Repository Copy" or "Repository Duplicate" comes to mind
     but they don't have the nice to-and-fro of "Backup and Restore".
     Suggestions are welcome.

   - Make it clear in the docs and UI (File->Backup... and File->Restore...)
     that "Backup and Restore" does *not* support schema or format migration.

Andi..