Re: SVN: Zope/branches/2.9/ Move to ZODB 3.6 final.
Hi, Why not use the tag you just made? ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0/src/ZODB etc. (Hi have a vague feeling this may have been discussed before but I'm not sure ;)). Florent Tim Peters wrote:
Log message for revision 41156: Move to ZODB 3.6 final.
Changed: _U Zope/branches/2.9/doc/ _U Zope/branches/2.9/lib/python/ _U Zope/branches/2.9/utilities/
-=-
Property changes on: Zope/branches/2.9/doc ___________________________________________________________________ Name: svn:externals - ZEO -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/doc/ZEO
+ ZEO -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/doc/ZEO
Property changes on: Zope/branches/2.9/lib/python ___________________________________________________________________ Name: svn:externals - ZConfig svn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1 BTrees -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/BTrees persistent -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/persistent ThreadedAsync -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ThreadedAsync transaction -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/transaction ZEO -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZEO ZODB -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZODB ZopeUndo -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZopeUndo zdaemon -r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon pytz -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/pytz zodbcode -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/zodbcode ClientCookie -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/ClientCookie mechanize -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/mechanize
+ ZConfig svn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1 BTrees -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/BTrees persistent -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/persistent ThreadedAsync -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ThreadedAsync transaction -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/transaction ZEO -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZEO ZODB -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZODB ZopeUndo -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZopeUndo zdaemon -r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon pytz -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/pytz zodbcode -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/zodbcode ClientCookie -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/ClientCookie mechanize -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/mechanize
Property changes on: Zope/branches/2.9/utilities ___________________________________________________________________ Name: svn:externals - ZODBTools -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/scripts
+ ZODBTools -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/scripts
_______________________________________________ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
-- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
[Florent Guillaume]
Why not use the tag you just made? ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0/src/ZODB etc.
Ask Jim ;-)
(Hi have a vague feeling this may have been discussed before but I'm not sure ;)).
I'm not sure it's been coherently discussed on a mailing list: - While a tag is conceptually read-only, sometimes people do make changes on tags. You can't cheat (or get screwed by someone else cheating) with -r NNNNN, though, - Updates to a different revision on the same SVN path typically go much faster, replacing only the files that have changed. When the SVN path changes (as was true when stitching in ZODB by tag), the entire project is refetched. When moving from ZODB 3.6.0b6 to 3.6.0 final, that's the difference between getting all the ZODB code again, or just getting the 3 (or so) files that changed (more files than that _did_ change in ZODB 3.6 final, but Zope doesn't include them -- the others are part of the standalone ZODB release). - When the SVN path changes, people who leave old .pyc (or other not-checked-in) files behind end up with OLD.n directories created by SVN too. Overall, I like tags better myself: - They're self-documenting. - I never leave old .pyc (etc) files around, always recompile everything, and do something else while `svn up` is running, so in all I just don't notice any of the "bad" aspects of using tags. - It's less error-prone to edit svn:externals to change a character or two in a mnemonically-named tag path than to replace an arbitrary-looking revision number. For example, I stitched ZODB 3.6 into 4 Zopes yesterday, doing propedit on 8 directories total. I screwed it up at first but didn't notice until after running tests, and then had to repair it and run them all over again: it turned out that the older -r 41065 wasn't unique to ZODB in all of them. s/41065/41153/g was semantically wrong, unintentionally updating some _non_-ZODB externals to rev 41553 too. If we had stuck to using tags, s/3.6.0b6/3.6.0/g would been right the first time around. So there are tradeoffs, and people won't agree on which is best overall. Jim has a strong preference for -r NNNNN, and much stronger than my will to argue about it ;-)
Tim Peters wrote:
[Florent Guillaume]
Why not use the tag you just made? ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0/src/ZODB etc.
Ask Jim ;-)
I don't like using tags in externals. Each time an external is changed to a tag, svn creates .OLD directories and gets a new version. It's a real hassle IMO. I especialy don't like this on the trunk, or on a branch. I don't really mind using a tag for a release. For example, I wouldn't necessarily mind if the Zope 3.2.0 release itself was based on a tag of ZODB. But I don't think it's all that important either. What I especially don't like is forcing a release and tag of something just because we want to use it somewhere else. For example, I would hate to create a tag in zope.testing just so Zope could use a later revision.
(Hi have a vague feeling this may have been discussed before but I'm not sure ;)).
I'm not sure it's been coherently discussed on a mailing list:
- While a tag is conceptually read-only, sometimes people do make changes on tags. You can't cheat (or get screwed by someone else cheating) with -r NNNNN, though,
- Updates to a different revision on the same SVN path typically go much faster, replacing only the files that have changed. When the SVN path changes (as was true when stitching in ZODB by tag), the entire project is refetched. When moving from ZODB 3.6.0b6 to 3.6.0 final, that's the difference between getting all the ZODB code again, or just getting the 3 (or so) files that changed (more files than that _did_ change in ZODB 3.6 final, but Zope doesn't include them -- the others are part of the standalone ZODB release).
- When the SVN path changes, people who leave old .pyc (or other not-checked-in) files behind end up with OLD.n directories created by SVN too.
Overall, I like tags better myself:
- They're self-documenting.
Yes if they are real tags. I don't think adds much documentation is created soley so that something else can have a tag in an external. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
--On 6. Januar 2006 10:49:29 -0500 Jim Fulton <jim@zope.com> wrote:
I don't like using tags in externals. Each time an external is changed to a tag, svn creates .OLD directories and gets a new version. It's a real hassle IMO.
I _like_ tags in externals because they are self-documenting. Dealing with externals where you have several different revision numbers is a PIA since you never know what version of a module is behind the revision. You always have look through the log for the referenced module...that's very time consuming. I see this as a major risk factor when working on releases. -aj
participants (4)
-
Andreas Jung -
Florent Guillaume -
Jim Fulton -
Tim Peters