Cannot reproduce with a thg mercurial development build 1.4.2 + python25 +
pywin32 on Windows 2003 with Apache 2.2.11.

Sorry... I said nonsense.

Hardlinks ARE working. I have installed Link Shell Extension 
(http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html) and it 
displays .hg contents as HardLinks (red dot overlayed over the file icon).

Then, maybe the problem is that the CGI script treats directly some .hg file 
as a hardlink without making a local copy when things on only one repository 
change (making both repositories appear to change)? It works with internal web 
server, so the problem should be at the CGI code.

By the way, Mercurial never did a "fast local clone" in my systems.

The clones are slow to do (Windows XP), because they copy all the files. Maybe 
I am wrong, but I did not experience really a fast response from a clone 
operation. Can I test if my clones are using hardlinks with a --debug 
parameter?

Hi again,

I have tried hosting the testbug1 and testbug2 in a FAT32 partition. The local 
clones (clone1 and clone2 in the sample) are on a NTFS partition.

And guess what? IT WORKS!!!! (tested both with LightTPD + Apache)

So, the problem must be with (Python cgi script?) + NTFS.

Hi again,

I have just tested this same with LightTPD v1.4.25-1 (Win32) and the SAME 
happens... (exactly the same message after hg verify --verbose).

I used LightTPD with mod_cgi for using Python, as suggested here:
http://mercurial.selenic.com/wiki/HgWebDirStepByStep#Using_Apache_or_lighttpd_
with_the_hgwebdir.cgi_script

(my system is Windows XP, but the same configuration settings apply)

Best regards

Hi again,

My system is Windows XP SP3 + Apache 2.2.9, NTFS filesystem and no virtual 
systems involved.

However, I have just reproduced the bug within a clean Virtual Machine 
(VMWare) with Windows XP SP3 (+Net 3.5 SP1) + XAMP v1.7.3 (includes Apache 
2.2.14). This virtual machine is absolutely clean, I mean, no Antivirus, no 
other program appart from:
- Python v2.5.4
- Mercurial v1.4.2 (latest)

I have tested this also only with command line commands (no TortoiseHG) just 
in case. The problem is exactly the same.

This time Mercurial tells me (after an hg verify --verbose on testbug1):

repository uses revlog format 1
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
 data/file2.txt.i@1: missing revlog!
 1: empty or missing file2.txt
 file2.txt@1: 6a9e169d2b12 in manifests not found
2 files, 3 changesets, 1 total revisions
3 integrity errors encountered!
(first damaged changeset appears to be 1)

I have just installed a fresh copy of Windows XP SP3 slipstreamed on a NTFS 
formatted volume, then installed XAMP v1.7.3, then Python v2.5.4, then 
Mercurial v1.4.2 and followed the steps described in the first post.

Hope this helps...

--pull was not intended as a fix so much as a diagnostic step. But clearly
your problem is related to hardlinks. What filesystem are you using and are
any network filesystems or virtualization systems involved?

Yes! It works!

hg clone --pull

No more clone + push via web problems. Thank you!

For your info, I was doing the tests with a XP machine running Apache 2.2.9
server and the problem only surfaced once per clone (with a recovery on the
testbug1 repository all seemed to be ok again).

Anyway, thanks for your info.

Try repeating the test, using hg clone --pull to create testbug2

If this works, you've probably got an issue related to hardlinks (yes,
Windows does have hardlinks and Mercurial uses them for fast light local
clones). This might happen for instance if your webserver is reading your
repos from a NAS fileserver via SMB rather than CIFS.

I have just test with hgserve and it works well. So must be a problem with
hgwebdir.cgi somewhat (or my Apache configuration, which I hope not...).

I have not tested with hgweb.cgi alone. Should I?

Just one thing, I have also tested with mercurial library from previous
version (hgwebdir_mod.pyc dated 2/Aug/2009) and the same happens. For your
info, I have run this test with Mercurial v1.4 executables installed, so
maybe it is not a valid test.

I have Python 2.5.4 installed in C:\Python25
And uncompressed mercurial.zip file (using 7zip) bundled with Mercurial v1.4
installable into C:\Python25\Lib\mercurial

If I can help with some other tests, please let me know.

Yes, I am running an AV scanner. Bit Defender Internet Security 2010 to be
precise.

I switched off all the AV functions and followed the above steps.

Unfornately, it renders the same result (broken testbug1 repository after
pushing from clone2 to testbug2).

I also did the test with local clones (I mean, clone1+clone2 clone of
file:///....) and it worked well (as expected). I will test again with
hgserve, just to test if something is wrong with my computer. I will post
here the results in a few minutes.

Are you running a virus scanner on the machine hosting the repositories? If
so, which one, and could you try to disable it and redo the test scenario?

I cannot immediately reproduce it with using hg serve (instead of setting up
an apache server).

Adding hgweb-guys to the nosy list...

Sorry, forgot to add an step:

Between 6 and 7, hence it should be step 6.5 :-)

6.5) Create a clone with http of this new clone:
   clone2 (http://localhost/hg/Test/hgwebdir.cgi/bug2)

If you have one clone of a repository that has some changesets, then pushing
to that clone served with hgwebdir.cgi causes algo an incorrect push to the
parent repository, leaving it in a broken state (you have to do a recover on
parent repository)

Steps to reproduce:
System: Windows XP + Apache 2.2.9
Mercurial for Windows v1.4 + TortoiseHg v0.9

1) Create HG repository: testbug1

2) Configure hgwebdir.cgi to serve the repository as "bug1"
   [paths]
   bug1 = C:\HG\Test\testbug1

3) Create a clone with http:
   clone1 (http://localhost/hg/Test/hgwebdir.cgi/bug1)

4) On clone1:
   create File1.txt and commit
   try to push to "bug1" -> Error: SSL required
   goto testbug1 and set:
   --------------------------
   [web]
   push_ssl = False
   allow_push = *
   --------------------------
   try to push -> ok
   Go to hgwebdir.cgi page:
   * bug1 hg status -> changed (with previous changeset) --> OK

5) Create local clone of testbug1: testbug2 (but do not update working copy)

6) Configure hgwebdir.cgi to serve the new repository as "bug2"
   [paths]
   bug1 = C:\HG\Test\testbug1
   bug2 = C:\HG\Test\testbug2

7) On clone2:
   delete File1.txt, create File2.txt and commit
   try to push to "bug2" -> Error: SSL required
   goto testbug2 and set:
   --------------------------
   [web]
   push_ssl = False
   allow_push = *
   --------------------------
   try to push -> ok
   Go to hgwebdir.cgi page:
   * bug1 hg status -> changed (with previous changeset) --> NOT EXPECTED!
   * bug2 hg status -> changed (with previous changeset) --> OK

8) Running an hg verify --verbose of the testbug1 repository shows:

   data/File2.txt.i@1: missing revlog!
   1: empty or missing File2.txt
   File2.txt@1: 58931210a64d in manifests not found
   3 integrity errors encountered!
   (first damaged changeset appears to be 1)

9) testbug2 repository is ok


---------- WORKAROUND ----------

After clone2 push, inmediately do a RECOVER on testbug1 (all changes from
last "good push" are lost)

Go go clone1, and then push to testbug1 again to leave testbug1 as before

Now you can work as expected, commiting to clone2 and then pushing to
testbug2 does not "fall back incorrectly" to testbug1 repository


---------- FINAL REMARK ----------

This happens again if you create a new clone of the testbug1 repository. You
have to always apply the workaround

Attached is a ZIP file with the repositories at step 9 - without the recover
(testbug1 is broken)

(please note that paths are a little bit different, here I simplified the names)