Checkin gives error "abort: There is no Mercurial repository here (.hg not found)!" on TortoiseHg/Windows version
jens...@nordea.com
Hi
I have come across an error where checking in a large binary file gives
me the error message "abort: There is no Mercurial repository here (.hg
not found)!" when I am clearly in the right directory.
I am reproducing this on Windows with the hg command line program from
the TortoiseHg installer under Cygwin. I cannot reproduce the problem
under Linux with neither version 1.1.2 or version
1.3.1+295-1de5ebfa5585. The simplest case I have been able to come up
with involves two versions of the same file, where the second checkin
fails:
$ ls -la
total 87945
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 11:23 .
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 11:00 ..
-rwxr-xr-x 1 g36565 mkgroup-l-d 291 Nov 5 15:14 dotest.sh
-rw-r--r-- 1 g36565 mkgroup-l-d 45023744 Nov 5 14:27 sleipner_1.xls
-rw-r--r-- 1 g36565 mkgroup-l-d 45025792 Nov 5 14:28 sleipner_2.xls
$ cat dotest.sh
#!/usr/bin/sh
echo "Version info:"
hg version
echo "Init repo:"
hg init
cp sleipner_1.xls sleipner.xls
echo "Add file:"
hg add sleipner.xls
echo "Checkin first version:"
hg ci -m "First version"
cp sleipner_2.xls sleipner.xls
echo "Checkin second version:"
hg ci -m "Second version, fails!"
$ ./dotest.sh
Version info:
Mercurial Distributed SCM (version 1.3.1)
Copyright (C) 2005-2009 Matt Mackall <m...@selenic.com> and others
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
Init repo:
Add file:
sleipner.xls: files over 10MB may cause memory and performance problems
(use 'hg revert sleipner.xls' to unadd the file)
Checkin first version:
Checkin second version:
abort: There is no Mercurial repository here (.hg not found)!
There is clearly something specific with the two versions of this file.
Unfortunately I cannot give the two files away as they are confidential.
(I might consider sending them to a few interested developers.) I cannot
reproduce the problem with random binary files of similar size (read
from /dev/random).
Any ideas?
Best regards, Jens
--
Jens Lund
Nordea Markets
Product Development
Ph. (+45) 33 33 55 54
E-mail: jens...@nordea.com
This transmission is intended solely for the person or entity to whom it
is addressed. It may contain privileged and confidential information. If
you are not the intended recipient, please be notified that any
dissemination, distribution or copying is strictly prohibited. If you
have received this transmission by mistake, please let us know and then
delete it from your system.
_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial
Benoit Boissinot
>
> Hi
>
> I have come across an error where checking in a large binary file gives
> me the error message "abort: There is no Mercurial repository here (.hg
> not found)!" when I am clearly in the right directory.
>
> I am reproducing this on Windows with the hg command line program from
> the TortoiseHg installer under Cygwin. I cannot reproduce the problem
> under Linux with neither version 1.1.2 or version
> 1.3.1+295-1de5ebfa5585. The simplest case I have been able to come up
> with involves two versions of the same file, where the second checkin
> fails:
> $ cat dotest.sh
> #!/usr/bin/sh
> echo "Version info:"
> hg version
> echo "Init repo:"
> hg init
> cp sleipner_1.xls sleipner.xls
> echo "Add file:"
> hg add sleipner.xls
> echo "Checkin first version:"
> hg ci -m "First version"
> cp sleipner_2.xls sleipner.xls
> echo "Checkin second version:"
> hg ci -m "Second version, fails!"
Does `hg root` works here?
--
:wq
jens...@nordea.com
Yes:
g36565@dkd1ws0030 ~/tmp/othertest/hgtest
$ hg root
v:\tmp\othertest\hgtest
Note, the first checkin works fine. I can check in other files fine as
well.
Jens
Benoit Boissinot
Ok, does hg --traceback give more information then?
regards,
Benoit
--
:wq
jens...@nordea.com
A bit more:
g36565@dkd1ws0030 ~/tmp/othertest/hgtest
$ hg --traceback ci -m "Second version, fails"
Traceback (most recent call last):
File "mercurial\dispatch.pyc", line 43, in _runcatch
File "mercurial\dispatch.pyc", line 441, in _dispatch
RepoError: There is no Mercurial repository here (.hg not found)
abort: There is no Mercurial repository here (.hg not found)!
Jens
Matt Mackall
> > From: Benoit Boissinot [mailto:benoit.b...@ens-lyon.org]
> > Ok, does hg --traceback give more information then?
>
> A bit more:
>
> g36565@dkd1ws0030 ~/tmp/othertest/hgtest
> $ hg --traceback ci -m "Second version, fails"
> Traceback (most recent call last):
> File "mercurial\dispatch.pyc", line 43, in _runcatch
> File "mercurial\dispatch.pyc", line 441, in _dispatch
> RepoError: There is no Mercurial repository here (.hg not found)
> abort: There is no Mercurial repository here (.hg not found)!
Wow, that's broken.
What's happening is that when we're creating the repository object, it's
reporting a repository error (probably something like "interrupted
transaction") and we're swallowing that error and trying to guess where
the repo is. This all happens way before we even attempt the actual
second commit. So I would expect a bunch of other commands to also be
broken (status, parents, etc.).
What files are in your .hg directory?
--
http://selenic.com : development and support for Mercurial and Linux
jens...@nordea.com
> > > From: Benoit Boissinot [mailto:benoit.b...@ens-lyon.org]
> > > Ok, does hg --traceback give more information then?
> >
> > A bit more:
> >
> > g36565@dkd1ws0030 ~/tmp/othertest/hgtest
> > $ hg --traceback ci -m "Second version, fails"
> > Traceback (most recent call last):
> > File "mercurial\dispatch.pyc", line 43, in _runcatch
> > File "mercurial\dispatch.pyc", line 441, in _dispatch
> > RepoError: There is no Mercurial repository here (.hg not found)
> > abort: There is no Mercurial repository here (.hg not found)!
>
> Wow, that's broken.
>
> What's happening is that when we're creating the repository
> object, it's
> reporting a repository error (probably something like "interrupted
> transaction") and we're swallowing that error and trying to
> guess where
> the repo is. This all happens way before we even attempt the actual
> second commit. So I would expect a bunch of other commands to also be
> broken (status, parents, etc.).
>
> What files are in your .hg directory?
Just before the second failing commit:
g36565@dkd1ws0030 ~/tmp/othertest/hgtest
$ hg st
M sleipner.xls
? dotest.sh
? sleipner_1.xls
? sleipner_2.xls
g36565@dkd1ws0030 ~/tmp/othertest/hgtest
$ hg parents
changeset: 0:0a6b669a4147
tag: tip
user: Jens Lund <jens...@nordea.com>
date: Fri Nov 06 15:51:40 2009 +0100
summary: First commit
g36565@dkd1ws0030 ~/tmp/othertest/hgtest
$ ls -laR
.:
total 131917
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 .
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:49 ..
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 .hg
-rwxr-xr-x 1 g36565 mkgroup-l-d 291 Nov 5 15:14 dotest.sh
-rw-r--r-- 1 g36565 mkgroup-l-d 45025792 Nov 6 15:51 sleipner.xls
-rw-r--r-- 1 g36565 mkgroup-l-d 45023744 Nov 5 14:27 sleipner_1.xls
-rw-r--r-- 1 g36565 mkgroup-l-d 45025792 Nov 5 14:28 sleipner_2.xls
./.hg:
total 5
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 .
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 ..
-rw-r--r-- 1 g36565 mkgroup-l-d 57 Nov 6 15:50 00changelog.i
-rw-r--r-- 1 g36565 mkgroup-l-d 69 Nov 6 15:51 dirstate
-rw-r--r-- 1 g36565 mkgroup-l-d 23 Nov 6 15:50 requires
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 store
-rw-r--r-- 1 g36565 mkgroup-l-d 7 Nov 6 15:51 undo.branch
-rw-r--r-- 1 g36565 mkgroup-l-d 69 Nov 6 15:51 undo.dirstate
./.hg/store:
total 4
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 .
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 ..
-rw-r--r-- 1 g36565 mkgroup-l-d 179 Nov 6 15:51 00changelog.i
-rw-r--r-- 1 g36565 mkgroup-l-d 119 Nov 6 15:51 00manifest.i
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 data
-rw-r--r-- 1 g36565 mkgroup-l-d 60 Nov 6 15:51 fncache
-rw-r--r-- 1 g36565 mkgroup-l-d 102 Nov 6 15:51 undo
./.hg/store/data:
total 6653
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 .
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 ..
-rw-r--r-- 1 g36565 mkgroup-l-d 6811410 Nov 6 15:51 sleipner.xls.d
-rw-r--r-- 1 g36565 mkgroup-l-d 64 Nov 6 15:51 sleipner.xls.i
Now trying to do the second commit:
g36565@dkd1ws0030 ~/tmp/othertest/hgtest
$ hg ci -m "Second version, fails"
abort: There is no Mercurial repository here (.hg not found)!
and after the failed commit, before any recover operation:
g36565@dkd1ws0030 ~/tmp/othertest/hgtest
$ hg st
M sleipner.xls
? dotest.sh
? sleipner_1.xls
? sleipner_2.xls
g36565@dkd1ws0030 ~/tmp/othertest/hgtest
$ hg parents
changeset: 0:0a6b669a4147
tag: tip
user: Jens Lund <jens...@nordea.com>
date: Fri Nov 06 15:51:40 2009 +0100
summary: First commit
g36565@dkd1ws0030 ~/tmp/othertest/hgtest
$ ls -laR
.:
total 131917
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 .
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:49 ..
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:54 .hg
-rwxr-xr-x 1 g36565 mkgroup-l-d 291 Nov 5 15:14 dotest.sh
-rw-r--r-- 1 g36565 mkgroup-l-d 45025792 Nov 6 15:51 sleipner.xls
-rw-r--r-- 1 g36565 mkgroup-l-d 45023744 Nov 5 14:27 sleipner_1.xls
-rw-r--r-- 1 g36565 mkgroup-l-d 45025792 Nov 5 14:28 sleipner_2.xls
./.hg:
total 8
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:54 .
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 ..
-rw-r--r-- 1 g36565 mkgroup-l-d 57 Nov 6 15:50 00changelog.i
-rw-r--r-- 1 g36565 mkgroup-l-d 69 Nov 6 15:51 dirstate
-rw-r--r-- 1 g36565 mkgroup-l-d 7 Nov 6 15:54 journal.branch
-rw-r--r-- 1 g36565 mkgroup-l-d 69 Nov 6 15:54 journal.dirstate
-rw-r--r-- 1 g36565 mkgroup-l-d 23 Nov 6 15:50 requires
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:54 store
-rw-r--r-- 1 g36565 mkgroup-l-d 7 Nov 6 15:51 undo.branch
-rw-r--r-- 1 g36565 mkgroup-l-d 69 Nov 6 15:51 undo.dirstate
-rw-r--r-- 1 g36565 mkgroup-l-d 15 Nov 6 15:54 wlock
./.hg/store:
total 5
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:54 .
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:54 ..
-rw-r--r-- 1 g36565 mkgroup-l-d 179 Nov 6 15:51 00changelog.i
-rw-r--r-- 1 g36565 mkgroup-l-d 119 Nov 6 15:51 00manifest.i
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 data
-rw-r--r-- 1 g36565 mkgroup-l-d 60 Nov 6 15:51 fncache
-rw-r--r-- 1 g36565 mkgroup-l-d 0 Nov 6 15:54 journal
-rw-r--r-- 1 g36565 mkgroup-l-d 15 Nov 6 15:54 lock
-rw-r--r-- 1 g36565 mkgroup-l-d 102 Nov 6 15:51 undo
./.hg/store/data:
total 6653
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 .
drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:54 ..
-rw-r--r-- 1 g36565 mkgroup-l-d 6811410 Nov 6 15:51 sleipner.xls.d
-rw-r--r-- 1 g36565 mkgroup-l-d 64 Nov 6 15:51 sleipner.xls.i
Jens
Matt Mackall
> > From: Matt Mackall [mailto:m...@selenic.com]
> > On Fri, 2009-11-06 at 15:23 +0100, jens...@nordea.com wrote:
> > > > From: Benoit Boissinot [mailto:benoit.b...@ens-lyon.org]
> > > > Ok, does hg --traceback give more information then?
> > >
> > > A bit more:
> > >
> > > g36565@dkd1ws0030 ~/tmp/othertest/hgtest
> > > $ hg --traceback ci -m "Second version, fails"
> > > Traceback (most recent call last):
> > > File "mercurial\dispatch.pyc", line 43, in _runcatch
> > > File "mercurial\dispatch.pyc", line 441, in _dispatch
> > > RepoError: There is no Mercurial repository here (.hg not found)
> > > abort: There is no Mercurial repository here (.hg not found)!
> >
> > Wow, that's broken.
> >
> > What's happening is that when we're creating the repository
> > object, it's
> > reporting a repository error (probably something like "interrupted
> > transaction") and we're swallowing that error and trying to
> > guess where
> > the repo is. This all happens way before we even attempt the actual
> > second commit. So I would expect a bunch of other commands to also be
> > broken (status, parents, etc.).
> >
> > What files are in your .hg directory?
>
> total 8
> drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:54 .
> drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 ..
> -rw-r--r-- 1 g36565 mkgroup-l-d 57 Nov 6 15:50 00changelog.i
> -rw-r--r-- 1 g36565 mkgroup-l-d 69 Nov 6 15:51 dirstate
> -rw-r--r-- 1 g36565 mkgroup-l-d 7 Nov 6 15:54 journal.branch
> -rw-r--r-- 1 g36565 mkgroup-l-d 69 Nov 6 15:54 journal.dirstate
> -rw-r--r-- 1 g36565 mkgroup-l-d 23 Nov 6 15:50 requires
> drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:54 store
> -rw-r--r-- 1 g36565 mkgroup-l-d 7 Nov 6 15:51 undo.branch
> -rw-r--r-- 1 g36565 mkgroup-l-d 69 Nov 6 15:51 undo.dirstate
> -rw-r--r-- 1 g36565 mkgroup-l-d 15 Nov 6 15:54 wlock
Hmm, a journal's getting created, but that shouldn't cause a problem
until much later. Your traceback indicates we're running into problems
quite early. It looks like the things that can cause an early bailout
are:
- repo not found (are you doing something interesting with shared
filesystems?)
- unexpected things in your requires file (can you send that?)
- unreachable shared path (doesn't apply)
- something interesting in an extension (using any?)
You might also try this patch:
diff -r ca24c862d915 mercurial/dispatch.py
--- a/mercurial/dispatch.py Sat Oct 17 14:00:41 2009 -0400
+++ b/mercurial/dispatch.py Fri Nov 06 10:11:59 2009 -0600
@@ -431,6 +431,7 @@
ui.setconfig("bundle", "mainreporoot", repo.root)
except error.RepoError:
if cmd not in commands.optionalrepo.split():
+ raise
if args and not path: # try to infer -R from command args
repos = map(_findrepo, args)
guess = repos[0]
--
http://selenic.com : development and support for Mercurial and Linux
jens...@nordea.com
> On Fri, 2009-11-06 at 15:56 +0100, jens...@nordea.com wrote:
> > > From: Matt Mackall [mailto:m...@selenic.com]
> >
> > ./.hg:
> > total 8
> > drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:54 .
> > drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:51 ..
> > -rw-r--r-- 1 g36565 mkgroup-l-d 57 Nov 6 15:50 00changelog.i
> > -rw-r--r-- 1 g36565 mkgroup-l-d 69 Nov 6 15:51 dirstate
> > -rw-r--r-- 1 g36565 mkgroup-l-d 7 Nov 6 15:54 journal.branch
> > -rw-r--r-- 1 g36565 mkgroup-l-d 69 Nov 6 15:54 journal.dirstate
> > -rw-r--r-- 1 g36565 mkgroup-l-d 23 Nov 6 15:50 requires
> > drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 15:54 store
> > -rw-r--r-- 1 g36565 mkgroup-l-d 7 Nov 6 15:51 undo.branch
> > -rw-r--r-- 1 g36565 mkgroup-l-d 69 Nov 6 15:51 undo.dirstate
> > -rw-r--r-- 1 g36565 mkgroup-l-d 15 Nov 6 15:54 wlock
>
> Hmm, a journal's getting created, but that shouldn't cause a problem
> until much later. Your traceback indicates we're running into problems
> quite early. It looks like the things that can cause an early bailout
> are:
>
> - repo not found (are you doing something interesting with shared
> filesystems?)
No, this fails on both network drives and the local harddrive. It is
however running in a Cygwin bash shell (running the TortoiseHg cmd line
program, not the Cygwing hg), so I guess there is something going on in
the disk access in the Cygwin layer. Trying from the explorer right
click menu using the Tortoise diaglogs results in a "silent" crash on
the second commit, which is not successful.
> - unexpected things in your requires file (can you send that?)
$ cat .hg/requires
revlogv1
store
fncache
> - unreachable shared path (doesn't apply)
> - something interesting in an extension (using any?)
Not really anything out of the ordinary:
$ cat $HOME/.hgrc
[ui]
username = Jens Lund <jens...@nordea.com>
[extensions]
hgext.graphlog =
hgext.extdiff =
hgext.hgk =
hgext.bookmarks =
transplant =
[extdiff]
cmd.kdiff = kdiff3
> You might also try this patch:
I am a bit in doubt here. As far as I can see, the TortoiseHg installer
only contains the compiled pyc files in library.zip, and not the "raw"
Python files? Am I looking in the correct place? In order to
nevertheless try the patch I installed the Cygwin version of hg --- that
one does not fail (which I suppose is somewhat consistent with it not
failing on Linux either). Thus specific to the TortoiseHg installer.
(Haven't tried the plain Windows installer.)
Jens
jens...@nordea.com
Hi
Does the further information below help giving anybody any clues that
can help me solving my problem, where the second of two commits fail on
Windows with the TortoiseHg installer?
Any other ideas as to in which direction to look for a solution?
Jens
> No, this fails on both network drives and the local
> harddrive. It is however running in a Cygwin bash shell
> (running the TortoiseHg cmd line program, not the Cygwing
> hg), so I guess there is something going on in the disk
> access in the Cygwin layer. Trying from the explorer right
> click menu using the Tortoise diaglogs results in a "silent"
> crash on the second commit, which is not successful.
>
> > - unexpected things in your requires file (can you send that?)
>
> $ cat .hg/requires
> revlogv1
> store
> fncache
>
> > - unreachable shared path (doesn't apply)
> > - something interesting in an extension (using any?)
>
> Not really anything out of the ordinary:
>
> $ cat $HOME/.hgrc
> [ui]
> username = Jens Lund <jens...@nordea.com>
>
> [extensions]
> hgext.graphlog =
> hgext.extdiff =
> hgext.hgk =
> hgext.bookmarks =
>
> transplant =
>
> [extdiff]
> cmd.kdiff = kdiff3
>
> > You might also try this patch:
>
> I am a bit in doubt here. As far as I can see, the TortoiseHg
> installer only contains the compiled pyc files in
> library.zip, and not the "raw" Python files? Am I looking in
> the correct place? In order to nevertheless try the patch I
> installed the Cygwin version of hg --- that one does not fail
> (which I suppose is somewhat consistent with it not failing
> on Linux either). Thus specific to the TortoiseHg installer.
> (Haven't tried the plain Windows installer.)
>
> Jens
>
Benoit Boissinot
>
> Hi
>
> Does the further information below help giving anybody any clues that
> can help me solving my problem, where the second of two commits fail on
> Windows with the TortoiseHg installer?
>
> Any other ideas as to in which direction to look for a solution?
Maybe one more question, do you use a file scanner, anti-virus, or
something similar?
regards,
Benoit
--
:wq
jens...@nordea.com
> something similar?
Yes, Symantec Antivirus.
Jens
Matt Mackall
> > From: Benoit Boissinot [mailto:benoit.b...@ens-lyon.org]
> > Maybe one more question, do you use a file scanner, anti-virus, or
> > something similar?
>
> Yes, Symantec Antivirus.
If possible, try your test with antivirus disabled.
--
http://selenic.com : development and support for Mercurial and Linux
jens...@nordea.com
I couldn't turn of anti-virus on my work computers, and I don't have
windows at home. However, heading over to a friend with a Windows
computer without anti-virus software revealed that the problem is still
present without any virus software.
On the good side, this same friend could also help me figure out that
the problem seem to be gone in the upcomming 1.4 release on Monday.
I will retest ASAP the new release comes out and report back.
Jens
jens...@nordea.com
The problem below is still present in hg 1.4/TortoiseHg ver 0.9 :-(
Summary of discussion so far in this thread:
* Running with traceback:
$ hg --traceback ci -m second
Traceback (most recent call last):
File "mercurial\dispatch.pyo", line 46, in _runcatch
File "mercurial\dispatch.pyo", line 441, in _dispatch
RepoError: There is no Mercurial repository here (.hg not found)
abort: There is no Mercurial repository here (.hg not found)!
* It doesn't seem to be related to anti-virus software or similar
running on the computer
* It only happens for the TortoiseHg installed version, not the cygwin
version.
* It fails both on network drives and local drives
Jens
> -----Original Message-----
> From: Lund, Jens
> Sent: Friday, November 06, 2009 11:38 AM
> To: 'merc...@selenic.com'
> Subject: Checkin gives error "abort: There is no Mercurial
> repository here (.hg not found)!" on TortoiseHg/Windows version
>
>
> Hi
>
> I have come across an error where checking in a large binary
> file gives me the error message "abort: There is no Mercurial
> repository here (.hg not found)!" when I am clearly in the
> right directory.
>
> I am reproducing this on Windows with the hg command line
> program from the TortoiseHg installer under Cygwin. I cannot
> reproduce the problem under Linux with neither version 1.1.2
> or version 1.3.1+295-1de5ebfa5585. The simplest case I have
> been able to come up with involves two versions of the same
> file, where the second checkin fails:
>
> $ ls -la
> total 87945
> drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 11:23 .
> drwxr-xr-x 1 g36565 mkgroup-l-d 0 Nov 6 11:00 ..
> -rwxr-xr-x 1 g36565 mkgroup-l-d 291 Nov 5 15:14 dotest.sh
> -rw-r--r-- 1 g36565 mkgroup-l-d 45023744 Nov 5 14:27 sleipner_1.xls
> -rw-r--r-- 1 g36565 mkgroup-l-d 45025792 Nov 5 14:28 sleipner_2.xls
>
> $ cat dotest.sh
> #!/usr/bin/sh
> echo "Version info:"
> hg version
> echo "Init repo:"
> hg init
> cp sleipner_1.xls sleipner.xls
> echo "Add file:"
> hg add sleipner.xls
> echo "Checkin first version:"
> hg ci -m "First version"
> cp sleipner_2.xls sleipner.xls
> echo "Checkin second version:"
> hg ci -m "Second version, fails!"
>
> $ ./dotest.sh
> Version info:
> Mercurial Distributed SCM (version 1.3.1)
>
> Copyright (C) 2005-2009 Matt Mackall <m...@selenic.com> and others
> This is free software; see the source for copying conditions.
> There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> Init repo:
> Add file:
> sleipner.xls: files over 10MB may cause memory and
> performance problems
> (use 'hg revert sleipner.xls' to unadd the file)
> Checkin first version:
> Checkin second version:
> abort: There is no Mercurial repository here (.hg not found)!
>
> There is clearly something specific with the two versions of
> this file. Unfortunately I cannot give the two files away as
> they are confidential. (I might consider sending them to a
> few interested developers.) I cannot reproduce the problem
> with random binary files of similar size (read from /dev/random).
>
> Any ideas?
>
> Best regards, Jens
>
> --
> Jens Lund
> Nordea Markets
> Product Development
> Ph. (+45) 33 33 55 54
> E-mail: jens...@nordea.com
>
> This transmission is intended solely for the person or entity
> to whom it is addressed. It may contain privileged and
> confidential information. If you are not the intended
> recipient, please be notified that any dissemination,
> distribution or copying is strictly prohibited. If you have
> received this transmission by mistake, please let us know and
> then delete it from your system.
>
Steve Borho
>
> The problem below is still present in hg 1.4/TortoiseHg ver 0.9 :-(
>
> Summary of discussion so far in this thread:
>
> * Running with traceback:
> $ hg --traceback ci -m second
> Traceback (most recent call last):
> File "mercurial\dispatch.pyo", line 46, in _runcatch
> File "mercurial\dispatch.pyo", line 441, in _dispatch
> RepoError: There is no Mercurial repository here (.hg not found)
> abort: There is no Mercurial repository here (.hg not found)!
>
> * It doesn't seem to be related to anti-virus software or similar
> running on the computer
>
> * It only happens for the TortoiseHg installed version, not the cygwin
> version.
>
> * It fails both on network drives and local drives
That is quite strange. It's likely this will not be fixed until it
can be reproduced by an appropriate developer. Barring that, you may
want to try:
hg --debugger ci -m second
Single step through the failure, write the output to a file, zip it
up, then post a link here or attach it to a bug report.
--
Steve Borho
jens...@nordea.com
> >
> > The problem below is still present in hg 1.4/TortoiseHg ver 0.9 :-(
> > $ hg --traceback ci -m second
> > Traceback (most recent call last):
> > File "mercurial\dispatch.pyo", line 46, in _runcatch
> > File "mercurial\dispatch.pyo", line 441, in _dispatch
> > RepoError: There is no Mercurial repository here (.hg not found)
> > abort: There is no Mercurial repository here (.hg not found)!
> That is quite strange. It's likely this will not be fixed until it
> can be reproduced by an appropriate developer.
Unfortunately, I cannot post the two versions of the file in public. However, as stated in my original mail I can probably send them to a few selected developers if anybody shows interest. So far, that has only been a fried om mine here in Denmark that happens to work at a company where they use Mercurial quite a lot.
> you may want to try:
> hg --debugger ci -m second
Hmm, that just seems to hang.
Jens
Martin Geisler
>> From: Steve Borho [mailto:st...@borho.org]
>> On Tue, Nov 17, 2009 at 5:50 AM, <jens...@nordea.com> wrote:
>> >
>> > The problem below is still present in hg 1.4/TortoiseHg ver 0.9 :-(
>> > * Running with traceback:
>> > $ hg --traceback ci -m second
>> > Traceback (most recent call last):
>> > File "mercurial\dispatch.pyo", line 46, in _runcatch
>> > File "mercurial\dispatch.pyo", line 441, in _dispatch
>> > RepoError: There is no Mercurial repository here (.hg not found)
>> > abort: There is no Mercurial repository here (.hg not found)!
>
>> That is quite strange. It's likely this will not be fixed until it
>> can be reproduced by an appropriate developer.
>
> Unfortunately, I cannot post the two versions of the file in public.
> However, as stated in my original mail I can probably send them to a
> few selected developers if anybody shows interest.
I've Cc'ed a number of other Danish Mercurial developers and users, some
of which use Windows (at least in their day-job). I hope one of them can
try to reproduce the problem.
> So far, that has only been a fried om mine here in Denmark that
> happens to work at a company where they use Mercurial quite a lot.
Cool -- we have talked about meeting for a Mercurial-fun-hacking-day
somewhere in Copenhagen on December the 5th or 6th. Sune and Henrik
should know more about it.
--
Martin Geisler
VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
Sune Foldager
> I've Cc'ed a number of other Danish Mercurial developers and users, some
> of which use Windows (at least in their day-job). I hope one of them can
> try to reproduce the problem.
I'd be happy to try, but I am gonna need some more context from someone :-p.
/Sune