[Zope3-checkins] CVS: Zope3/doc/zsync - README.txt:1.1
zbundle.txt:1.1 zsync.txt:1.1
Fred L. Drake, Jr.
fred at zope.com
Mon Aug 18 18:04:07 EDT 2003
Update of /cvs-repository/Zope3/doc/zsync
In directory cvs.zope.org:/tmp/cvs-serv16340/doc/zsync
Added Files:
README.txt zbundle.txt zsync.txt
Log Message:
The documentation for zsync & friends is really intended for an end-user, so
move it to the doc/ tree.
=== Added File Zope3/doc/zsync/README.txt ===
==========================
Filesystem Synchronization
==========================
For background and the original description by Jim Fulton, see the
|FSSYNC|_. Additional background material can be found in the
|TTWSITE|_ proposal.
.. |FSSYNC| replace:: Filesystem Synchronization Proposal
.. |TTWSITE| replace:: Through the Web Site Development
.. _FSSYNC: http://dev.zope.org/Zope3/FileSystemSynchronizationProposal
.. _TTWSITE: http://dev.zope.org/Zope3/ThroughTheWebSiteDevelopment
The "bundles" mentioned there are likely candidates for filesystem
synchronization. (See section `Working With Bundles`_ below.)
This version is based loosely on a prototype written by Jim Fulton and
Deb Hazarika. It is now maintained by Fred Drake.
User stories
------------
* A user with site development privileges plans to go offline for a
weekend and wants to work on (part of) the site on his laptop during
that time. On Friday, before going offline, he checks out a subtree
of the site to his laptop's disk. This maps folders to directories
and other objects to files. Metadata is stored in a subdirectory
named ``@@Zope/``, some of it as XML. Over the weekend he edits the
files and perhaps the metadata on his laptop. On Monday, once
online again, he commits his work back to the site.
* It is possible that someone else might have made changes to the site
that conflict with the work done offline. The commit operation
should fail in this case without making any changes. Our user
should then invoke an update command that merges the site's changes
into his local work area. If there are any merge conflicts, he
should then resolve these manually. Once conflicts are resolved, he
can commit his changes successfully, assuming there are no
additional changes made to the site in the mean time; otherwise, the
commit will fail again and the cycle starts over.
* Like CVS, after doing a successful commit, you can continue to work
and do another commit later.
* There should be commands to show the differences in the local copy,
and to show the status of each file or directory.
* Merging changes should deal with simultaneous changes in the same
file, at least for text files; what CVS does is pretty reasonable
(this seems to be based on the **diff3** command).
* Update and commit should handle addition and removal of files and
directories. For local additions and removals, an explicit command
must be given to confirm these, to avoid committing files that were
accidentally created or lost.
* Commands that are reasonable to do offline (**add**, **remove**,
**status**, and the simplest form of **diff**) must be performed
entirely offline.
* An interesting possibility: you could couple your filesystem copy to
a revision control system like CVS or Subversion, to have an
auditable revision history of a site. Typically, you'd do a cvs
commit after each sync update and after each sync commit, after
verifying that the state committed to Zope actually works. It would
be handy if files added to or removed from Zope are automatically
added or removed from CVS. The "binary" flag for CVS might be set
automatically based on the Zope object type.
* Another possibility: export and import (a la Zope 2 export/import)
should be easily implemented on top of this. Export would be done
with checkout; import could be a new **checkin** command. (This is
now implemented.)
* And last but not least, this will form the basis of bundles; see
|TTWSITE|_.
Bugs
----
* When committing an added file, you must commit the directory
containing it; you can't commit the file itself, since the command
tries to send the request to a view of the corresponding object,
which doesn't exist yet.
* When doing an update, somehow the absolute pathnames of all files
are reported rather than the nice relative names.
Platform Notes
--------------
* RedHat Linux 9: Anthony Baxter reports that the tests can hang in a
futex() system call. It appears that the glibc version shipped with
RedHat 9 (glibc-2.3.2-11) has some bug that causes this; updating to
at least glibc-2.3.2-27.9 fixes the problem.
To Do
-----
- Implement bundle commands via a new command-line utility to convert
a checkout of a site-management folder to a bundle (in progress).
* Bundles should be read-only.
- Documentation for the **zsync** and **zbundle** command line tools
(in progress)
- Explicit import/export facilities, similar to the functionality
found in Zope 2
* Should produce a single file (.zip or .tgz maybe)
- Improve some common data file formats (for example, the Entries.xml
file, possibly incorporating some or all of the Extra or Annotations
data). An XML data format is probably a better idea than switching
to ZConfig for this file, primarily to make it easier to support
additional data.
The format for the RegistrationManager, on the other hand, may do
well as a ZConfig format, since each entry is very much like a
dictionary. The catch is that the registrations define their own
fields, even though their pretty much all the same, and the current
implmementation relies on them being indivudually serialized.
- Figure out how to write meaningful adapter tests.
- More adapters. Should make sure that an XML pickle will always work
as a serialization, even if an adapter gets added.
- For objects serialized as XML pickles which are
``IAttributeAnnotatable`` and have an ``__annotations__`` key in the
pickled dictionary, separate the annotations from the dict so they
appear in the ``@@Zope/Annotations/`` tree.
XXX Note that ``IAttributeAnnotatable`` doesn't say anything about
*how* the ``__annotations__`` attribute is stored; it can be in the
object's ``__dict__``, it can be a property, or who know what else.
There's probably not enough information about how the manipulate the
object's state in a reliable way to implement this feature
automatically. The only way to always do the right thing is to
define an appropriate adapter.
- Work out security details (before beta).
* A commit unpickles user-provided data. Unpickling is not a safe
operation. Possible solution: have an unpickler that finds
globals in a secure way. Use an import on a security proxy for
sys.modules.
* The adapters returned by the fs registry should optionally have a
permission associated with them. If you have an adapter that
calls ``removeAllProxies()`` or ``trustedRemoveSecurityProxy()``,
the adapter should require a permission.
- In the sync application (nice-to-haves):
* More **diff** options:
-2 diffs between local and remote
-3 diffs between original and remote
* Something akin to **cvs -n update** or **svn status -u**, which
shows what update would do without actually doing it.
* Add support for HTTP proxies.
* Implement **diff** using ``difflib``. (is this really needed?)
- Code maintenance:
* Unit tests for the **zsync** and **zbundle** utilities.
* Add unit tests for ``zope.app.fssync.syncer``.
* Use camelCase for public method names.
- Refine the fssync adapter protocol or implementation to leverage the
file-system representation (== FTP, WebDAV) protocol.
* look in: ``zope.app.interface.file``
- In common case where extra data are simple values, store extra data
in the entries file to simplify representation and updates. Maybe
do something similar w/ annotations.
- Maybe leverage adaptable storage (APE) ideas to assure losslessness.
Working With Bundles
--------------------
- Bundles aren't quite as easy to use as they are supposed to be as
described in the |TTWSITE|_ Wiki page referenced above, but you can
do some basic bundle-ish things. All these need is a little better
packaging.
- Permissions. Everything described here requires the
zope.ManageServices permission, which usually requires being logged
in with the manager role.
- Bundle status. There is not yet an explicit notion of "bundle-ness"
for site management folders. Any site management folder can be
treated as a bundle. Exception: the Bundle view works for the
default folder but the form included in the view refuses to change
it. This is a safety measure: the bundle form can do a lot of
damage, e.g. it can disable all services at once. By convention, I
propose that bundles have a folder name of the form
<name>-<version>, where <version> is two or more decimal numbers
separated by dots and <name> is unconstrained.
- Creating a bundle. There is no specific command to create a bundle.
Instead, you create a new site management folder by going to the
Contents view of the site (e.g. ``/++etc++site/@@contents.html``)
and clicking on **Add** in the actions menu. A box will appear in
which you should type the name and version of your bundle. Then in
that bundle you should create the things that you want to go into
the bundle, e.g. modules, templates, services, utilities, etc.
- Creating a bundle from an existing folder. If you have some
existing work done in the default folder or another non-bundle
folder, you can save your work to the filesystem using the **zsync
checkout** command, and then check it in under a different name using
the **zsync checkin** command. Example; replace u:p with your manager
username and password::
$ zsync checkout http://u:p@localhost:8080/++etc++site/default
<lots of output>
All done.
$ zsync checkin http://u:p@localhost:8080/++etc++site/bundle-1.0 default
Now go back to your web browser and check out the contents of
``/++etc++site/``; a new folder bundle-1.0 should exist, containing
a copy of the default folder. You should delete unnecessary things;
especially the standard service definitions are not needed.
- Exporting a bundle. First deactivate the bundle by using the
**Deactivate bundle** button on the Bundle tab (see below). Then
save the bundle to the filesystem using **zsync checkout**. Finally
tar or zip it up. Make sure to include the ``@@Zope/`` directory at
the same level as the bundle directory in the archive.
::
$ zsync checkout http://u:p@localhost:8080/++etc++site/bundle-1.0
<lots of output>
All done.
$ tar tf - bundle-1.0 @@Zope | gzip >bundle-1.0.tgz
Now distribute the gzipped tar file via the web.
- Importing a bundle. First extract the zip or tar file to the
filesystem. Then use **zsync checkin** command to add it to your
Zope server. Warning: the **checkin** command will happily
overwrite an existing site management folder!
- Activating a bundle. An imported bundle is completely inactive.
Its configuration records (the objects in the bundle's
RegistrationManager subfolder, and in RegistrationManager subfolders
of subfolders of the bundle) are not registered with their
respective services. To activate the bundle, navigate your web
browser to its contents and select the Bundle tab; it is probably
the second tab from the left. The Bundle tab displays two sections
and a few buttons.
- Section one of the Bundle tab shows the services needed by the
bundle. This list is created by inspection of the bundle's
configuration records: for example, if there is a configuration
record for a utility, the service needs the utility service.
For each needed service, there are three possibilities:
1) The service is already active in the site. This is probably
because it exists in the default folder or in a previously
installed bundle.
2) The service is not yet active in the site but the bundle
provides a configuration for the service.
3) No usable definition of the service can be found. Note that a
service active in a parent site cannot be used. This is called
an unfulfilled dependency. This means that the bundle cannot
be activated. A helpful link to the **Add service** view of
the default folder is provided, where you can create (and
activate!) the service and then navigate back to the bundle;
but you may also import the service as part of another bundle.
- Section two of the Bundle tab shows, for each of the service types
shown in section one, all configuration records in the bundle for
that service type. Initially, all configurations are in the
"Unregistered" state. At the bottom of the list you will find a
button which will register all configurations, and activate the
ones that aren't in conflict with pre-existing registrations.
Conflicts are indicated in red and provide a link to the
conflicting active configuration record, probably in another
bundle. The automatic resolution of conflicts in favor of a newer
version of the same bundle, mentioned in the Wiki, is not yet
implemented; by default, whenever there is a conflict the
conflicting configuration record in the bundle is not activated.
You can resolve conflicts yourself in favor of the new bundle by
clicking the radio button labeled "Register and activate". You
can also leave a configuration record inactive by clicking the
radio button "Register only". When you are satisfied with the
selections, click the **Activate bundle** button below the list to
register and activate the bundle's configuration records; this
performs the actions selected by the radio buttons. If you later
change your mind, you can always go back to the Bundle tab and
change your selections.
- At the very bottom of the page is a button labeled **Deactivate
bundle**. This is used for uninstalling a bundle; it makes all
configuration records contained in the bundle inactive and
unregistered. It is also used for exporting a bundle; before you
export a bundle, you should deactivate it (see above). In
contrast to the description in the Wiki, deactivating a bundle
does not reactivate any configuration records that were active
before the bundle was activated, because the configuration
registries don't record this information; it can't distinguish
between previously active and previously registered. A redesign
of the registries would be necessary to accommodate this feature.
- To delete a deactivated bundle, go to the site manager's contents
display (``/++etc++site/@@contents.html``), select the checkbox in
front of the bundle name, and click the **Delete** button below the
list. Deleting an active bundle usually doesn't work because of the
dependencies between the configuration records and the configured
objects in the bundle.
=== Added File Zope3/doc/zsync/zbundle.txt ===
Name
----
**zbundle** - Zope bundle management tool
Synopsis
--------
**zbundle** [*general-options*...] *command* [*command-options*...] [*args*]
Description
-----------
The **zbundle** command is used to manage site management bundles
within a **zsync** checkout.
**create**
Create a bundle and schedule it for addition to Zope via **zsync**.
**help**
Display help text.
There are general options which apply to all **zbundle** commands, and
specific options which apply to individual commands. General options
must be specified between the **zbundle** command name and the specific
command, while options for specific commands must be supplied after
the name of the specific command.
General Options
~~~~~~~~~~~~~~~
The following general options are supported. These must be specified
between the name **zbundle** and the name of the specific command being
run.
-h, --help
Display help text
The **zbundle create** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**create** PATH [SOURCE]
Description
+++++++++++
XXX
Options
+++++++
-f FACTORY, --factory FACTORY
Specify the object factory to use for the object being added.
-t TYPE, --type TYPE
The type of the object to be created. Normally only *FACTORY* needs
to be specified.
The **zsync help** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**help** [*command* ...]
Description
+++++++++++
When used with specifying *command*, this displays general help on
using **zsync**. When *command* is given, information about each
command list is presented.
Security Notes
--------------
- The ``@@Zope/Root`` file contains the username and password with
which the checkout was made. Since this will typically allow access
with content management priviledges, this file should not be shared
carelessly.
Files
-----
**zbundle** does not create any supplemental files beyond what
**zsync** produces. Refer to the **zsync** documentation for details
on those files.
Reporting Bugs
--------------
Bugs in **zbundle** and the filesystem synchronization support in Zope 3
should be reported via the `Zope 3 Development Issue Collector`__, an
online reporting tool that allows you to enter reports directly into
our bug-tracking system.
.. __: http://collector.zope.org/Zope3-dev
See Also
--------
There are two interesting and directly relevant articles in the `Zope 3
wiki`:
* The |FSSYNC|_ is the initial proposal for a way to synchronize
copies of a Zope-based website between a filesystem-based
representation and the database backing the live site.
* Bundles are discussed in |TTWSITE|_; this gives more information on
the motivation and goals surrounding this work.
.. |FSSYNC| replace:: Filesystem Synchronization Proposal
.. |TTWSITE| replace:: Through the Web Site Development
.. _FSSYNC: http://dev.zope.org/Zope3/FileSystemSynchronizationProposal
.. _TTWSITE: http://dev.zope.org/Zope3/ThroughTheWebSiteDevelopment
Copyright
---------
Copyright (c) 2003 `Zope Corporation`__ and Contributors.
All Rights Reserved.
.. __: http://www.zope.com/
This software is subject to the provisions of the `Zope Public
License`_, Version 2.0 (ZPL). A copy of the ZPL should accompany
this distribution. THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL
EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST
INFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE.
.. _Zope Public License: http://www.zope.org/Resources/ZPL
=== Added File Zope3/doc/zsync/zsync.txt ===
Name
----
**zsync** - Zope filesystem synchronization tool
Synopsis
--------
**zsync** [*general-options*...] *command* [*command-options*...] [*args*]
Description
-----------
The **zsync** command is used to synchronize the representation of a
Zope 3 based website stored in the object database with a
directory-tree representation. The **zsync** command "feels like" the
**cvs** and **svn** commands, but is different in that there is no
basic versioning model in **zsync**.
Like the **cvs** and **svn** programs, **zsync** requires a **zsync**
command and any arguments to that to be given on the command line.
The additional specific command given controls what operation is
performed. The following commands are supported; names given in
parentheses are aliases supported for convenience:
**help** (h, ?)
Display help text on **zsync** and individual commands.
**checkin** (ci)
Add the target material to the object database.
**checkout** (co)
Retrieve the serialized representation of a portion of the object
database.
**commit**
Integrate changes in the local representation objects into the
object database. If there are changes to the same objects in the
object database, those changes must be merged into the local
representation before the local changes can be committed.
**update** (up)
Retrieve updates from the object database.
**diff** (di)
Report differences between the local representation and the data
from which the modified copy was generated. This command can be run
*offline* (without any network access), so is useful when working
from a disconnected system.
**add**
Mark an object for addition to the object database. The change is
not made to the object database itself until the next **zsync
commit**.
**mkdir**
Create new directories and schedule them for addition. The
additions are not made to the object database itself until the next
**zsync commit**.
**delete** (del remove rm)
Mark an object for removal from the object database. The change is
not made to the object database itself until the next **zsync
commit**.
**resolve**
Remove a conflict indicator for a file that has been updated on
both the server and the working copy. (This does not actually
modify the file to resolve conflicts; this is used to tell **zsync**
that you're done making changes to resolve the conflict.)
**revert**
Restore targets to their unmodified state.
**status** (stat)
Show the current status of the target material; whether it has been
changed in the local representation, has been removed or added, or
is unchanged.
There are general options which apply to all **zsync** commands, and
specific options which apply to individual commands. General options
must be specified between the **zsync** command name and the specific
command, while options for specific commands must be supplied after
the name of the specific command.
General Options
~~~~~~~~~~~~~~~
The following general options are supported. These must be specified
between the name **zsync** and the name of the specific command being
run.
-h, --help
Display help text
The **zsync add** Command
~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**add** [*add-options*] [*path*]
Options
+++++++
-f FACTORY, --factory FACTORY
Specify the object factory to use for the object being added.
-t TYPE, --type TYPE
The type of the object to be created. Normally only *FACTORY* needs
to be specified.
The **zsync checkin** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**checkin** [*checkin-options*] *target-url* [*path*]
Description
+++++++++++
Check an object representation into the repository. The
representation may have been created by a checkout from a different
object database or from a different location in the target database.
If the metadata in the representation includes path information, that
is ignored in favor of the new name being assigned in the target
repository.
The new name is given as part of *target-url*. The last component of
*target-url* is used as the local *path* if path is not specified.
The representation which is used as the source is not modified; it
does not become an equivalent of a checkout. A separate **zsync
checkout** is needed to create a working copy on the local
filesystem.
Options
+++++++
-F FILE, --file FILE
Set the message used for the transaction note to the contents of the
file *FILE* (similar to the ``-F`` option for **cvs commit**).
-m MSG, --message MSG
Set the message used for the transaction note to *MSG* (similar to
the ``-m`` option for **cvs commit**).
The **zsync checkout** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**checkout** *source-url* [*dir*]
Description
+++++++++++
Retrieve the serialized representation of a portion of the object
database. The database and starting path to be retrieved are
specified as *source-url*. The local representation is stored in the
directory *dir*, which defaults to the current directory.
The **zsync commit** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**commit** [*commit-options*] [*path* ...]
Description
+++++++++++
Integrate changes in the local representation objects into the object
database. If there are changes to the same objects in the object
database, those changes must be merged into the local representation
before the local changes can be committed.
If *path* is given, only the named content objects are committed into
the repository. If not given, the current directory and all
descendents are committed.
Options
+++++++
-F FILE, --file FILE
Set the message used for the transaction note to the contents of the
file *FILE* (similar to the ``-F`` option for **cvs commit**).
-m MSG, --message MSG
Set the message used for the transaction note (similar to the ``-m``
option for **cvs commit**).
-r, --raise-on-conflicts
Tell **zsync** to raise an exception on conflicts instead of simply
reporting a list of paths for which conflicts are detected.
The **zsync delete** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**delete** *path* ...
Description
+++++++++++
The **delete** command has no specific options. It requires at least
one *path* argument.
The **zsync diff** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**diff** [*diff-options*] [*path* ...]
Description
+++++++++++
If *path* is given, only the named content objects are considered. If
not given, the current directory and all descendents are examined.
Options
+++++++
-b
Ignore changes in the amount of white space.
-B
Ignore changes that only insert or delete blank lines.
--brief
Report only that changes exist, not the details of the change.
-c
Generate a context diff.
-C NUM, --context NUM
Set the number of lines of context information included on each side
of changes to *NUM*.
-i
Ignore changes in case; consider upper- andlower-case letters
equivalent.
-N
When the files to be diffed include files being added or deleted,
perform comparisons between those files and ``/dev/null`` instead of
complaining about them.
-u
Generate a unified diff.
-U NUM, --unified NUM
Use the unified output format, showing *NUM* (an integer) lines of
context, or three if *NUM* is not given. For proper operation,
**patch** typically needs at least two lines of context.
The **zsync help** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**help** [*command* ...]
Description
+++++++++++
When used with specifying *command*, this displays general help on
using **zsync**. When *command* is given, information about each
command list is presented.
The **zsync mkdir** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**mkdir** *path* ...
Description
+++++++++++
Create one or more directories and schedule them for addition. The
additions are not made to the object database itself until the next
**zsync commit**. Reverting these additions with **zsync revert**
will not cause the directories themselves to be removed.
The **zsync resolve** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**resolve** [*path* ...]
Description
+++++++++++
Clear conflict markers from each *path*.
The **resolve** command has no specific options.
The **zsync revert** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**revert** [*path* ...]
Description
+++++++++++
Restore targets to their unmodified state. Files which have been
modified are overwritten by pristine copies of the data from
``@@Zope/Original/`` and scheduled additions and deletions are
de-scheduled. Additions that are de-scheduled do not cause the
working copy of the file to be removed.
The **zsync status** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**status** [*path* ...]
Description
+++++++++++
The **status** command has no specific options.
The **zsync update** Command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Synopsis
++++++++
**update** [*path* ...]
Description
+++++++++++
The **update** command has no specific options.
Security Notes
--------------
- The ``@@Zope/Root`` file contains the username and password with
which the checkout was made. Since this will typically allow access
with content management priviledges, this file should not be shared
carelessly.
Files
-----
When **zsync** is used to checkout a Zope 3 website (or a portion of a
site), it creates a directory structure on the local filesystem which
mirrors the containment hierarchy of the object database underlying
the application server. The directory structure includes both content
data and metadata used to support **zsync** operation.
Since content in the object database can be fairly sophisticated
internally, not all object types may naturally serialize into single
files. To accomodate the **zsync** support information and the
complex data requirements for content objects, every directory that
contains database objects contains an additional directory named
``@@Zope/`` that contains the additional information needed.
An ``@@Zope/`` directory contains the following:
``Entries.xml``
A file containing supplemental information needed for filesystem
synchronization. This is managed by **zsync**; you should never
need to peek inside here.
``Annotations/``
A directory that contains annotation data for the objects in the
content directory. This directory contains child directories with
the same name as the content objects, and each of those diretories
has a file for each annotation; the file names there are the names
of the annotations, and the contents of those files are the
serializations of the annotation values.
This is only present if there are objects in the content directory
which have annotations.
``Extra/``
Objects which require data beyond what's present in their basic
serialized form to restore object state will cause it to be written
here. This directory contains child directories with the same name
as the content objects, and each of those diretories has a file for
each piece of named additional information.
This is only present if there are objects in the content directory
which have "extra" data.
As an example, a File content object may have the MIME content type
of the file stored as the ``contentType`` value in the ``Extra/``
directory. If the content object is named ``foo.ext``, the content
type information would be stored in the file
``@@Zope/Extra/foo.ext/contentType``.
``Original/``
A directory that contains a copy of the unmodified content data.
This is only present if there are non-container content objects in
the content directory.
``Root``
File that gives the base URL for the checkout represented by the
filesystem representation. The URL must include the username and
password needed for authentication, so care must be taken in sharing
access to a checkout. This only exists in the ``@@Zope/`` directory
for the top-level checkout.
Reporting Bugs
--------------
Bugs in **zsync** and the filesystem synchronization support in Zope 3
should be reported via the `Zope 3 Development Issue Collector`__, an
online reporting tool that allows you to enter reports directly into
our bug-tracking system.
.. __: http://collector.zope.org/Zope3-dev
See Also
--------
There are two interesting and directly relevant articles in the `Zope 3
wiki`:
* The |FSSYNC|_ is the initial proposal for a way to synchronize
copies of a Zope-based website between a filesystem-based
representation and the database backing the live site.
* Bundles are discussed in |TTWSITE|_; this gives more information on
the motivation and goals surrounding this work.
.. |FSSYNC| replace:: Filesystem Synchronization Proposal
.. |TTWSITE| replace:: Through the Web Site Development
.. _FSSYNC: http://dev.zope.org/Zope3/FileSystemSynchronizationProposal
.. _TTWSITE: http://dev.zope.org/Zope3/ThroughTheWebSiteDevelopment
Copyright
---------
Copyright (c) 2003 `Zope Corporation`__ and Contributors.
All Rights Reserved.
.. __: http://www.zope.com/
This software is subject to the provisions of the `Zope Public
License`_, Version 2.0 (ZPL). A copy of the ZPL should accompany
this distribution. THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL
EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST
INFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE.
.. _Zope Public License: http://www.zope.org/Resources/ZPL
More information about the Zope3-Checkins
mailing list