Re: [Collective-versioning] Re: [houston-sprint] Focus & Direction

[Alberto B. <al...@me...>]

Il giorno lun, 08-11-2004 alle 20:39 -0600, alan runyan ha scritto:

> I understand what it looks like - and I'm not trying to be inconsiderate.
> Basically the versioning in CMFEditions looks like what we will be using.
> There is an awful lot in there that covers their use-cases that isnt
> generic enough for Plone.  Search for 'portal_multisite' in CMFEditions.
> 

The versioning stuff really require a CMF site, so it's generic.It's not "clean code" yet but we are working on that.

> Some of the code needs to be cleaned up and factored out.  The basic
> versioning scheme is all the same across all of these projects -
> ZopeVersionControl.  I am more interested when ZVC is *not* appropriate.
> We have nailed down the ZVC parts.  We are going to sync up with
> CMFEditions guys - I hope.  They are busy working on their code for a
> delivery.
> 
Gregoire, Duncan and the reflab's guys knows  that I really  don't like
ZVC. What it does is really pickling and object and putting it in a
IOBTree. It has a nonsense api form me, and a lot of the code is there
to handle the branching stuff that we don't use now, but i don't think
it's a correct way to handle "the big branching problem" as i said to
Robert Spencer in another mail.
Personally, i would love to get rid of it, but I know that Greg has
different opinions on the subject so I've moved the problem somewhere in
the future, even if Greg and I are discussing it.  I see also another
problem with ZVC, that we must address in the future as Duncan said
before. There will be the need to move VersionHistories between
repositories, maybe because content export and import, maybe for other
purposes, and  current ZVC really doesn't permit a quick way for two
repositories to being compared, discovering in what they differ,
especially due in how VersionHistories  numbering is done...
Finally i think however that there will not be any problem of getting
rid of ZVC, thank to the simplified api that we use for storing versions
now, and if we in the future use a "multi layer" strategy to implement
versioning features.

> What I am hoping is possible is that we can say here are the tools and
> CMFEditions can call our API's instead of using their own.  Does that
> make sense?  They may not be able to participate.  We have very competent
> people.  Enfold is sponsoring Kapil to come to Houston.  Rice has some use
> cases.  Some coders from Comp. Associates will be there.
> 

Maybe yes, I we are able to communicate respective needs...whe will see.
I will try to find the time to keep in touch with you guys during  the
sprint, even if the timezone difference will not semplify that...

> I am trying to lead people into something that everyone can use.  So its
> basic.  Something that we can potential port our code over to using as
> well.

CMFEditions VersionTool accomplishes one of most basic use cases right
now e.g. versioning without staging.

I'm sorry for my bad english

-- 
Alberto Berti <al...@me...>