Using our new generator, we factor out revmap.youngest and renamed it to the
same name as the config file 'lastpulled' because that is the name of the file
and is arguably less confusing to read.
I have a hgsubversion repo that contains over 300,000 commits.
In that repo, this patch improves performance as follows:
hg --time log -r 'first(fromsvn())'
Before: 40.3 sec
After: 0.8 sec
hg --time log -r 'svnrev(350000)'
Before: 40.3 sec
After: 0.1 sec
Note: the performance of these revset implementations is very sensitive
to doing as little work as possible per line of the rev_map file.
I originally attempted to hide the file format details by hoisting the
parsing of each line up into RevMap.readmapfile, but the current less
abstract code is dramatically (10x or more) faster.
If the revmap file is missing, we error out and print a message
describing what to do.
hg 1.9 dramatically cleaned up patch application, but unfortunately
this breaks stupid mode with filemaps. In the name of getting a
release out the door, disabling this feature for now. There will be
changes required in hg to make this work again, so we may just drop
the feature entirely if nobody's interested.
This prevents re-pulling the same revision over and over, which was a
problem when the most recent revision was a tagging revision that
wouldn't exist properly in the revmap. This should also allow users to
not re-pull huge volumes of commits that have no effect on the hg
repository.
Previously, specifying an extra authormap with the
hgsubversion.authormap configuration variable would cause the entirety
of the other authormap to be appended to the one in '.hg/svn/authors'
on each subversion access (e.g. hg in/out/pull/push).
This also changes the authormap to preserve comments and the like in
the authormap file.
This uses a separate map, since the purpose is very different from the purpose
of the TagMap that we currently have. It seemed to me that unifying both will
only serve to make the implementation more complicated. The name TagRenames
is not that elegant, but I didn't have any better idea. Feel free to change.
Author maps for the Python repo got truncated because of the author map stupidly
writing upon itself. This patch implements a better and faster scenario, where
entries will only be written to the saved author map if they're not coming from that
file. They're also now streamed into the file directly, instead of having to re-open
the file on every entry, and formatting is preserved.
