Checkin gives error "abort: There is no Mercurial repository here (.hg not found)!" on TortoiseHg/Windows version

[jens.lund]

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 <mpm@...> 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. ([phone]
E-mail: jens.lund@...

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
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Benoit Boissinot]

On Fri, Nov 06, 2009 at 11:38:12AM +0100, jens.lund@... wrote:

>
> 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
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[jens.lund]

> -----Original Message-----
> From: Benoit Boissinot [mailto:benoit.boissinot@...]
> On Fri, Nov 06, 2009 at 11:38:12AM +0100, jens.lund@... wrote:
> >
> > 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?

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

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Benoit Boissinot]

On Fri, Nov 06, 2009 at 01:55:41PM +0100, jens.lund@... wrote:

> > -----Original Message-----
> > From: Benoit Boissinot [mailto:benoit.boissinot@...]
> > > cp sleipner_2.xls sleipner.xls
> > > echo "Checkin second version:"
> > > hg ci -m "Second version, fails!"
> >
> > Does `hg root` works here?
>
> 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.

Ok, does hg --traceback give more information then?

regards,

Benoit

--
:wq
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[jens.lund]

> From: Benoit Boissinot [mailto:benoit.boissinot@...]
> 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)!

Jens

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Matt Mackall]

On Fri, 2009-11-06 at 15:23 +0100, jens.lund@... wrote:

> > From: Benoit Boissinot [mailto:benoit.boissinot@...]
> > 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


_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[jens.lund]

> From: Matt Mackall [mailto:mpm@...]
> On Fri, 2009-11-06 at 15:23 +0100, jens.lund@... wrote:
> > > From: Benoit Boissinot [mailto:benoit.boissinot@...]
> > > 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.lund@...>
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.lund@...>
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

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Matt Mackall]

On Fri, 2009-11-06 at 15:56 +0100, jens.lund@... wrote:

> > From: Matt Mackall [mailto:mpm@...]
> > On Fri, 2009-11-06 at 15:23 +0100, jens.lund@... wrote:
> > > > From: Benoit Boissinot [mailto:benoit.boissinot@...]
> > > > 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?
>
> ./.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?)
- 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


_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[jens.lund]

> From: Matt Mackall [mailto:mpm@...]
> On Fri, 2009-11-06 at 15:56 +0100, jens.lund@... wrote:
> > > From: Matt Mackall [mailto:mpm@...]
> > > What files are in your .hg directory?
> >
> > ./.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.lund@...>

[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

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[jens.lund]

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

> -----Original Message-----
> From: Lund, Jens
> Sent: Sunday, November 08, 2009 11:54 PM
> To: 'Matt Mackall'
> Cc: 'benoit.boissinot@...'; 'mercurial@...'
> Subject: RE: Checkin gives error "abort: There is
> noMercurialrepositoryhere(.hg not found)!" on
> TortoiseHg/Windows version
>
> > From: Matt Mackall [mailto:mpm@...]
> > On Fri, 2009-11-06 at 15:56 +0100, jens.lund@... wrote:
> > > > From: Matt Mackall [mailto:mpm@...]
> > > > What files are in your .hg directory?
> > >
> > > ./.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.lund@...>
>
> [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
>

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Benoit Boissinot]

On Thu, Nov 12, 2009 at 02:54:49PM +0100, jens.lund@... wrote:
>
> 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
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[jens.lund]

> From: Benoit Boissinot [mailto:benoit.boissinot@...]
> Maybe one more question, do you use a file scanner, anti-virus, or
> something similar?

Yes, Symantec Antivirus.

Jens
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Matt Mackall]

On Thu, 2009-11-12 at 17:24 +0100, jens.lund@... wrote:
> > From: Benoit Boissinot [mailto:benoit.boissinot@...]
> > 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


_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[jens.lund]

> From: Matt Mackall [mailto:mpm@...]
> If possible, try your test with antivirus disabled.

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
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial