(Sorry for the late response, I just now figured out how your forum notifications work)
> Regarding history, as of the last time I was aware there is no way to track through the branches other than using a "best-guess"
> algorithm which is horribly inefficient (believe me, I tried). ... It may works ok on a smaller code base, but on a converted version of
> our code base it took nearly an hour to get a complete history for a file. Subversion is supposed to be putting in some better support for this,
> and when it is available we will support it as soon as possible.
Tell me if I'm totally off base here, but I was hacking Trac a little bit and was looking at their python implementation of this stuff. The svn header files define this:
http://svn.collab.net/viewvc/svn/trunk/subversion/include/svn_repos.h?view=markupin svn_repos.h (part of the subversion-devel package), function svn_repos_get_logs3
* If discover_changed_paths, then each call to receiver passes a
* hash mapping paths committed in that revision to information about them
* as the receiver's @a changed_paths argument.
so it looks like the svn_repos_get_logs function allows you to specify a "discover_changed_paths" parameter that will follow the changes backwards.
Then if you look at the trac source code (sorry, we're using an old version and it's been heavily refactored since then):
http://trac.edgewall.org/browser/trunk/trac/Log.py?rev=800look at the definitions for get_info and the callback function log_receiver
I think that's the way to track through the branches without using a "best-guess" algorithm. And it seems pretty efficient. Isn't that right?
Sorry, I'm at work right now or I'd put together a code snippet. The part of SlickEdit that does this is in compiled C code, not in the macros, right?