Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 13 Mar 2015 10:49:02 -0700] rev 1212
merge with stable
Durham Goode <durham@fb.com> [Fri, 13 Mar 2015 09:05:34 -0700] rev 1211
evolve: fix manifest usage to match upstream
The manifest class upstream is no longer a dictionary, so switch to using an API
it does support.
Durham Goode <durham@fb.com> [Fri, 13 Mar 2015 09:04:12 -0700] rev 1210
drophack: fix to match upstream repair.strip
repair.strip upstream now assumes the input nodelist is a list, so update to
match it. The upstream change only affects the name of the backup bundle, so
this shouldn't affect any other functionality.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 05 Mar 2015 20:02:07 -0500] rev 1209
evolve: prevent a crash in httpclient_pushobsmarkers() when pushing
I've been running into a crash when pushing from my hg repo in a Fedora 16 VM to
Win7 running 'hg serve', even with extensions disabled on both sides:
../hg push -r . pc
pushing to http://192.168.1.4:8000/
searching for changes
no changes found
pushing 2 obsolescence markers (263 bytes)
** unknown exception encountered, please report by visiting
...
File "hg-evolve/hgext/evolve.py", line 2482, in _pushobsolete
remote.evoext_pushobsmarkers_0(obsdata)
File "hg-evolve/hgext/evolve.py", line 2522, in httpclient_pushobsmarkers
ret, output = self._call('evoext_pushobsmarkers_0', data=obsfile)
ValueError: too many values to unpack
I'm not sure how this repo differs from the one in the test suite, so I'm not
sure how to craft a test for this. The failure occurs even when there _are_
csets to push. There was no crash if no obsolete markers needed to be pushed.
At any rate, this code was stolen from httppeer._callpush(), where it calls
self._call(). The socket exception handling wasn't necessary to fix the crash,
but the calling code might as well be duplicated in its entirety.
A successful push with this patch looks like this. Note the final line is _not_
in the output of the http push in test-simple4server.t:
../hg push -r . pc
pushing to http://192.168.1.4:8000/
searching for changes
remote has heads on branch 'default' that are not known locally: 3af110194a0c
56000e3ae44d 57ac6e51d290 7da4355c21b8 and 8 others
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 0 changes to 1 files (+1 heads)
pushing 4 obsolescence markers (525 bytes)
remote: 2 obsolescence markers added
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 05 Mar 2015 10:52:01 -0800] rev 1208
merge stable into default
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 05 Mar 2015 10:45:53 -0800] rev 1207
Added tag 5.1.1 for changeset 9b8628e0a142
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 05 Mar 2015 10:45:40 -0800] rev 1206
prepare release 5.1.1
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 05 Mar 2015 10:44:43 -0800] rev 1205
update readme
Yuya Nishihara <yuya@tcha.org> [Thu, 29 Jan 2015 22:53:43 +0900] rev 1204
evolve: use 3.2+ fullreposet to evaluate argument set (issue4515)
getset() has no compatibility wrapper for old-style argument and we don't
want to add more hacks in Mercurial core.
Mathias De Maré <mathias.demare@gmail.com> [Mon, 02 Mar 2015 20:12:00 +0100] rev 1203
evolve: cache marker encoding to avoid performance degradation
The main overhead in bug 4518 is caused by calculating relevant markers
and encoding markers into the correct format.
Calculating relevant markers takes (worst case) ~ 0.12 seconds.
Encoding markers takes (worst case) ~ 0.06 seconds.
Caching encoded markers takes care of the second part and
speeds up cloning in bug 4518 by about 35%.