ZSyncer 0.7.0 Released Version 0.7.0-final (2005/12/15) is available for download from sourceforge: http://sourceforge.net/project/showfiles.php?group_id=28073&package_id=20913... ZSyncer is a Zope 2 product that allows you to synchronize and compare objects from one zope (source) to another (destination). It is a lot more convenient than the old manual export / transfer / import procedure. Noteworthy changes since 0.6.2: Features added: * We now have two-directional sync! Instead of just "sync", we now have both "put" (like the old sync) and "get" (pulls changes from the remote system to the client system). Thanks Alan Milligan! * new method of ZSyncer and ZSyncerTool: callManyRemote() to call multiple arbitrary methods on the remote system and return a list of results. * Pretty complete example skins for ZSyncerTool integration with CMF/Plone. See README.txt for more instructions. Doesn't have all features yet (e.g. no "pull" support). * Should work with Zope 2.8 now! * The "override user" stuff is removed from the UI. You now have to use the proto://user:passwd@server url format. See README.txt for more information. * The (broken) XMLRPC code has been removed. * New config variable, "upload_threshold_kbytes", determines the point at which the server spools data to a temp file instead of RAM. * "delete" now deletes from both local and remote systems. * SSL connections using ConnectionMgr should now set timeout properly. * Lots of unit tests! For bugfixes and older changes, see CHANGES.txt. -- Paul Winkler http://www.slinkp.com
ZSyncer 0.7.1-beta1 Released ZSyncer is a Zope 2 product that allows you to synchronize and compare objects from one zope (source) to another (destination). It is a lot more convenient than the old manual export / transfer / import procedure. Version 0.7.1-beta1 (2005/12/22) is available for download from sourceforge: http://sourceforge.net/project/showfiles.php?group_id=28073 This is a beta of a minor bugfix release. The fixes are all UI-related, and thus 0.7.1 should interoperate well with 0.7.0. I encourage everybody using (or thinking of using) 0.7.0 to upgrade to 0.7.1 so we can get some feedback and get another stable release out soon. Thanks! -- Paul Winkler http://www.slinkp.com
Hi, we just installed Zsyncer 0.7.1-beta1 on a couple of our servers and have run into some problems with page template synchronization. Some items that have different time stamps on the server and on the development machines show on th sync screen as synchronized even when they are different. Then if we do a 'get' from the client, it fetches the file but the objects now appear as unsynchronized! We are using Zope 2.8.0 on the clients (Windows) and Zope 2.8.4 on the server (Linux), could this be the problem? Thanks a lot. Carlos de la Guardia On 12/22/05, Paul Winkler <pw_lists@slinkp.com> wrote:
ZSyncer 0.7.1-beta1 Released
ZSyncer is a Zope 2 product that allows you to synchronize and compare objects from one zope (source) to another (destination). It is a lot more convenient than the old manual export / transfer / import procedure.
Version 0.7.1-beta1 (2005/12/22) is available for download from sourceforge: http://sourceforge.net/project/showfiles.php?group_id=28073
This is a beta of a minor bugfix release. The fixes are all UI-related, and thus 0.7.1 should interoperate well with 0.7.0.
I encourage everybody using (or thinking of using) 0.7.0 to upgrade to 0.7.1 so we can get some feedback and get another stable release out soon.
Thanks!
--
Paul Winkler http://www.slinkp.com _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Fri, Jan 13, 2006 at 09:08:26PM -0600, Carlos de la Guardia wrote:
Hi,
we just installed Zsyncer 0.7.1-beta1 on a couple of our servers and have run into some problems with page template synchronization. Some items that have different time stamps on the server and on the development machines show on th sync screen as synchronized even when they are different. Then if we do a 'get' from the client, it fetches the file but the objects now appear as unsynchronized!
Yes. These are limitations of comparing objects that have only a bobobase_modification_time timestamp. See ZSyncer/README.txt, in the "Usage" section. Solving this problem is hard. See ZSyncer/TODO.txt.
We are using Zope 2.8.0 on the clients (Windows) and Zope 2.8.4 on the server (Linux), could this be the problem?
I have no experience running clients and server on different platforms, but I doubt that is the issue. Do the system clocks on client and server agree? It's best if they are as close as you can make them. You might also try adjusting the "fudge_secs" value in ZSyncer/Config.py. Read the comment describing its purpose. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote at 2006-1-14 15:30 -0500:
On Fri, Jan 13, 2006 at 09:08:26PM -0600, Carlos de la Guardia wrote:
we just installed Zsyncer 0.7.1-beta1 on a couple of our servers and have run into some problems with page template synchronization. Some items that have different time stamps on the server and on the development machines show on th sync screen as synchronized even when they are different. Then if we do a 'get' from the client, it fetches the file but the objects now appear as unsynchronized!
Yes. These are limitations of comparing objects that have only a bobobase_modification_time timestamp. See ZSyncer/README.txt, in the "Usage" section.
Solving this problem is hard. See ZSyncer/TODO.txt.
You should remember the synchronized "bobobase_modification_time"s (this may cost an additional (small) request). -- Dieter
On Sun, Jan 15, 2006 at 09:24:35PM +0100, Dieter Maurer wrote:
Paul Winkler wrote at 2006-1-14 15:30 -0500:
On Fri, Jan 13, 2006 at 09:08:26PM -0600, Carlos de la Guardia wrote:
we just installed Zsyncer 0.7.1-beta1 on a couple of our servers and have run into some problems with page template synchronization. Some items that have different time stamps on the server and on the development machines show on th sync screen as synchronized even when they are different. Then if we do a 'get' from the client, it fetches the file but the objects now appear as unsynchronized!
Yes. These are limitations of comparing objects that have only a bobobase_modification_time timestamp. See ZSyncer/README.txt, in the "Usage" section.
Solving this problem is hard. See ZSyncer/TODO.txt.
You should remember the synchronized "bobobase_modification_time"s (this may cost an additional (small) request).
I'm sorry, I can't seem to understand what you mean. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote at 2006-1-15 17:28 -0500:
...
Yes. These are limitations of comparing objects that have only a bobobase_modification_time timestamp. See ZSyncer/README.txt, in the "Usage" section.
Solving this problem is hard. See ZSyncer/TODO.txt.
You should remember the synchronized "bobobase_modification_time"s (this may cost an additional (small) request).
I'm sorry, I can't seem to understand what you mean.
Synchronization modifies "bobobase_modification_time" on the target. A safe method to check whether you have a current state is to register the "bobobase_modification_time" (on source and target) that resulted from the synchronization. A resynchronization is necessary when the "bobobase_modification_time" moved away from the registered "sync_bobobase_time"s. -- Dieter
On Mon, Jan 16, 2006 at 07:48:45PM +0100, Dieter Maurer wrote:
Synchronization modifies "bobobase_modification_time" on the target.
Yep.
A safe method to check whether you have a current state is to register the "bobobase_modification_time" (on source and target) that resulted from the synchronization. A resynchronization is necessary when the "bobobase_modification_time" moved away from the registered "sync_bobobase_time"s.
Ahhh, now I see. Thank you, this is probably cheaper than most of my ideas. I could store that info in a BTree of some flavor. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote at 2006-1-16 14:32 -0500:
On Mon, Jan 16, 2006 at 07:48:45PM +0100, Dieter Maurer wrote:
Synchronization modifies "bobobase_modification_time" on the target.
Yep.
A safe method to check whether you have a current state is to register the "bobobase_modification_time" (on source and target) that resulted from the synchronization. A resynchronization is necessary when the "bobobase_modification_time" moved away from the registered "sync_bobobase_time"s.
Ahhh, now I see. Thank you, this is probably cheaper than most of my ideas. I could store that info in a BTree of some flavor.
An alternative would be a persistent subobject of the synchronized object (such that its modification does not modify the "bobobase_modification_time" of the primary object). I just notice that synchronization of structured (e.g. "ObjectManager") objects might be a problem. As subobjects might also be synchronizable, they, too, should get the correct times. -- Dieter
On Tue, Jan 17, 2006 at 07:13:53PM +0100, Dieter Maurer wrote:
Paul Winkler wrote at 2006-1-16 14:32 -0500:
On Mon, Jan 16, 2006 at 07:48:45PM +0100, Dieter Maurer wrote:
Synchronization modifies "bobobase_modification_time" on the target.
Yep.
A safe method to check whether you have a current state is to register the "bobobase_modification_time" (on source and target) that resulted from the synchronization. A resynchronization is necessary when the "bobobase_modification_time" moved away from the registered "sync_bobobase_time"s.
Ahhh, now I see. Thank you, this is probably cheaper than most of my ideas. I could store that info in a BTree of some flavor.
An alternative would be a persistent subobject of the synchronized object (such that its modification does not modify the "bobobase_modification_time" of the primary object).
That's not good: unless i find a suitable core zope class to use, if the user ever uninstalls ZSyncer, all of his objects are broken! in general, i don't like to pile more data onto the poor user's unsuspecting objects. I have done it, i just don't like it :-)
I just notice that synchronization of structured (e.g. "ObjectManager") objects might be a problem. As subobjects might also be synchronizable, they, too, should get the correct times.
Ugh, yes, that's a problem. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote at 2006-1-17 15:52 -0500:
...
An alternative would be a persistent subobject of the synchronized object (such that its modification does not modify the "bobobase_modification_time" of the primary object).
That's not good: unless i find a suitable core zope class to use, if the user ever uninstalls ZSyncer, all of his objects are broken!
Maybe, a "PersistantMapping"?
in general, i don't like to pile more data onto the poor user's unsuspecting objects. I have done it, i just don't like it :-)
Zope3 makes it a strategy (--> annotations), CMF uses it a lot (--> WorkflowState, Discussability, ...) -- Dieter
participants (3)
-
Carlos de la Guardia -
Dieter Maurer -
Paul Winkler