[Tim Peters] >> People who think they understand those projects first need to make >> tags, so Zope 2.8 has something to point _to_. Also, Zope, Zope3, and >> ZODB should all coordinate to make sure they're using the same tags >> for zdaemon and ZConfig. Else, e.g., I develop ZODB using a ZConfig >> that doesn't match the one Zope uses, and then things break when Zope >> moves to a newer ZODB.
[Andreas Jung] > So am I right that you develop the ZODB already against two different > ZConfig versions (for Zope 2.8 and Zope 3)? No: under SVN, ZODB has its own copy of ZConfig, and its own copy of zdaemon. The copies of those ZODB currently uses may or may not have anything in common with the copies of those Zope trunk currently uses, and those in turn may or may not have anything in common with the copies of those Zope3 uses, and so on. When Zope or Zope3 trunk get a new version of ZODB stitched in, they do _not_ get new copies of ZConfig and zdaemon at the same time. Those aren't part of ZODB. ZODB development simply uses ZConfig and zdaemon, same as Zope 2.8 and Zope3 develpment simply uses them. A difference is that I pay an enormous amount of attention to making sure Zope and Zope3 trunks are using "good" versions of ZODB. Nobody pays any attention (so far) to the versions of ZConfig and zdaemon used by Zope and Zope3 trunks. Somebody should; as I said before, I used to try to keep zdaemon and ZConfig copies in synch across SVN projects too, but I stopped trying months ago (too much else to do). Another key difference is that nobody identifiable "is in charge of" either ZConfig or zdaemon. > So an unique ZConfig repository does make sense to you I'm not sure I follow your meaning here. ZConfig already has its own repository, and that has nothing to do with me personally. ZConfig (ditto zdaemon) is a distinct project from all the others, and actually always has been (it's simply much clearer that this is so under SVN than it was under CVS, due to mountains of "repolink" magic under CVS that blurred the boundaries between distinct projects). > - of course only it is used by everyone. For me it would make perfect > sense to get rid of the local copies since it removes the need to maintain > multiple copies. It was never the intent that multiple copies be maintained. The original intent was that whoever was in charge of a project A would, from time to time, copy in new releases of the external projects A relies on. With svn externals, you can do that by editing a property. Using copies, it requires a long dance, along the lines of: - Talk the person in charge of an external project E into examining A to find checkins made to E _from_ A. Those changes need to be merged back into E. Or someone from A can do the merge into E. Regardless, A cannot retain unique (to A) changes in E unless A intends to fork E, in which case A takes full responsibility for maintaining A's copy of E forever after. - Then the person in charge of A does svn switch to a new (merged) version of E locally and tests it; if that passes, svn switch back to A's old version of E; svn remove A's E code; svn commit the removal; svn copy the new version of E into A; svn commit the new version. I'm not sure anyone but me ever did that dance, and I got sick to death of it -- "the merge step" in particular could take an arbitrary and unpredictable amount of time, and was extremely error-prone. This was in part because, using copies, _most_ people working on Zope and Zope3 really have scant idea of which part of the code "belongs" to Zope and which doesn't, so routinely check in changes to (copies of) external projects. My ZODB life has been much easier since Zope and Zope3 trunks switched to using svn externals for their piles of ZODB directories. > @Jim: what's your opinion on this subject? Jim likes copies better than externals. If you can get him to explain why, you should win a fabulous prize <wink>. But, regardless, you and Brian (I think) are in charge of Zope 2.8 now, so "your project, your call" rules. _______________________________________________ Zope-Coders mailing list Zope-Coders@zope.org http://mail.zope.org/mailman/listinfo/zope-coders
