Re: Upgrade repository format for trunk?

[Henrik Nordstrom]

fre 2010-03-26 klockan 12:18 +1300 skrev Amos Jeffries:

> FWIW, I've already upgraded my local repos months ago. There have been 
> no ill side effects from 2a here despite the source repo being 0.9.  If 
> you can it's worth doing the upgrade locally anyway even before the master.

How do you merge stuff back to the main repo from your upgraded one?

Or maybe merge works and just push/commit(bound) don't..?

Regards
Henrik

arm-debian build-host functional

[Kinkie]

Hi all,
  earlier today our new ARM-debian build-host failed its first build
:) (two failures in RFC1738, but apart from that everything seems to
be working)

As of now, it's not hooked to the main test-chain and it only tests
head. A full testsuite build on that host needs probably about 30
hours (!), but still it works and that's amazing enough.

The host is reachable only from eu, it only carries the root and
hudson accounts, both with the same password as the other hosts in the
build-farm.

Now to fix the failing tests.. :)
Next step, ppc.

-- 
/kinkie

Build failed in Hudson: 3.HEAD-i386-opensolaris-SunStudioCc #172

[noc]

See 


Changes:

[Automatic source maintenance ] SourceFormat 
Enforcement

--
[...truncated 4382 lines...]
make[3]: Leaving directory 
`
Making all in ntlm_auth
make[3]: Entering directory 
`
make[4]: Entering directory 
`
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory 
`
make[3]: Leaving directory 
`
Making all in url_rewrite
make[3]: Entering directory 
`
make[4]: Entering directory 
`
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory 
`
make[3]: Leaving directory 
`
make[3]: Entering directory 
`
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory 
`
make[2]: Leaving directory 
`
Making all in test-suite
make[2]: Entering directory 
`
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory 
`
Making all in tools
make[2]: Entering directory 
`
make[3]: Entering directory 
`
source='../../tools/squidclient.cc' object='squidclient.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/CC -DHAVE_CONFIG_H  -I../.. 
-I../../include -I../../src -I../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 -I../../tools-g -c -o 
squidclient.o ../../tools/squidclient.cc
source='../../tools/test_tools.cc' object='test_tools.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/CC -DHAVE_CONFIG_H  -I../.. 
-I../../include -I../../src -I../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 -I../../tools-g -c -o 
test_tools.o ../../tools/test_tools.cc
source='cachemgr.cc' object='cachemgr__CGIEXT_-cachemgr.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/CC -DHAVE_CONFIG_H  -I../.. 
-I../../include -I../../src -I../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 -I../../tools   
-DDEFAULT_CACHEMGR_CONFIG=\"
  -g -c -o cachemgr__CGIEXT_-cachemgr.o `test -f 'cachemgr.cc' || echo 
'../../tools/'`cachemgr.cc
source='test_tools.cc' object='cachemgr__CGIEXT_-test_tools.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/CC -DHAVE_CONFIG_H  -I../.. 
-I../../include -I../../src -I../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 -I../../tools   
-DDEFAULT_CACHEMGR_CONFIG=\"
  -g -c -o cachemgr__CGIE

Build failed in Hudson: 3.HEAD-i386-opensolaris-SunStudioCc #171

[noc]

See 


Changes:

[Automatic source maintenance ] SourceFormat 
Enforcement

[Amos Jeffries ] Compat: IPPROTO can;t be defined early 
for Linux.

Removed them again to uncover which OS actually need them. Add back as
needed to those specific OS compat headers.

[Amos Jeffries ] Compat: Shuffle final squid.h 
hacks into libcompat

[Amos Jeffries ] Compat: Several compile issues 
in Profiler and LeakFinder

[Francesco Chemolli ] Also check for SASL shared 
libreries in SASL helper configlet.

--
[...truncated 4423 lines...]
Making all in ntlm_auth
make[3]: Entering directory 
`
make[4]: Entering directory 
`
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory 
`
make[3]: Leaving directory 
`
Making all in url_rewrite
make[3]: Entering directory 
`
make[4]: Entering directory 
`
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory 
`
make[3]: Leaving directory 
`
make[3]: Entering directory 
`
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory 
`
make[2]: Leaving directory 
`
Making all in test-suite
make[2]: Entering directory 
`
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory 
`
Making all in tools
make[2]: Entering directory 
`
make[3]: Entering directory 
`
source='../../tools/squidclient.cc' object='squidclient.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/CC -DHAVE_CONFIG_H  -I../.. 
-I../../include -I../../src -I../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 -I../../tools-g -c -o 
squidclient.o ../../tools/squidclient.cc
source='../../tools/test_tools.cc' object='test_tools.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/CC -DHAVE_CONFIG_H  -I../.. 
-I../../include -I../../src -I../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 -I../../tools-g -c -o 
test_tools.o ../../tools/test_tools.cc
source='cachemgr.cc' object='cachemgr__CGIEXT_-cachemgr.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/CC -DHAVE_CONFIG_H  -I../.. 
-I../../include -I../../src -I../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 -I../../tools   
-DDEFAULT_CACHEMGR_CONFIG=\"
  -g -c -o cachemgr__CGIEXT_-cachemgr.o `test -f 'cachemgr.cc' || echo 
'../../tools/'`cachemgr.cc
source='test_tools.cc' object='cachemgr__CGIEXT_-test_tools.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/CC -DHAVE_CONFIG_H  -I../.. 
-I../../include -I../../src -I../include -I/usr/local/include 
-I/usr

Re: Upgrade repository format for trunk?

[Henrik Nordström]

tor 2010-03-25 klockan 15:29 -0600 skrev Alex Rousskov:

> Bzr folks are very good at making lots of releases but the world is
> apparently incapable of moving with the same speed!

Fedora keeps up.. but you then need to keep up with Fedora as well with
new full OS releases every 6 months..

> If nothing else, this will require instruction on how to upgrade the
> everyone repositories. I can support the upgrade once those instructions
> work for me :-).

1. Upgrade bzr to a supported release.

2. Anywhere in the repository, run "bzr upgrade" and go out for lunch.
Hopefully done when you come back, otherwise go directly to coffiebreak
until done..

Actually the 2 above is a little pessimistic. You can continue working
in an old repository just fine until the upgrade is done provided you do
the upgrade in a new path/location. Pushing from an old repository to 2a
works fine, only gets a little tricky if there is merges needing to be
done due to changes in both.. (you then need to push to a new branch in
2a and merge from there)

Regards
Henrik

Re: Upgrade repository format for trunk?

[Henrik Nordström]

tor 2010-03-25 klockan 18:01 +0100 skrev Kinkie:

> He didn't threaten any, but I didn't specifically ask for promises :)
> The worst I can think of is that it will mandate all developers to
> have halfway recent bzr installs.

2a will basically require bzr 1.18 or later to be useful iirc.

Upgrading to 2a is also a one-way path. Once you switch over to a
rich-root format there is no way back to the older format.

There is also no way to push/pull things from a 2a repository to older
non-rich versions, which means that when we switch over all developers
must also upgrade their repositories.

I still have some machines where bzr is not up to date for handling 2a
repositories.

> We need to backup it before, rolling back is then very easy.

Depends on when you need to roll back. See above.

but there is no risk of loosing the repository due to the upgrade
itself. There is an automatic backup done by the upgrade process.

> the 'bzr upgrade' process also does that automatically. During the
> upgrade the repository will be unavailable.

True, and takes an hour or so, at least last time I tried upgrading a
moderate squid repository to 2a. The main repository probably takes a
bit longer due to the wast amount of branches in there left over from
the CVS conversation.

Regards
Henrik

Re: Upgrade repository format for trunk?

[Matthew Morgan]

Alex Rousskov wrote:

On 03/25/2010 02:50 PM, Robert Collins wrote:
  

On Thu, 2010-03-25 at 10:40 -0600, Alex Rousskov wrote:


On 03/25/2010 10:06 AM, Kinkie wrote:
  

I've noticed that the bzr repository for trunk is based on an
ancient "pack-0.92" repo format.
After a few emails with Robert his recommendation is to upgrade the
repo format to format 2a .
Does anyone see any reason why this should not be done?


Has Robert promised no bad side-effects?
  

Everyone will *need* bzr 2.0.x, or newer. (2.1.0 recommended,
naturally). bzr has moved to a micro-release every month, so 2.0.0 is
now 7 months old.



Sigh. I would rather not upgrade then. I do not know how to move from
bzr 1.3 to bzr 2.0.x on Red Hat box that I have to use for some of the
development, and I doubt somebody here would enjoy educating me on that
process... Besides, even Ubuntu 9.10 only has bzr v2.0.2 by default.
Thus, we would be cutting it pretty close to bleeding edge for many.
  
There is an ubuntu ppa for more recent versions of bazaar here: 
https://launchpad.net/~bzr/+archive/ppa but it looks like they may be 
testing versions.  The description says the repo contains the " latest 
release or release candidate of bzr...".  It looks like it has bazaar 
2.1.0 for karmic, jaunty, intrepid, and hardy.  They don't list a build 
for lucid.

Bzr folks are very good at making lots of releases but the world is
apparently incapable of moving with the same speed!

  

2a is much more compact on disk, and faster across the board. But
everyone will need to upgrade their own repositories, which can take a
bit of time (or delete them and pull anew).



If nothing else, this will require instruction on how to upgrade the
everyone repositories. I can support the upgrade once those instructions
work for me :-).

Cheers,

Alex.