# Lots of errors after upgrade to hgSubversion 1.6.3 stable (807c443928d4)

Issue #426 closed
FlorianGeorge
created an issue

This is the version used when the first error occurs:

Mercurial Distributed SCM (version 3.1+2)

Copyright (C) 2005-2014 Matt Mackall 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.

hgsubversion: 807c443928d4
Subversion: 1.6.16
bindings: SWIG


After upgrading to it, an hg pull gives lots of errors:

# abort: unable to operate on unrelated repository

abort: unable to operate on unrelated repository


I edited svnmeta.py line 138 to be

raise hgutil.Abort('unable to operate on unrelated repository - uuid is ' + uuid + ', stored uuid is ' + stored_uuid)


and got the message

abort: unable to operate on unrelated repository - uuid is xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, stored uuid is "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"


I looked into the file .hg/svn/uuid, and indeed, the uuid there was stored with " around it.

Removing the " around it solves this issue, but the next one soon popped up.

Possible solution: Check if uuid has " around it and remove them?

Workaround: Edit .hg/svn/uuid File and remove the "

# abort: unable to work on a different path in the repository

After fixing the uuid issue, I got the error

abort: unable to work on a different path in the repository


Again, to find out what's going on, I edited svnmeta.py lines 112 and 113 to now say

                raise hgutil.Abort('unable to work on a different path in the '
'repository - subdir is ' + subdir + ', stored subdir is ' + stored_subdir)


and got the error message

abort: unable to work on a different path in the repository - subdir is trunk, stored subdir is "trunk"


And again, looking into the .hg/svn/subdir file, indeed the trunk dir was surrounded with "

Removing the " around it solves this, issue, but the next one soon popped up.

Possible solution: Check if uuid has " around it and remove them?

Workaround: Edit .hg/svn/subdir File and remove the "

# Branch ../

Now doing an hg pull will pull, but instead of putting the pulled svn revisions into default, they are named ../ which is super weird but probably means that yet another string has been parsed the wrong way:

While I am able to pull now, this doesn't seem right. I have no possible solution or workaround for this issue atm so I am not able to continue pulling.

# svn.core.SubversionException: ("Path 'trunk' not present", 160016)

When doing an hg push, I am getting the following output:

pushing to svn://xxx.xxx.xxx.xxx/XXXxx/trunk
searching for changes
committing 37baa77745dd
** Unknown exception encountered with possibly-broken third-party extension hgsu
bversion
** which supports versions unknown of Mercurial.
** If that fixes the bug please report it to the extension author.
** Python 2.7.6 (default, Nov 10 2013, 19:24:24) [MSC v.1500 64 bit (AMD64)]
** Mercurial Distributed SCM (version 3.1+2)
Traceback (most recent call last):
File "hg", line 42, in <module>
File "mercurial\dispatch.pyo", line 28, in run
File "mercurial\dispatch.pyo", line 69, in dispatch
File "mercurial\dispatch.pyo", line 138, in _runcatch
File "mercurial\dispatch.pyo", line 820, in _dispatch
File "mercurial\dispatch.pyo", line 600, in runcommand
File "mercurial\dispatch.pyo", line 911, in _runcommand
File "mercurial\dispatch.pyo", line 882, in checkargs
File "mercurial\dispatch.pyo", line 817, in <lambda>
File "mercurial\util.pyo", line 550, in check
File "mercurial\extensions.pyo", line 151, in wrap
File "mercurial\util.pyo", line 550, in check
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\wrappers.py", line 651, in generic
return orig(ui, repo, *args, **opts)
File "mercurial\util.pyo", line 550, in check
File "mercurial\commands.pyo", line 4791, in push
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\svnrepo.py", line 81, in wrapper
return fn(self, *args, **opts)
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\svnrepo.py", line 105, in push
return wrappers.push(self, remote, force, revs)
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\wrappers.py", line 269, in push
tip_hash, svn)
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\pushmod.py", line 204, in commit
props, newcopies)
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\svnwrap\svn_swig_wrapper.py", line 456, in commit
editor.close_edit(edit_baton, self.pool)
File "libsvn\delta.pyo", line 453, in close_edit
File "libsvn\delta.pyo", line 666, in svn_delta_editor_invoke_close_edit
svn.core.SubversionException: ("Path 'trunk' not present", 160016)


Again, this seems like a string parse going wrong. Maybe the ' (instead of ") around the trunk path are a hint?

# Reverting to Mercurial 3.0.1

Looking at the directory where I save my installers, the last version I had installed before the issue occured was TortoiseHg 3.0.1 which had Mercurial 3.0.1 bundled.

Reverting to TortoiseHg 3.0.1 with Mercurial 3.0.1 didn't work, the same errors occurred with this version, so it might not be Mercurial's fault:

Mercurial Distributed SCM (version 3.0.1)

Copyright (C) 2005-2014 Matt Mackall 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.

hgsubversion: 807c443928d4
Subversion: 1.6.16
bindings: SWIG


# Reverting to an hgSubversion 1.5.1

When reverting to hgSubversion 1.5.1 (b5b1fce26f1f), I am getting this error on pull:

V:\Development>"c:\Program Files\TortoiseHg\hg.exe" pull
*** failed to import extension hgsubversion from V:\Tools, Libraries, Ressources
\SVN & CVS Tools\hgsubversion\hgsubversion: 'module' object has no attribute 'ca
nonpath'
** unknown exception encountered, please report by visiting
** http://mercurial.selenic.com/wiki/BugTracker
** Python 2.7.6 (default, Nov 10 2013, 19:24:24) [MSC v.1500 64 bit (AMD64)]
** Mercurial Distributed SCM (version 3.0.1)
Traceback (most recent call last):
File "hg", line 42, in <module>
File "mercurial\dispatch.pyo", line 28, in run
File "mercurial\dispatch.pyo", line 69, in dispatch
File "mercurial\dispatch.pyo", line 138, in _runcatch
File "mercurial\dispatch.pyo", line 786, in _dispatch
File "mercurial\hg.pyo", line 119, in repository
File "mercurial\hg.pyo", line 106, in _peerorrepo
File "mercurial\hg.pyo", line 80, in _peerlookup
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\__init__.py", line 185, in _lookup
if util.islocalrepo(url):
AttributeError: 'NoneType' object has no attribute 'islocalrepo'


This is not good, do I need an older Version of TortoiseHg/Mercurial for it to work? Found that issue here: https://bitbucket.org/durin42/hgsubversion/issue/416/failed-to-import-extension But getting the newest Mercurial and newest hgSubversion is currently a problem, I simply don't know which is the most-recent-but-working combination :(

# Reverting to hgSubversion 1.6.1 (00193337d7f3)

Mercurial Distributed SCM (version 3.0.1)

Copyright (C) 2005-2014 Matt Mackall 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.

hgsubversion: 00193337d7f3
Subversion: 1.6.16
bindings: SWIG


will give the

abort: unable to operate on unrelated repository


error already, so it might have started there.

# Up-verting to hgSubversion default/tip instead of stable

Using this version

Mercurial Distributed SCM (version 3.0.1)

Copyright (C) 2005-2014 Matt Mackall 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.

hgsubversion: 5c2917375961
Subversion: 1.6.16
bindings: SWIG


I am getting the error

pulling from svn://xxx.xxx.xxx.xxx/CCDev/trunk
** Unknown exception encountered with possibly-broken third-party extension hgsu
bversion
** which supports versions unknown of Mercurial.
** If that fixes the bug please report it to the extension author.
** Python 2.7.6 (default, Nov 10 2013, 19:24:24) [MSC v.1500 64 bit (AMD64)]
** Mercurial Distributed SCM (version 3.0.1)
Traceback (most recent call last):
File "hg", line 42, in <module>
File "mercurial\dispatch.pyo", line 28, in run
File "mercurial\dispatch.pyo", line 69, in dispatch
File "mercurial\dispatch.pyo", line 138, in _runcatch
File "mercurial\dispatch.pyo", line 819, in _dispatch
File "mercurial\dispatch.pyo", line 599, in runcommand
File "mercurial\dispatch.pyo", line 910, in _runcommand
File "mercurial\dispatch.pyo", line 881, in checkargs
File "mercurial\dispatch.pyo", line 816, in <lambda>
File "mercurial\util.pyo", line 518, in check
File "mercurial\extensions.pyo", line 151, in wrap
File "mercurial\util.pyo", line 518, in check
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversio
n\wrappers.py", line 645, in generic
return orig(ui, repo, *args, **opts)
File "mercurial\util.pyo", line 518, in check
File "mercurial\extensions.pyo", line 151, in wrap
File "mercurial\util.pyo", line 518, in check
File "hgext\rebase.pyo", line 933, in pullrebase
File "mercurial\util.pyo", line 518, in check
File "mercurial\commands.pyo", line 4607, in pull
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\svnrepo.py", line 77, in wrapper
return fn(self, *args, **opts)
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\svnrepo.py", line 105, in pull
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\wrappers.py", line 434, in pull
tbdelta = meta.update_branch_tag_map_for_rev(r)
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\svnmeta.py", line 547, in update_branch_tag_map_for_rev
t_name = self.get_path_tag(p)
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\svnmeta.py", line 365, in get_path_tag
return self.layoutobj.get_path_tag(path, self.taglocations)
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\svnmeta.py", line 355, in taglocations
return self.layoutobj.taglocations(self.metapath)
File "V:/Tools, Libraries, Ressources/SVN & CVS Tools/hgsubversion\hgsubversion\layouts\standard.py", line 69, in taglocations
File "mercurial\demandimport.pyo", line 103, in __getattribute__
AttributeError: 'module' object has no attribute 'load'


This error has been discussed here: https://bitbucket.org/durin42/hgsubversion/issue/421/fail-to-clone-a-repository-with-mercurial

After using the workaround by robi wan, I can pull again with this combination, but it is pulling it into the feared ../ branch...I guess I broke my local repository :(((

# Continuing to use Mercurial 3.1+2 and hgSubversion 1.6.3

I am currently trying two things to be able to continue working.

One of them is doing a completely new Clone with the new TortoiseHg/Mercurial Version. That way it appears that the metadata and whatever got changed will be stored correctly now and I can use the newly cloned repository from now on with the new TortoiseHg/Mercurial Version.

I hope I am able to just export patches of my uncommitted changes and reimport them.

I hope that I can just copy the shelves directory to keep them.

Anything else I would need to look at when migrating to the "new" local repository?

1. repo owner

Can you show us the output of hg version --svn on both of those builds? I have no idea what tortoise might be shipping, and without that information there's no hope of us finding the problem.

2. repo owner

BTW, a likely fix would be to run 'hg svn rebuildmeta' on your local copy - that'll rebuild the local metadata caches and then things /should/ start working more cleanly.

3. repo owner

Your hgsubversion didn't change? That seems impossible. Is it your own hgsubversion, or one that came with thg?

(Please just comment in the comments from here on rather than updating the bug contents.)

4. repo owner

You definitely won't be able to copy shelves to save them.

I'd really rather have a conversation with you, rather than you editing the entire description. You seem to have missed this last time, so I'm going to make this super-clear:

STOP MODIFYING THE BUG DESCRIPTION AND MAKE A COMMENT. The way you're doing things makes this almost impossible to follow.

Now, can you get me a version of hgsubversion that actually works the old way for you?

Can you try 'hg svn rebuildmeta' in the old clone? (Maybe in a copy so as to preserve the old-format metadata files so if we get a fix you can test it.)

5. reporter

Ok sorry I didn't see your replies.

• added versions to all errors

• the very fist thing I did was a hg svn rebuildmeta, that didn't help (at that time).

• I usually update TortoiseHg and the local hgSubversion repo at the same time

• I currently have neither an old nor a new combination of versions that is working the way it did before all these errors occured

I am now using this Version:

Mercurial Distributed SCM (version 3.0.1)

Copyright (C) 2005-2014 Matt Mackall 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.

hgsubversion: 5c2917375961
Subversion: 1.6.16
bindings: SWIG


I did yet another hg svn rebuildmeta and it might have solved all my issues now.

This might push all my reported errors into the wont-fix-works-for-me-now trench but oh well.

6. repo owner

Okay. Should I just close this for now?

(I'll probably do some investigation around this in the future anyway, as the report is worrying. It'd still be nice to know what the version you were using with the older tortoise was, because it's completely implausible that changing just the hg or svn libraries would break this part of hgsubversion.)

7. reporter

Yes, for now, you can close this.

It would be nice to find fixes to at least some of those weird errors, even if they are not needed for me atm.

I am using the default branch now, the errors might still be present in the current stable one.

You are right, the fact that I can't pinpoint the TortoiseHg / hgSubversion combination I was using before the error occured is extremely unfortunate.

8. repo owner

Closing this since we don't have enough info to start bisecting a problem.