[Zope-PTK] Workflow - security model

[Chalu Kim]

We have experimented with CVSMixin. It works and it is pretty cool. 

However, as you are describing how to make a use of CVS from Zope, it
seems to me that this usefulness part was not well thought out.
Likewise, many Zope modules are demonstrations of programming ability. I
marvel at that but I must say there needs to be a voice to the vision (I
heard about it. People say FishBowl and so on). 

What I am trying to say a few word is that I like to see a matrix of
features where these modules belong and see how they are developed
harmoniously for greater cooperation. 

It is apparent that Zope does not really have versioning.

I can't help to voice one of the ideas being kicked around our Zope
Users group. This CVSMixin is a good way to create versions but what we
like to see is following;

- Additional radio (or property) available on every object so that its
versions don't get packed. This way, history and Undo will survive the
discriminate packing (GC). 

- Better yet, develop a folder which uses its own ZODB file and you can
pack differently. This way, CVS is just redundant. Probably in the work,
Jim?


Steve Spicklemire wrote:
> 
> Hi Jay,
> 
> >>>>> "Jay," == Jay, Dylan <djay@avaya.com> writes:
> 
>     Jay,> PS. On a mildly related note. We are not progressing with
>     Jay,> Zope for our product despite the possibility of having to
>     Jay,> reproduce some of Zopes functionality in Java (mainly
>     Jay,> security and undo of some kind of database backend). The
>     Jay,> main reason for this was lack of control over the code. We
>     Jay,> have plenty of tools for doing software process using CVS
>     Jay,> for doing code reviews and merging etc. I can see no
>     Jay,> un-dodgy way to let code that resides in the the ODB to
>     Jay,> participate in this. What is needed is a full file per
>     Jay,> object based ODB implementation or something. This again
>     Jay,> runs into the same problem of "What about bizzare pickled
>     Jay,> object data?". And how would you match zope users to CVS
>     Jay,> users? And versions? How would changes in the file system
>     Jay,> get back into Zope?
> 
> This is the problem ZCVSMixin tries to solve. While it's certainly
> not perfect at this point, it does make life a lot more bearable,
> and I do know that lots of folks are using since I routinely get
> feedback about it... and that only helps make it better. There are
> two ways we use it:
> 
> 1) Each developer works on a different system. They run their own Zope
> and manage their own local CVS checkouts. It's just like normal CVS
> development except your checking in and out Zope objects in the form
> of xml and/or zexp files.
> 
> 2) Each developer has a different (basically mirrored) 'area' in a
> single Zope server. For each independent area there is a separate cvs
> hierarchy that maintains their modifications/checkouts. This is
> of limited usefulness since it can't be done with ZClasses and
> such... but it's useful for 'simple' content.
> 
> -steve
> 
> _______________________________________________
> Zope-PTK maillist  -  Zope-PTK@zope.org
> http://lists.zope.org/mailman/listinfo/zope-ptk
> 
> See http://www.zope.org/Products/PTK/Tracker for bug reports and feature requests