Hg push tries to push data to repo without any changes
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Wed Jan 30 20:52:05 UTC 2013
On 29 janv. 2013, at 13:32, Pierre-Yves David wrote:
> - We should discuss this with a lower latency medium (including air)
There is summary of todays phone call with Matt:
We need a fixes in two directions:
- prevent new client to have issue with older client (2.1+)
- prevent old client (2.1+) to have issue with newer server
This is important since old client tend to stay around for a long time.
(next Debian stable has 2.2.2)
Client side fix
----------------
Short term fix (aimed at 2.5):
We are going to not push phase when all the following condition are True:
1) Push is triggered by subrepo
2) Push did not exchanged any changeset
3) Server is publishing
This narrow the behavior change to the most problematic case.
Longer terms fix would be to have subrepo not event try to push if nothing
changed on a subrepo. This is much more complex change that implies to track
subrepo state in a reliable way.
Server side fix
----------------
We want older client talking to new server to not be affected by the subrepo
bug. This is harder to achieve as we can alter client behavior.
The currently proposed approach is to add a new pushkey namespace for phases
(phases2). This new namespace will behave exactly as the current one, but
publishing server will not list draft root in the old "phases" namespace.
eg:
If a publishing server have B draft locally we will list:
phases: {'publishing': 'True'}
phases2: {'publishing': 'True', 'B': '1'}
New client search for phases2 and fallback to phase on older server. They will
behaver exactly as now including the subrepo push exception to prevent the
issue.
Older client will not see draft changeset on newer server and not try to push
synchronisation (in all case, subrepo and other)
This fix is scheduled for "later" (probably 2.5.1) so we can think a bit more
about it.
--
Pierre-Yves David
More information about the Mercurial
mailing list