[Zope-dev] Re: CVS File 0.9 bugs

[Craeg K Strong]

Thanks for your note.

Yes, version 0.9 went out with some silly bugs, and I haven't had time 
to fix them.
However, we now have a customer funding some Zope-related work, so I
imagine I will have time to work on CVSFile again within 3-6 weeks.

CVSFile will be supported until it gets replaced by another Zope add-on
that will add CVS functionality to the Adaptable Persistence Engine (APE).
We will be looking into that for our customer as well.  APE is the wave
of the future, it will ultimately replace ExternalFile (the current 
underpinnings
of CVSFile), ExtFile, LocalFS, and lots of other related products.

As far as migrating from a Zope site developed the traditional way, you have
to decide what is worth versioning and what is not.  For example, in 
what format
is your content?  Is it in XML?  HTML?  Is it mixed in with your formatting
directives inside your ZPTs? Or perhaps is it all in DTML documents?

We used versioning for anything meeting any of the following criteria
- multiple developers might work on it simultaneously
- content that needs to be reused
- anything changing rapidly that might need to be reverted or needs an 
audit trail

Under that definition, quite a few zope objects should be versioned, all but
the most trivial ones, really.

One option is to have a folder full of versioned CVSFiles in a tree, 
parallel
to your "real" site.  Your "real" site then merely navigates in via 
aquisition and retrieves its
content from objects within the versioned area.   That way, you have *two*
hierarchies.  One is for the site.  One matches the file system and CVS.

I found this arrangement a little easier to handle, because I could 
refresh the
entire CVSFile hierarchy in a batch and watch my website update :-)
See the latest CVSFile batch oriented functionality for more details.

Hope this helps,

--Craeg

PS, I cc'd the zope-dev mailing list, as I feel the conversation might 
be helpful to others...

Guido Notari wrote:

>Dear Sirs,
>we're examining your CVS File Zope product, and we feel it has the
>potential to be hugely useful to the serious Zope developer.
>I am eager to give it a serious try, and integrate it in one of our
>projects.
>
>I had difficulties with it, though, and found some little bugs, you may be
>already aware of.
>
>Actually, I'm having problems with the CVS Management tag of a CVS File
>instance: as it goes, the page template file (cvs.pt) names the called
>methods with incorrect spelling. Among the others, I found
>manage_updateFile instead of manage_UpdateFile, and manage_commitFile
>instead of manage_CommitFile.
>There are probably others...
>
>In the light of these little bugs, considering that Revision 0.9.0 was
>released a few month ago (May 2003), I cannot refrain from asking:
>Is CVS File supported anymore? Why such obvious bugs got unnoticed?
>(possibly by bud luck and page templates been rushed in place?)
>
>I would really like to hear from you, I don't really want to lose the
>opportunity to test the product, if indeed is usable.
>
>And, speaking of doubts... It's not really obvious to me how to migrate
>_into_ a CVS an existing Zope site, developed in the "traditional" way.
>Have you got any "standard" method you're adopting to make such a move?
>Perhaps some kind of dump product?
>
>Best regards
>Guido Notari
>
>--
> __/__/   Link I.T. spa                   Tel > +39 0332 250111
> __/__/   Servizi Integrati Avanzati      Fax > +39 0332 250199
>          via Cairoli, 5 - 21100 Varese   http://www.linkgroup.it/
>
>
>  
>

-- 
Craeg K Strong, General Partner
Ariel Partners LLC
http://www.arielpartners.com
voice 781-647-2425
fax   781-647-9690

NOTICE: This message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any review,
retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than
the intended recipient is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all
copies -- including electronic copies -- of the original message.