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

Re: Node origins cache rewrite

From: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 28 Jan 2008 13:25:34 -0500

On Jan 28, 2008 1:18 PM, David Glasser <glasser_at_davidglasser.net> wrote:
> On Jan 27, 2008 8:08 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> >
> > Can you explain a little more the impact on existing repositories.
> >
> > 1) Dump/Load would generate the new node-ID so all would be good if
> > you did that approach.
> Yes.
> > 2) Say I have 10,000 revisions in my 1.4 repository. I move to 1.5.
> See, what does that mean? It could mean one of three things:
> (a) You don't change the FS format of the repository at all, so it's
> still '2'. You have the poor performance of uncached history-walks.
> On the other hand, it is very likely that we will have to forbid you
> from using merge tracking on such a repository anyway.
> (b) You change the FS format to '3' using the *only currently
> officially supported method*, which is a dump and a load. All's well.
> (c) You change the FS format to '3' using the unsupported method of
> manually changing the format number (and creating txn-current, and
> creating txn-protorevs, etc etc etc). New node-IDs contain the rev in
> them; old node-IDs (including new noderevs from old nodes) don't and
> require the slow walk. But hey, you just did something unsupported
> anyway.
> (d) You run some sort of "svnadmin upgrade" command which does the
> same thing as (c), except it's actually supported. Then, well, yeah,
> you have the same downside, and us developers don't get the excuse of
> "you did something unsupported".

Well, we have the script to shard a repository. That must change the
format. I was also under the impression (back when SQLite was used)
that the first time you committed something with mergeinfo, then
SQLite db was created. Did this not bump the format? Maybe that was
just tied to sharding?

> Really I think if you care about the performance of this particular
> operation, then you dump and load. (Or run svnsync, or whatever.)
> It's not that hard, and as long as you have space on the machine it
> shouldn't even require downtime. Justin said the ASF would be happy
> with that.

I do not recall Justin saying he would be happy with this. Are you
saying he would use svnsync to migrate and then "flip the switch"?

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-28 19:25:44 CET

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