[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Arfrever Frehtes Taifersar Arahesis <arfrever.fta_at_gmail.com>
Date: Tue, 4 Mar 2008 18:49:22 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.