I can spend some time on the command line tool -- that would be ideal for us
anyway. Security isn't an issue, at least short term, as this is strictly for
In the next couple weeks I'll take a closer look.
If I understand the gist of the checkin/checkout model, there's profound
implications for TTW development. Would this not alleviate the SCM problerms of
code-in-the-ZODB-black-box syndrome that Zope 2 faces?
On , [EMAIL PROTECTED] wrote:
> Garrett Smith wrote:
>> I have a backup requirement to save a folder (a site) and be able to
>> restore it without effecting other sites on a server.
>> I looked briefly at Zope3's fssync but I'm not sure if it's current,
> I don't know if it's current. It is largely independent of
> Zope so it should
> still work.
> > or
>> exactly how it could be used for this.
>> Any recommendations?
> Sigh. I wish someone had time to work on this.
> It currently has a web-based interface that allows objects
> to be checked out and checked in, with semantics much like
> a version control system. We aren't using it because it lacks
> an adequate security model to support web-based access.
> FWIW, here are some thoughts of where I'd like to see this go:
> - I'd like to see 2 different types of interface:
> o A web based interface like we have now except that you should
> only be able to check out or in if the object being checked out
> or checked in has a fssyn adapter (other than the default) and
> if the user has the necessary permissions.
> o A command-line tool that opens the database directly. This tool
> would not go through the security system at all and would be able
> to use the default (xml-pickle-based) adapter.
> - (at least) Two modes should be supported.
> o checkout/checkin
> When objects are checked out, we make 2 copies (as svn does).
> This allows us to track and merge changes made in zope or
> on the file system.
> o export/import
> Here the goal is tranfering things. We don't make 2 copies.
Zope3-dev mailing list