mirror of
https://github.com/facebook/sapling.git
synced 2024-10-11 09:17:30 +03:00
c8659cbb76
Conversion of a merge starts with p1 and re-adds the files that were changed in the merge or came unmodified from p2. Files that are unmodified from p1 will thus not be touched and take no time. Files that are unmodified from p2 would be retrieved and rehashed. They would end up getting the same hash as in p2 and end up reusing the filelog entry and look like the p1 case ... but it was slow. Instead, make getchanges also return 'files that are unmodified from p2' so the sink can reuse the existing p2 entry instead of calling getfile. Reuse of filelog entries can make a big difference when files are big and with long revlong chains so they take time to retrieve and hash, or when using an expensive custom getfile function (think http://mercurial.selenic.com/wiki/ConvertExtension#Customization with a code reformatter). This in combination with changes to reuse filectx entries in localrepo._filecommit make 'unchanged from p2' almost as fast as 'unchanged from p1'. This is so far only implemented for the combination of hg source and hg sink. This is a refactoring/optimization. It is covered by existing tests and show no changes - which is a good thing. |
||
---|---|---|
.. | ||
convert | ||
highlight | ||
largefiles | ||
zeroconf | ||
__init__.py | ||
acl.py | ||
blackbox.py | ||
bugzilla.py | ||
censor.py | ||
children.py | ||
churn.py | ||
color.py | ||
eol.py | ||
extdiff.py | ||
factotum.py | ||
fetch.py | ||
gpg.py | ||
graphlog.py | ||
hgcia.py | ||
hgk.py | ||
histedit.py | ||
keyword.py | ||
mq.py | ||
notify.py | ||
pager.py | ||
patchbomb.py | ||
progress.py | ||
purge.py | ||
rebase.py | ||
record.py | ||
relink.py | ||
schemes.py | ||
share.py | ||
shelve.py | ||
strip.py | ||
transplant.py | ||
win32mbcs.py | ||
win32text.py |