2008-03-03 16:11 C. Michael Pilato <cmpilato_at_collab.net> napisał(a):
> 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?
Do you also plan to introduce blocking of commits from pre-1.5 clients?
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients
Received on 2008-03-04 18:49:41 CET