upgrading mysql repositories from format 1.14 to format 2a

Asked by GuilhemBichot

Hello. I am slowly preparing for the upgrade of our central internal host's shared repository of MySQL branches, from repository format 1.14 to 2a. I would like to use this bug report as the place of resolution of issues faced as I progress (I have already read the 2a upgrade guide).
I just upgraded my local shared repo from 1.14 to 2a with "bzr upgrade --2a" (it took ~8 hours); this local repo is a good approximation of our central repo.
My observations:
                                                    1.14 2a result
size of .bzr 850 MB 300 MB good
(after "bzr pack", and excluding "obsolete_packs")
time for "bzr log -n0" 23 secs 14 secs good
time for "bzr annotate big_file" 12 secs 24 secs bad

I'm using bzr.dev pulled a few days ago.
I think "annotate" is a serious problem, could you please fix the slowdown observed in 2a? My colleagues already complain of the slowness of annotate since we migrated to bzr, I'd rather not make it worse.
If you want to reproduce this: big_file above is sql/mysqld.cc from this branch:
https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-codebase-bugfixing

Then I have general questions. When I'm confident that the new format is good for us, I'll do the migration in steps:
- at T1: ask the 100+ colleagues to install bzr 2.1 (then most will, and a few won't, that happens)
- at T2: upgrade the central shared repo to 2a
- at T3: ask colleagues to upgrade their shared repo (either with "bzr upgrade --2a", or by "scp"-ing a copy of the central repo, to be determined later).
What I wonder is:
1) between T2 and T3, will a colleague with a 1.9/1.14 local repo be able to push to the 2a central repo? to pull from the 2a central repo? to "bzr branch" a branch from the 2a central repo?
2) after T2, will Launchpad mirroring (visible in https://code.launchpad.net/mysql-server) break?
3) after T2, will a colleague using an old bzr (like bzr 1.15) be able to accidentally break something by pushing/pulling to/from the 2a central repo, or will he get a nice error message?
Thanks for your help.

Question information

Language:
English Edit question
Status:
Answered
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Martin Pool (mbp) said :
#1

Hi,

This is more of a set of questions than a bug so I'm going to convert it.

Revision history for this message
Martin Pool (mbp) said :
#2

> 2) after T2, will Launchpad mirroring (visible in https://code.launchpad.net/mysql-server) break?

No, it won't. I checked with mwhudson and he said that Launchpad will re-mirror the branch if the source format changes.

Revision history for this message
Martin Pool (mbp) said :
#3

You might like to read <http://doc.bazaar.canonical.com/bzr.dev/en/upgrade-guide/index.html> if you have not already done so.

I'm glad 2a is smaller and mostly faster for you.

Annotate speed in <https://bugs.edge.launchpad.net/bzr/+bug/153787>; it's already marked high and affecting mysql. There are some things we can do there, though we should finish off some of the already in-progress work (on conflicts, log, etc) before getting into it.

> at T3: ask colleagues to upgrade their shared repo (either with "bzr upgrade --2a", or by "scp"-ing a copy of the central repo, to be determined later).

I would recommend that you ask them to instead make a new local 2a repository, branch your upgraded trunk into it, then branch in any work-in-progress branches they may have. This will probably be faster than everyone repeating the upgrade and branching all of 2a should be comparable in time to scping a tarball - though if it is faster to scp, that would also work.

> 1) between T2 and T3, will a colleague with a 1.9/1.14 local repo be able to push to the 2a central repo? to pull from the 2a central repo? to "bzr branch" a branch from the 2a central repo?

2a is a 'rich root' format; it stores some extra metadata to support foreign branches and subtrees. A consequence of this is that you can go from 1.9 or 1.14 to 2a but not the reverse. (There are some bugs tagged format-ui, that this is not sufficiently gracefully handled.) If some people want to stay on earlier versions they can do so by upgrading to 1.9-rich-root or 1.14-rich-root, which will be fast.

That said we would recommend that people do upgrade to 2.1 and 2a because that's where all our future bug work is going.

> 3) after T2, will a colleague using an old bzr (like bzr 1.15) be able to accidentally break something by pushing/pulling to/from the 2a central repo, or will he get a nice error message?

They should get a message something like "repository format 2a (needs bzr 2.0 or later)".

Hope that helps, just ask if any more questions come up.

Revision history for this message
John A Meinel (jameinel) said :
#4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

...
>> 1) between T2 and T3, will a colleague with a 1.9/1.14 local repo be
> able to push to the 2a central repo? to pull from the 2a central repo?
> to "bzr branch" a branch from the 2a central repo?
>
> 2a is a 'rich root' format; it stores some extra metadata to support
> foreign branches and subtrees. A consequence of this is that you can go
> from 1.9 or 1.14 to 2a but not the reverse. (There are some bugs
> tagged format-ui, that this is not sufficiently gracefully handled.) If
> some people want to stay on earlier versions they can do so by upgrading
> to 1.9-rich-root or 1.14-rich-root, which will be fast.

Actually, 1.9 => 1.9-rich-root requires rewriting the inventory text for
every revision, though it doesn't require rebuilding the text storage. I
would at least call it a wash, but wouldn't be surprised if upgrading
1.9 => 1.9-rich-root was slower than 1.9 => 2a.

>
> That said we would recommend that people do upgrade to 2.1 and 2a
> because that's where all our future bug work is going.
>
>> 3) after T2, will a colleague using an old bzr (like bzr 1.15) be able
> to accidentally break something by pushing/pulling to/from the 2a
> central repo, or will he get a nice error message?
>
> They should get a message something like "repository format 2a (needs
> bzr 2.0 or later)".

There was a bug where the short message was looked up in a dictionary,
and it wasn't found raising a key error. I don't know the exact versions
that introduced the bug or when it was fixed. But suffice it to say that
most people will get a simple error message, some will get that error
message inside of a traceback.

>
> Hope that helps, just ask if any more questions come up.
>

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktzV7MACgkQJdeBCYSNAAMSqACgxV/sQONJRmq4fA58hJN4hEPO
uz8AnjBpP11daFOKSdoFeLtaH6JwCxsb
=usxK
-----END PGP SIGNATURE-----

Revision history for this message
GuilhemBichot (guilhem-bichot) said :
#5

I'm sorry for being dumb, but I don't really understand the replies to
"1) between T2 and T3, will a colleague with a 1.9/1.14 local repo be able to push to the 2a central repo? to pull from the 2a central repo? to "bzr branch" a branch from the 2a central repo? "
Could you please rephrase the replies in the form of yes/no for each sub-question?

Then I have another one: assuming a colleague uses a local upgraded 2a repo and the central repo has not yet been upgraded, can he push to the central repo? can he pull from the central repo?

Thanks a lot!

Revision history for this message
John A Meinel (jameinel) said :
#6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> Question #100631 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/100631
>
> Status: Answered => Open
>
> GuilhemBichot is still having a problem:
> I'm sorry for being dumb, but I don't really understand the replies to
> "1) between T2 and T3, will a colleague with a 1.9/1.14 local repo be able to push to the 2a central repo? to pull from the 2a central repo? to "bzr branch" a branch from the 2a central repo? "
> Could you please rephrase the replies in the form of yes/no for each sub-question?
>

You can always push from 1.9/1.14 => 2a.
You cannot pull from 2a => 1.9, but you can pull to 1.9-rich-root.
You cannot branch from 2a => 1.9.

> Then I have another one: assuming a colleague uses a local upgraded 2a
> repo and the central repo has not yet been upgraded, can he push to the
> central repo? can he pull from the central repo?
>
> Thanks a lot!
>

If you locally use 2a, you cannot push to 1.9/1.14.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt0GUcACgkQJdeBCYSNAANp2gCfYefl8gEvcbh1Wml6gbcjDS8o
LkEAnRiyD2OD1Ljq+vecTIka3Dzw3XL4
=FjTM
-----END PGP SIGNATURE-----

Revision history for this message
GuilhemBichot (guilhem-bichot) said :
#7

To Martin, in reply to:
"I would recommend that you ask them to instead make a new local 2a repository, branch your upgraded trunk into it, then branch in any work-in-progress branches they may have. This will probably be faster than everyone repeating the upgrade and branching all of 2a should be comparable in time to scping a tarball - though if it is faster to scp, that would also work."
I can share some statistics: on my brand new workstation,
- "bzr upgrade" from 1.14 to 2a, takes 8 hours
- bzr init-repo local_repo_2a; cd local_repo_2a; bzr branch local_repo_1.14/some_representative_branch .
takes 5 hours
- the tar.gz of the 2a repo is 312MB (excluding obsolete_packs), I'd scp it to the shared machine, then people would download it from there; if they use scp it should take ~20 minutes (I experience 20MB/min roughly).

Revision history for this message
John A Meinel (jameinel) said :
#8

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> Question #100631 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/100631
>
> GuilhemBichot posted a new comment:
> To Martin, in reply to:
> "I would recommend that you ask them to instead make a new local 2a repository, branch your upgraded trunk into it, then branch in any work-in-progress branches they may have. This will probably be faster than everyone repeating the upgrade and branching all of 2a should be comparable in time to scping a tarball - though if it is faster to scp, that would also work."
> I can share some statistics: on my brand new workstation,
> - "bzr upgrade" from 1.14 to 2a, takes 8 hours

Upgrade upgrades all revisions in the repository.

> - bzr init-repo local_repo_2a; cd local_repo_2a; bzr branch local_repo_1.14/some_representative_branch .
> takes 5 hours

branch only upgrades the specific revisions in the ancestry of the branch.

My guess is that you would get significantly different results if it was
a 5.1 branch versus a 6.0 branch, etc.

> - the tar.gz of the 2a repo is 312MB (excluding obsolete_packs), I'd scp it to the shared machine, then people would download it from there; if they use scp it should take ~20 minutes (I experience 20MB/min roughly).
>

Sure, the question is whether:

bzr init-repo new_2a
cd new_2a
bzr branch REMOTE_2a/trunk

is specifically slower/faster than downloading a tar.gz.

Also, I would guess that .gz gives negligible compression over just
'.tar'. If that isn't the case, let us know.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt0L/gACgkQJdeBCYSNAAMbHgCg0FTJAg775eKQNOC50vnXoK+y
jVUAn2p/jJyOpsUsPwB00AQTtcARi48A
=IGE8
-----END PGP SIGNATURE-----

Revision history for this message
GuilhemBichot (guilhem-bichot) said :
#9

Hello John.
Right, tar.gz is 311MB whereas just tar is 317MB, not worth the gz. Good work guys on the compression side!
It seems that if I let my colleagues do the upgrade of their local repo themselves, either via "bzr upgrade" or making a fresh local 2a repo and "bzr branch"-ing each branch from their old local 1.14 repo to the new 2a repo, it will take them 8 hours, maybe more if they have a slower machine (laptop). So I'd rather offer them an upgraded repo for download. It surely won't be current (people push all the time, so my upgraded repo will be out of date), they will still need to refresh it with "bzr pull", and migrate their not-pushed branches, but it should save them most of the time as my upgraded repo will have the bulk of revisions.
So the procedure would be the following (each step is separated by indefinite amounts of time).

At T0 I install bzr 2.1 on the shared central host (it's 1.17-dev now), and I prepare an upgraded 2a repo on the shared central host, it takes 8 hours; it soons becomes out of date. I do "check -v" on it.

T1 I ask sysadmins to install bzr 2.1 on machines they manage (it's 1.15 now)

T2 I ask devs to install bzr 2.1 on their local machines, and to download the upgraded 2a repo from the shared central host to their local machine (scp or "bzr branch" into fresh local 2a repo).

T3 Optional steps for devs: they might at will unpack the downloaded repo on their machine and start using it: they can pull from the central host's 1.14 repo into this local 2a repo, but not push (they get an error); they can migrate their local branches into the local 2a repo with "bzr branch"; the migration is relatively fast because the shared repo I gave them has most revisions. Any migration they do now is time gained for later, but they still need their local 1.14 repo in order to be able to push. So their 2a repo is not usable for real work (no point in committing a revision there).

T4 I put the 1.14 repo of the central host offline, I make the central host's upgraded 2a repo up-to-date with the 1.14 repo (refresh each branch), I make this new repo online in place of the 1.14 repo

T5 devs cannot pull from the central 2a repo into their 1.14 repo (they get an error), but they can push to the central 2a repo. They thus have to move to using a local 2a repo: those who didn't act at T3 do the same steps as T3.

Alternative: if it is confusing for devs that at T3 they migrate branches but cannot use them yet, I could move T3 to T5.

Can you help with this problem?

Provide an answer of your own, or ask GuilhemBichot for more information if necessary.

To post a message you must log in.