[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 ;-)