I see.

(1) Are there any specific cases that this scan solves? (I know there's one
problematic case that I encountered in the LyX repo, where a whole bunch of
branches appear under branches/personal/ rather than directly under branches/,
and then they were all getting imported into mercurial as a single branch, with
a wrong file layout; and this was wreaking havoc with the repository's size.
However, I'm not sure that the scan would solves this, since by the time it
happens (after having imported the changesets) it's too late to decide what is a
branch and what is not?).
(2) Perhaps the information gleaned from such a scan could be cached, so that
incremental imports would not take as long? The initial convert takes a long
time on a large repository as it is, so the additional overhead of the scan, is,
 I think, acceptable. But taking so long for incremental imports is not.
(3) Or perhaps there could be some other solution?

But the current situation means that incrementally tracking LyX's subversion
repository is basically not workable, at least not automatically.

Thanks for your feedback!

This issue is not a bug but it's more a design problem. Because Subversion
doesn't force to respect trunk, branches and tags convention, P.Mézard chose to
design svn convert tools to be able to deal with any situations (where an svn
repo doesn't follow the svn convention). But to do this, we should scan svn
history to discover the relations between the mainstream branch and tags and
this takes a lot of time if there are a lot of tags like in Lyx svn repo.
Added to this, there are special cases like tags renaming which we should take
care and it implies to scan svn history which is expensive operation in big repo.
Added to this, there are special cases like tags renaming to take care of this
we should scan svn history which is expensive operation.

convert from svn enters an endless (or possibly just very long) loop when the
conversion is completed. I'm testing with the following command:

hg convert --rev 139 --debug svn://svn.lyx.org/lyx/lyx-devel /tmp/convert-test

(Note: rev 139 is the first revision under lyx-devel; converting up to 138 
works fine --- i.e., does nothing, but doesn't hang.)

This did not use to happen, and bisect finds that it was introduced by this:

The first bad revision is:
changeset:   6392:5efd447a9b8d
user:        Patrick Mezard <pmezard@gmail.com>
date:        Sat Mar 29 17:15:45 2008 +0100
summary:     convert: follow svn tags history (issue953)

I first reported this to the mailing list about a month ago, there's a debug log
attached in the original message
(http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/7131).
Only recently was I able to confirm this from a separate machine.