File timestamps are incorrect when updating to an earlier revision

Issue #1 resolved
Jean-Luc Jumpertz
created an issue

When running hg update to revert to an earlier revision than the currently selected one, the timestamp of the updated files is not correctly set if the files have not been changed in the target update revision.

For example, let's consider the following configuration

{{{ rev 3: 2011-10-05 FileA FileB

rev2: 2011-09-05 File B

rev1: 2011-01-01 FileA }}} {{{

hg update -q -r null

hg update -q -r 3 ls -l FileA 2011-10-05 FileB 2011-10-05

hg update -q -r 2 ls -l FileA 2011-10-05 --> incorrect ! should be 2011-01-01 FileB 2011-09-05


This can easily be explained by the code taking only into account the dates of the changed files between preupdate and update revisions. I have a fix available (functional but quite slow in case many files have changed) I can provide it if you're interested.



Comments (5)

  1. Jean-Luc Jumpertz reporter

    Attached is my proposed fix.

    The basic idea is simple: it gets the latest revision for each file having the date in the map after the date of the target update revision. Unfortunately this means executing one hg log command for each file matching this criteria, so it may take some time when many files have been changed.

  2. Esben Skovenborg repo owner

    Ok, would you like to push your patch to the bitbucket repo?

    I'm not sure how many users hg_timestamp_update has, but I suppose most of us would prefer 'correct' over 'faster'. I'll do some more testing later, on some largeish repos, to see how bad it is.

  3. Esben Skovenborg repo owner

    I've now done some more testing, and found no functional side-effects of the fix in fc0808cf155a .

    In some cases updating to an earlier revision can indeed be quite slow due to the extra calls to hg log. Most of the time is apparently spent spawning the hg process rather than executing the actual hg log command. It takes between 0.2 and 0.3 s per hg call, on my Win XP system.

    In 2921e56f568b I added a check which will in many cases reduce the number of extra hg calls. I've tagged this version 0.4.

    But it would be nice with an equivalent solution that would require a constant number of calls to hg...

  4. Log in to comment