view tests/test-eol-tag.t @ 25774:4f8c20fe66f0

shelve: keep old backups if timestamp can't decide exact order of them

Before this patch, backups to be discarded are decided by steps below
at 'hg unshelve' or so:

  1. list '(st_mtime, filename)' tuples of each backups up
  2. sort list of these tuples, and
  3. discard backups other than 'maxbackups' ones at the end of list

This doesn't work well in the case below:

  - "sort by name" order differs from actual backup-ing order, and
  - some of backups have same timestamp

For example, 'test-shelve.t' satisfies the former condition:

  - 'default-01' < 'default-1' in "sort by name" order
  - 'default-1'  < 'default-01' in actual backup-ing order

Then, 'default-01' is discarded instead of 'default-1' unexpectedly,
if they have same timestamp. This failure appears occasionally,
because the most important condition "same timestamp" is timing
critical.

To avoid such unexpected discarding, this patch keeps old backups if
timestamp can't decide exact order of them.

Timestamp of the border backup (= the oldest one of recent
'maxbackups' ones) as 'bordermtime' is used to examine whether
timestamp can decide exact order of backups.

http://mercurial.selenic.com/bts/issue2493

Testing tagging with the EOL extension

  $ cat >> $HGRCPATH <<EOF
  > [extensions]
  > eol =
  > 
  > [eol]
  > native = CRLF
  > EOF

setup repository

  $ hg init repo
  $ cd repo
  $ cat > .hgeol <<EOF
  > [patterns]
  > ** = native
  > EOF
  $ printf "first\r\nsecond\r\nthird\r\n" > a.txt
  $ hg commit --addremove -m 'checkin'
  adding .hgeol
  adding a.txt

Tag:

  $ hg tag 1.0

Rewrite .hgtags file as it would look on a new checkout:

  $ hg update -q null
  $ hg update -q

Touch .hgtags file again:

  $ hg tag 2.0

  $ cd ..