What to do about our repository (was: svn.collab.net is now running 1.5.0-alpha2)

There's been some discussion about the plan I put forth regarding our own
svn.collab.net repositories. If I had to guess, I'd say 90% of the mails
are folks explaining more precisely what it is I was planning to do and why
it carries the consequences I noted. The remaining few actually express
some opinion.

So where do we stand on this thing? Checking out working new copies is no
problem for me -- I've been branch-happy lately anyway, so I've been
checking out trees left and right. (And our tree isn't a very large one.)
But I can understand if folks would rather not go that route. If I'm doing
my counting right, so far it seems Justin is opposed, and while there have
been several folks *for* this change in IRC, they haven't really stated as
much in this thread.

As I see it, there are three different ways this can go:

   1. We run 'svnadmin upgrade' and 'svn-populate-node-origins-index' and
      'svnmerge-migrate-history.py' and 'fsfs-reshard.py' on
      our repository. We get 1.5 features, HEAD svnmerge.py history migrated
      and a populated node-origins index. Our merge tracking internals are
      out of sync, but while it is inelegant, we don't think this will cause
      a problem. If there are earlier proto-forms of merge tracking property
      syntax in our tree that are not supported in alpha2, they may cause us
      problems later (but I don't know if there are). Nobody needs to
      checkout new working copies.

   2. We dump/load our repository with no filtering and run
      'svnmerge-migrate-history.py' on it. Same benefits as the previous
      case except our node-origins cache is optimized, our merge tracking
      internals are in sync, and we'll know if we have bogus proto-forms of
      merge tracking property syntax because they might cause this whole
      process to fail. Nobody needs to checkout new working copies.

   3. We dump/load our repository with filtering and run
      'svnmerge-migrate-history'. We get the benefits of the previous case
      plus a cleanup of old mergeinfo that wasn't supposed to be there anyway
      plus retroactive migration of our svnmerge history (instead of only
      HEAD). Old proto-forms of merge tracking property syntax are no
      problem because we've purged all that stuff. We all need new working
      copies.

Thoughts? Opinions? Concerns?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand