Re: BZR repository upgrade re-proposal.
I'm glad that a consensus is forming. The next question would then be who will perform the upgrade, and when - assuming noone speaks up against it. This friday? +1 :) +1. It seems that the schedule was missed. When is the next chance? Thanks, -- /kinkie
Re: BZR repository upgrade re-proposal.
sön 2012-09-09 klockan 19:15 +0200 skrev Kinkie: It seems that the schedule was missed. Yes. Been ill since friday. Combination of sleep deprivation and a cold taking it's poll. When is the next chance? Haven't seen any indications of any remaining reasons to not being able to switch. Wednesday maybe? Not feeling too alert tonight and should probably not do anything needing privileges, and monday tuesday is a bit choked already. Regards Henrik
Re: BZR repository upgrade re-proposal.
On Sun, Sep 9, 2012 at 9:36 PM, Henrik Nordström hen...@henriknordstrom.net wrote: sön 2012-09-09 klockan 19:15 +0200 skrev Kinkie: It seems that the schedule was missed. Yes. Been ill since friday. Combination of sleep deprivation and a cold taking it's poll. Sorry to hear that. Get well soon! When is the next chance? Haven't seen any indications of any remaining reasons to not being able to switch. Wednesday maybe? Not feeling too alert tonight and should probably not do anything needing privileges, and monday tuesday is a bit choked already. Sounds like a good plan. Thanks! -- /kinkie
Re: BZR repository upgrade re-proposal.
Okay, I'm glad that a consensus is forming. The next question would then be who will perform the upgrade, and when - assuming noone speaks up against it. Thanks -- /kinkie
Re: BZR repository upgrade re-proposal.
ons 2012-09-05 klockan 09:03 +0200 skrev Kinkie: I'm glad that a consensus is forming. The next question would then be who will perform the upgrade, and when - assuming noone speaks up against it. This friday? Regards Henrik
Re: BZR repository upgrade re-proposal.
On Wed, Sep 5, 2012 at 9:07 AM, Henrik Nordström hen...@henriknordstrom.net wrote: ons 2012-09-05 klockan 09:03 +0200 skrev Kinkie: I'm glad that a consensus is forming. The next question would then be who will perform the upgrade, and when - assuming noone speaks up against it. This friday? +1 :) -- /kinkie
Re: BZR repository upgrade re-proposal.
On 05.09.2012 20:23, Kinkie wrote: On Wed, Sep 5, 2012 at 9:07 AM, Henrik Nordström hen...@henriknordstrom.net wrote: ons 2012-09-05 klockan 09:03 +0200 skrev Kinkie: I'm glad that a consensus is forming. The next question would then be who will perform the upgrade, and when - assuming noone speaks up against it. This friday? +1 :) +1. Amos
Re: BZR repository upgrade re-proposal.
On Tue, Sep 4, 2012 at 2:25 AM, Henrik Nordström hen...@henriknordstrom.net wrote: tis 2012-09-04 klockan 11:41 +1200 skrev Amos Jeffries: There is also an alternative layout tree at /bzr/squid3-new-2a/ which flattens the tree to ../ trunk 3.0 3.1 3.2 getting rid of the CVS references and other legacy. Does this obsolete the CVS mirror completely? or do you mean that is all pushed into the mirror sub-directories system instead of the bzr repo? I did not mirror the CVS branches into squid3-new-2a. But trunk have full history as before. It is easy to copy over any additional branches if needed and the old repository will still be available to resurrect stuff from, only locked to prevent any accidental commits. What do you mean by other legacy? There is a bit of cruft that have been collecting in branches/ There likely also is some other active branches we want to keep like mswin. The new layout is only a suggestion picking the most obvious main branches. Okay. As long as we have a scheduled time and process how-to distributed I don't see any problems there. Agreed. Upgrading using a local shared repository is fairly quick (some minutes at most). Do we have administrative time to see this through before the 15th Sept? I will be wanting to branch 3.3 by the end of this month and it would make sense to deal with less branches in the migration. The actual switch is only two mv commands. If there is any persistent local bzr repositories in the build farm or anywhere else then those need to be verified 2a format. But I don't think we have any of those do we? There are, but I will take care of that; the most impact will be a failed build. Add a couple of symlinks and we can support both branches/ and the proposed flattened layout at the same time, minimizing the number of scripts and branch URLs that need updating. We can then successively phase out the branches/ URLs when we see fit. Great. I'm holding off the merge for a few days, I hope that this discussion will complete positively soon. Robert said on IRC that his suggestion is to upgrade. -- /kinkie
Re: BZR repository upgrade re-proposal.
On 09/04/2012 03:28 AM, Kinkie wrote: Great. I'm holding off the merge for a few days, I hope that this discussion will complete positively soon. IIRC, I was unhappy about the earlier upgrade proposal because bzr on older but still supported RHEL boxes did not support 2a at the time, and I did not want to tell folks to install bzr manually. RH seems to have migrated to newer bzr versions (I see bzr v2.1.1 or later) so I do not see any reason to delay the upgrade further. It would be nice to have specific instructions on how to update a local branch to support 2a. I see bzr upgrade command but it is not clear whether that is sufficient, especially with all the talk about two repositories (old and 2a). Thank you, Alex.
Re: BZR repository upgrade re-proposal.
tis 2012-09-04 klockan 11:00 -0600 skrev Alex Rousskov: It would be nice to have specific instructions on how to update a local branch to support 2a. I see bzr upgrade command but it is not clear whether that is sufficient, especially with all the talk about two repositories (old and 2a). upgrade is sufficient, but quite time consuming even if you only have one branch to upgrade as it needs to redo the complete history from revision 1. An alternative is to reuse the already upgraded repository to avoid upgrading past revisions already upgraded. This is done by using a shared repository (many branches sharing the same store) where you first create branches the already upgraded branches and then your branches. bzr init-repo squid-new cd squid-new bzr branch bzr+ssh://bzr.squid-cache.org/bzr/squid3/trunk bzr branch bzr+ssh://bzr.squid-cache.org/bzr/squid3/3.2 bzr branch bzr+ssh://bzr.squid-cache.org/bzr/squid3/3.1 bzr branch bzr+ssh://bzr.squid-cache.org/bzr/squid3/3.0 bzr branch /path/to/your/repo name [repeat for each branch] you need to reset push/pull locations etc after. you can rename/move things as you please, including a full rename of the main repository path (squid-new). the only requirement is that branches need to stay somewhere below the repository location. Regards Henrik
BZR repository upgrade re-proposal.
On 04.09.2012 00:13, Kinkie wrote: +1. this one looks better. If it is easy please commit the $Id$ changes separately so we get a cleaner protos.h change patch. But this is just wishful thinking, if its not easy you have my +1 for go-ahead anyway. Hi, I've hit a bit of a snag: due to the fact that the main repository is still in a very old format, there is no easy way to merge the branch while preserving the revision history (I'm trying the hard way, but failure is an option). Which leaves us with a choice: - upgrade main repository to format 2a (requires bzr 1.16+, circa 2009) - lose commit history for the merged branch (100 commits) and all subsequent launchpad-hosted branches :\ I'd clearly favor the first option, but I remember that the issue was already brought to the table and it was decided not to do it yet. Thanks, This is http://bugs.squid-cache.org/show_bug.cgi?id=3603 for the sysadmin TODO list. Can you add these details about history to the record there please. FWIW: I'm in favour of the upgrade, it is a large part of the build timeout issues on rio Debian sid build slave, it causes timeouts while converting the repo changes and/or downloading large portions of repo changeset data before for each test. It is also the reason I'm only working with patches as merge candidates these days. IIRC the objection was that 2a was relatively new at the time. A year on that should no longer be an issue. Amos
Re: BZR repository upgrade re-proposal.
tis 2012-09-04 klockan 10:56 +1200 skrev Amos Jeffries: FWIW: I'm in favour of the upgrade, it is a large part of the build timeout issues on rio Debian sid build slave, it causes timeouts while converting the repo changes and/or downloading large portions of repo changeset data before for each test. It is also the reason I'm only working with patches as merge candidates these days. Yes there is nothing holding back the upgrade to 2a repository format today. There is a 2a repository already prepared in /bzr/squid3-2a since some years back. It's not automatically pulling changes from /bzr/squid3 at the moment but is kept mostly up to date. There is also an alternative layout tree at /bzr/squid3-new-2a/ which flattens the tree to ../ trunk 3.0 3.1 3.2 getting rid of the CVS references and other legacy. Switching to squid3-2a is only a matter of switching the two folders. Switching to the alternative layout requires a bit more discussion as it has effects on branch URLS and our scripts. It is possible to add symlinks to allow both URL styles. Any local branches in old format needs upgrading as well. Due to the number of revisions i'd recommend setting up a 2a shared-repository from the already converted tree and branch your local old format trees into that for conversation. Regards Henrik
Re: BZR repository upgrade re-proposal.
On 04.09.2012 11:22, Henrik Nordström wrote: tis 2012-09-04 klockan 10:56 +1200 skrev Amos Jeffries: FWIW: I'm in favour of the upgrade, it is a large part of the build timeout issues on rio Debian sid build slave, it causes timeouts while converting the repo changes and/or downloading large portions of repo changeset data before for each test. It is also the reason I'm only working with patches as merge candidates these days. Yes there is nothing holding back the upgrade to 2a repository format today. There is a 2a repository already prepared in /bzr/squid3-2a since some years back. It's not automatically pulling changes from /bzr/squid3 at the moment but is kept mostly up to date. There is also an alternative layout tree at /bzr/squid3-new-2a/ which flattens the tree to ../ trunk 3.0 3.1 3.2 getting rid of the CVS references and other legacy. Does this obsolete the CVS mirror completely? or do you mean that is all pushed into the mirror sub-directories system instead of the bzr repo? What do you mean by other legacy? Switching to squid3-2a is only a matter of switching the two folders. Switching to the alternative layout requires a bit more discussion as it has effects on branch URLS and our scripts. It is possible to add symlinks to allow both URL styles. I think that flattening is a good idea. Any local branches in old format needs upgrading as well. Due to the number of revisions i'd recommend setting up a 2a shared-repository from the already converted tree and branch your local old format trees into that for conversation. Okay. As long as we have a scheduled time and process how-to distributed I don't see any problems there. Do we have administrative time to see this through before the 15th Sept? I will be wanting to branch 3.3 by the end of this month and it would make sense to deal with less branches in the migration. Amos
