Configuring ZSyncer

    - Destinations: Valid ZSyncers to sync to, identified by URL, 
      including port. For
      example: http://www.myzopesite.com:8080/my_ZSyncer. These can be
      https urls if you want.  If your destination is a ZEO cluster,
      you must only specify the URL for a single zope server in the
      cluster, or just give the virtual address presented by your load
      balancer if you have one.

      ZSyncer supports the following URL syntax extension for HTTP Basic 
      Authentication:

         proto://user:pass@host:port/path

      This allows you to use a different username / password for each
      destination server. It replaces the old "Override User" config
      option, which wasn't flexible enough for some users.

      (SECURITY WARNING: it also exposes the passwords in plaintext on the
      ZSyncer properties page. If you use this feature, be sure that
      only trusted administrators have the "View Management Screens"
      permission in context of your ZSyncer instance.)

    - Connection Type: the underlying transport classes to use.
      You should probably leave this alone unless you know what you're
      doing. 
      ConnectionMgr works with SSL and supports timeouts.  The
      previous solution, ZPublisher.Client, does neither.  Therefore,
      ConnectionMgr is now preferred. But if you have any problems
      with it, you might try ZPublisher.Client.

      (Prior to version 0.6, ZSyncer used XML-RPC. It was inefficient, had
      character encoding problems, and the code is now broken; so
      we have removed it.)

    - Use Relative Paths: Force ZSyncer to treat object paths as
      relative to "Base Path", not relative to the zope root.
      (If "Base Path" is not set, it defaults to the parent 
      container of the ZSyncer instance.)

      This means that the source and destination zsyncers can live in
      different parts of the object hierarchy, and objects will be pushed
      where you expect them relative to the destination zsyncer.
      It also prevents you from syncing anything above the
      "Base Path".
 
      Note that this flag MUST currently be set the same way on both
      the source and destination servers. If the settings do not
      match, you may have problems. This requirement may be removed in
      a future release.

    - Base Path:  Where to look for objects if
      use_relative_paths is true. See above.

    - Log?: Turns on logging.

    - Logfile: specify the file to log to.  Should be a path relative
      to your INSTANCE_HOME.

    - Approval?: Require confirmation before performing actions.

    - Syncable types: what meta types you want to sync. See below for
      info.

    - Additional syncable types: if you want some meta_types to be syncable
      and they do not show in the "Syncable types" list, you can type
      them here, one per line.

    - Non-syncable meta types: types to explicitly remove from the
      list of syncable types. These are applied last and will override
      any previously added types.

How to sync

    The sync web page shows the difference between a development Zope
    and one or more other Zopes. It does this by comparing the date
    stamps on the objects in Zope.

    - File: shows the object name in Zope. If this object is a folder,
      you can click on it to traverse to the lower folder.

    - Status: shows the status of the object in relation between the
      Zopes it will be one of the following terms:

        <img src="misc_/ZSyncer/ok.gif"> *ok* -- this object is present on both production and
          development and is in sync
            
        <img src="misc_/ZSyncer/missing.gif"> *missing* -- this object is present development but not
          production, it needs syncing
        
        <img src="misc_/ZSyncer/extra.gif"> *extra* -- object is on production but not
          development, it needs deleting from production
            
        <img src="misc_/ZSyncer/outdated.gif"> *out of date* -- this object is present on both the
          production and development, but has been changed on
          development, it needs syncing.
    
    - View: takes you to a version on the appropriate server 
    
    - Action: perform the highlighted action.
        
        *put* -- copies the relevant object(s) from the local server
          to all the remote servers.
        
        *get* -- copies the relevant object(s) from the first available
	remote server to the local server.
        
        *delete* -- removes the relevant object(s) from all the
         servers on which it is present. (This affects the local
         server and all the remote servers.)

        *touch* -- change the modified timestamp on both local and
         remote object to *now*.


Syncable types:

    - This should be considered experimental, but it **sort of**
      limits the objects that can be synced. You specify the meta
      types and only objects of that type are shown.


    - **However** if your list of syncable objects is not the same
        on all systems, this could generate false results. For example,
        the source has 'Foo' in its syncable types, but the destination
        doesn't. If that's the case, an object of type 'Foo' that is
        on both systems will be shown as 'missing' on the destination,
        because it is filtered from the destination object list.
        Similarly, if 'Foo' is syncable on the destination but not on
        the source system, an object of type 'Foo' that is on both
        systems will be shown as 'extra' on the destination because
        it is filtered from the source object list.

    - **Also** if you sync a folderish object, all the objects in it
        are moved, not just the syncable types. This is because of the
        way Zope generates export files.

    - Let me know if this makes it a mess.

Notes

    If you sync a folder, it will sync *all* the items in that folder.

    ZODB Versions are respected; if you have made changes in a version
    they will not be synced until committed. (But of course ZODB
    Versions are evil and you should use them with care.)

    If you change an object in a folder, that folder does not become
    out of date. However, if you add or delete objects, the immediate
    parent folder becomes out of date. This is due to the way Folders
    are implemented in the ZODB.