[Zope-dev] Re: SVN: Zope/branches/2.9/ Move to ZODB 3.6 final.

[Tim Peters]

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