Merclipse: problems with large repository (100,000+ changesets, 17,000 files)

[Greg Ward]

I'm just going to keep asking Merclipse questions here until someone
tells me to shut up or points me at the appropriate forum for
Merclipse support.  So here's the next problem:

Various operations are unusable because they attempt to load the
project's entire history.  E.g. if I right-click on a project, then go
to Team->Update, I get a dialog "Update the working directory to the
specified r...".  (I assume that is supposed to say "revision", and
the truncation is a GUI bug.)  But then it just goes off into "Loading
revisions", apparently forever.  With 'ps' I can see that Eclipse has
a child process running 'hg log', which is not a good idea on a
repository with 100,000 changesets.  I assume it's is eventually going
to try to present me a menu with 100,000 items in it, which also
doesn't seem like a good idea.

Cancelling the dialog leaves that 'hg log' child process still running.

Similar behaviour with Team->Merge, Team->Push.

Team->Show Repository Log is also impractical, since it too spawns 'hg
log' and waits for the result.  While 'hg log' is running, Eclipse is
even slower than normal.  Once 'hg log' is done, Eclipse appears to
lockup entirely for a few minutes.  Eventually I get the complete
project history (100,000+ changesets) in the History tab, but
Eclipse's memory use has gone from RSS=~110 MB to ~330 MB.  (Oh yeah,
this is all on Linux, CentOS 5 to be precise.  Eclipse 3.4.2.  I can
try 3.5.0 if it's worth my while.)

Anyways... it looks like Merclipse wasn't really designed for use on
large repositories.  Too bad.  Is anyone actually working on it, or
should I go back to MercurialEclipse and see if they have plans to
handle large repositories?  (MercurialEclipse also doesn't work
brilliantly with 100,000 changeset and 17,000 files -- but at least it
has a mailing list and appears to be actively maintained.)

Greg

P.S. to anyone writing or maintaining a Mercurial front-end, please
keep in mind that projects with 100,000+ changesets and a decade or
more of history are a reality *right now*, and will only become more
common in the future.  The only front-end I have seen that makes any
attempt to handle large repositories is TortoiseHg, and it uses a dead
simple, very reliable, easy-to-understand mechanism for doing so: only
show the latest 500 changesets by default.  Great idea!  Let's have
more of that.  It's not perfect, as I don't think it's possible to
jump back in time to revision 30,000 without reading the intervening
70,000 revisions.  But it's miles ahead of the competition.