In main repo now.

Fix pushed to crew

I have solution 2) ready, it seems to work fine.
Now I'm working on 3) which is almost ready.

restored new title

On Sat, 2006-03-04 at 07:36 +0000, Thomas Arendsen Hein wrote:

> Ah, this explains it, and I'm glad that you found it, because this might screw
> up repository conversions between revlog formats or in the future for filename
> encodings (e.g. for case insensitive fs).

Yes, it's kind of an exciting bug.  It would have had some interesting
possibilities :-)

> Another option would be to create a repo ui object from scratch which passes
> unknown requests to the global ui object.

That would make sense.

> P.S.: bos, I added you to the nosy list because this roundup isn't configured to
> add people to it when commenting.

Thank you!

	<b

changed the title to state the real problem

Ah, this explains it, and I'm glad that you found it, because this might screw
up repository conversions between revlog formats or in the future for filename
encodings (e.g. for case insensitive fs).

Another option would be to create a repo ui object from scratch which passes
unknown requests to the global ui object.

P.S.: bos, I added you to the nosy list because this roundup isn't configured to
add people to it when commenting.

I looked into this.

What's happening is that the push from 3 to 2 triggers 2's changegroup hook as
it should.

But when 2 does the push to 1, it uses the same ui object to construct the
localrepository object for 1.  So thre config dict for that ui gets updated with
1's config.  This means that any of 2's hooks not overridden by 1 get applied
again in 1.

So when the push from 2 to 1 happens, the ui object in 1 contains 2's config,
overridden by 1's config.  Afterwards, when execution continues in 2, it
contains 1's config, overriding 2's config.

If someone were to script something together in a single Python process that did
multiple operations, this could bite them in potentially nasty ways.

Of course, this problem only affects pushes and pulls through the local filesystem.

The solution is for the global and per-repo hgrc data to not be read into a
single dict.  Instead, you could

1) keep global hgrc data in one dict, and per-repo in another.  Look up the
per-repo first, then the global.

2) keep global hgrc data in a dict, copy and update it for each repo when
reading .hg/hgrc.

Option 2 is probably faster and simpler.

Here is a script to reproduce the issue

I have 2 machines and 3 repositories:
machine A, machine B, repository A1, B1 and B2
I push from A1 to B1 through ssh. B1 has a changegroup hook which pushes to B2.

When I initiate the push from A1 to B1, the push freezes. If I interrupt it, and
verify the content of the various repositories, each repository seem to have
been updated. There is a stale lock in B2/.hg/lock

Thomas said he could reproduce it with 0.8