$ hg log -r '1.8.2::1.8.3 and keyword(subrepo)'

changeset:   13912:71ea5b2b9517
branch:      stable
parent:      13905:08d49b6b8d32
user:        Thomas Arendsen Hein <thomas@intevation.de>
date:        Thu Apr 07 12:33:47 2011 +0200
summary:     subrepo: prevent url normalization from removing // in ssh
paths (issue2556)

http://www.selenic.com/hg/rev/71ea5b2b9517

I bet that is the culprit, but not sure what's going on here precisely.

Yes the problem is with this patch. I added following print statement just
after parent and return r and the result is:

lucck@lucckpc:/tmp$ hg clone ssh://hg@sserver/collector_app ee555454
requesting all changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 4 changes to 3 files
updating to branch default
parent ssh://hg@sserver/collector_app
r is ssh://hg@sserver//ollector_app/libisixdrv-stm32
parent ssh://hg@sserver/collector_app
r is ssh://hg@sserver//ollector_app/libisixdrv-stm32
parent ssh://hg@sserver/collector_app
r is ssh://hg@sserver//ollector_app/libisixdrv-stm32
pulling subrepo libisixdrv-stm32 from
ssh://hg@sserver//ollector_app/libisixdrv-stm32
remote: mercurial-server: absolute paths are not supported
abort: no suitable response from remote hg!

so it seems that parent var is ok but after conversion r has missing c
letter in the url

lucck, just to be sure that it works in the future, can you try it with the
default branch of Mercurial?

Besides that I'll look at the problem in stable.

I tried to build default branch and test it on the windows environment ( 
cygwin using python 2.5) and it seems to be working:

Lucck@LB /cygdrive/c/temp
$ ./mercurial-repo/hg -v
Mercurial Distributed SCM (version 1.8.3+58-3a90fb3addc1+20110505)
(see http://mercurial.selenic.com for more information)

$ ./mercurial-repo/hg clone ssh://hg@boff.pl:687/collector_app ca
requesting all changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 4 changes to 3 files
updating to branch default
pulling subrepo collector from ssh://hg@boff.pl:687/collector_app/collector
requesting all changes
adding changesets
adding manifests
adding file changes
added 92 changesets with 338 changes to 48 files
pulling subrepo isix from ssh://hg@boff.pl:687/collector_app/isix
requesting all changes
adding changesets
adding manifests
adding file changes
added 186 changesets with 726 changes to 120 files
pulling subrepo lib-stm32 from ssh://hg@boff.pl:687/collector_app/lib-stm32
requesting all changes
adding changesets
adding manifests
adding file changes
added 62 changesets with 132 changes to 57 files
pulling subrepo libfoundation from 
ssh://hg@boff.pl:687/collector_app/libfoundation
requesting all changes
adding changesets
adding manifests
adding file changes
added 38 changesets with 83 changes to 23 files
pulling subrepo libisixdrv-stm32 from 
ssh://hg@boff.pl:687/collector_app/libisixdrv-stm32
requesting all changes
adding changesets
adding manifests
adding file changes
added 18 changesets with 28 changes to 7 files
3 files updated, 0 files merged, 0 files removed, 0 files unresolved

Today evening I'll try to build on linux machine with python 2.7 and let you 
know.

I can't reproduce the problem with 1.8.3 and the current stable branch
(3a90fb3addc1) with Python 2.5.2 (Debian lenny), but I can reproduce it with
Python 2.6.6 (Debian squeeze).
(default branch works in both cases)

It seems I have to add a call to urlparse.urlunparse with known input to
detect which behavior should be used.

I suggest backporting a minimal part of Brodies URL handler. The solution
will only be used for one month anyway.

* Mads Kiilerich <bugs@mercurial.selenic.com> [20110505 15:05]:
> I suggest backporting a minimal part of Brodies URL handler. The solution
> will only be used for one month anyway.

I already tried this and it is not trivial, see msg15976 in
issue2556, therefore it might even be better to live with this bug
than introducing new problems in other areas.

IMO a simple copy&paste of the relevant parts would be acceptable for this
short-term solution.

A backout that fixes this issue and reintroduces issue2556 would also be OK.

I posted a simple patch for this:
http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/41016

Should I push it to stable (and do an empty merge to default)?

I tested default branch version 1.8.3+58-3a90fb3addc1 on the linux platform
ubuntu 11.04 (natty) with python 2.7.1 and it seems to be working. I tested
also on windows tortoiseHG version 2.0.3 work ok but version 2.0.4 doesn't work.

Oh. I forgot to post yesterday that I have pushed some tests to the default
branch that shows that it has been fixed correctly for 1.9.

Fixed by http://selenic.com/repo/hg/rev/7b627923739f
Thomas Arendsen Hein <thomas@intevation.de>
subrepo: use code from 71ea5b2b9517 only if Python needs it (issue2795)

(please test the fix)

* Mads Kiilerich <bugs@mercurial.selenic.com> [20110505 23:21]:
> Oh. I forgot to post yesterday that I have pushed some tests to the default
> branch that shows that it has been fixed correctly for 1.9.

Yes, thanks.

I noticed it and thought if I should port that to stable, too, but
dummyssh was not not yet used in this test and I did not want to
make too many changes in stable.

luuck, the fix is in the stable branch.
I'm pretty sure it works now, but can you confirm it on your installation
and then set this issue to resolved?

I just cloned the stable repo and tested it in our environment and the
problem is resolved. Many thanks for prompt response and fix.

Thanks for the test

--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:19 EDT  ---

This bug was previously known as _bug_ 2795 at http://mercurial.selenic.com/bts/issue2795