[Zope-dev] RE: Barriers to Zope popularity: Part 2: source control

Tue, 25 Sep 2001 10:24:38 -0400

I'd like to add some misinformation...errmm, comments. :^)  On the 
version control side, you're quite right, we're still behind on it. 
There _are_ some ways to get there, if you try hard enough.  But that's 
unacceptible.

There are two things long term that need to be done: filesystem 
synchronization and version control.  The former is a project to make it 
possible to represent and perhaps round-trip Zope data in a way friendly 
filesystem tools and patterns.  This obviously includes SCM systems like 
ClearCase.

We've had, at our Friday jam sessions, a couple of proposals on this. 
So far it's simply provoked rigorous discussion but not a lot of 
consensus, as balancing the competing goals is harder than it sounds.

I was talking with Jim yesterday over lunch about this, and whether the 
new component model would put filesystem synchronization in its scope. 
The short answer is, not in the first cut.  It will certainly make 
filesystem synchronization a lot easier, but we need to get it out the 
door and tackle filesystem syncing later.

Regarding version control...this is something that has been burned into 
our skulls in recent RFPs that we've responded to.  It's the number one 
thing we at ZC need to address to be more competitive in CMS bids.

So far the goals and use cases of DeltaV seem to best describe what 
we're currently thinking:

http://www.webdav.org/deltav/
http://www.webdav.org/deltav/goals/draft-ietf-webdav-version-goals-01.txt
http://www.webdav.org/deltav/scenarios/scenarios-00-1.htm

Note that this is for Zope itself to have a model for version control. 
Filesystem sync is the most obvious way to interface to a separate SCM 
system.  However, _if_ Zope adopted a repository model, it's conceivable 
that Zope could have an implementation of the repository that used an 
external system.  _Please_ understand that this is all hand-waving right 
now.  But I'm on the hook to incept versioning, so it's informed 
hand-waving. :^)

--Paul

Jay, Dylan wrote:

>>-----Original Message-----
>>From: Kenichi Sato
>>Sent: Monday, 24 September 2001 5:49 PM
>>To: djay
>>Subject: Barriers to Zope popularity: Part 2: source control
>>
>>
>>Dear Mr. Jay, Dylan,
>>
>>I am Ken Sato, a manager of software development projects. I'm now
>>taking a look at Zope as a tool to publish project related
>>information internally.
>>
>>Zope looks nice but I found it has two potential problems.
>>
>> 1. WYSIWYG editing
>> 2. Source control (by ClearCase)
>>
>>Then, I found that you pointed out exactly same things in the
>>zope-dev mailing list.
>>(http://lists.zope.org/pipermail/zope-dev/1999-September/001602.html)
>>
>>Because the post was two years ago, I wonder if you have already
>>solved the above problems. It would be very helpful for me if you
>>could give me some information on this issue, please.
>>
> 
> Hope you don't mind me CC'ing this to zope-dev. I still see both these
> issues as important and still see the lack of progress towards Zope working
> well in traditional development environments being a real outage. Plus
> others may have different opinions about the current state of affairs
> 
> 1. I have not used Zope Page Templates but these are supposed to solve the
> wysiwyg problem. They are an alternative to DMTLDocuments. They allow for
> much better seperation of code and presentation. Get you graphics people to
> use webdav to edit the html with whatever editor they want and the coding
> people argment the html rather than rip it appart.
> http://www.zope.org/Documentation/Articles/ZPT1
> 
> Personally I like DTML and back then I did suggest a way DTML could used in
> a similar way to Page Templates (basically have a view mode of a DTML
> document that incorparates the rendered content as well as the DTML code
> such that when the page is edited and saved back, it will save all the
> changed parts back to the where they came from, i.e. the different
> DTMLMethods that made up the page). but like most of my ideas I din't have
> the ability or time to implement it.
> 
> 
> 2. Hasn't really been solved. There are sort of attempts that work now with
> CVS (I havn't tried it)
> http://www.zope.org/Members/sspickle/ZCVSMixin
> This 
> 
> but there are proposals that will better solve this problem, but no
> implementation on the way that I can see.
> The problem is really one of synchronization. You want two different
> representations that are both kept upto date. One for zope to use, one for
> all the reasons we have things under source control. You may or may not want
> control of when the synchronization occurs.
> 
> Here are some related proposals
> 
> http://www.zope.org//Wikis/DevSite/Proposals/SynchronizationMechanismZCVSMix
> in
> 
> http://www.zope.org/Wikis/DevSite/Proposals/SynchronizationTab
> 
> http://www.zope.org/Wikis/DevSite/Proposals/RepresentingObjectsOnTheFilesyst
> em
> 
> I also see a lot of parallels with the work going on with ZODB replication.
> If you had replication between a normal ZODB and some filesystem source
> control ZODB then you would have the source control synchronization problem
> solved maybe?
> 
> http://dev.zope.org/Wikis/DevSite/Projects/ZEOReplicatedStorage/FrontPage
> 
> 
> 
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope )
> 