Well, it looks like of the folks that voiced opinions, this is falling
toward option #3, so that's the route I'm going to take. I will tweak UUIDs
to be different, and I will *not* (at this time, anyway) install hooks that
prevent 1.4 clients from committing.
I'll transmit a followup mail when this is all done.
C. Michael Pilato wrote:
> 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
Received on 2008-03-05 16:40:40 CET