comparison tests/test-histedit-obsolete.t @ 30556:c059286a0f9c

tests: replace "cp -r" with "cp -R"

The POSIX documentation about "cp" [1] says:

  ....

  RATIONALE
    ....
    Earlier versions of this standard included support for the -r option to
    copy file hierarchies. The -r option is historical practice on BSD and
    BSD-derived systems. This option is no longer specified by POSIX.1-2008
    but may be present in some implementations. The -R option was added as a
    close synonym to the -r option, selected for consistency with all other
    options in this volume of POSIX.1-2008 that do recursive directory
    descent.

    The difference between -R and the removed -r option is in the treatment
    by cp of file types other than regular and directory. It was
    implementation-defined how the - option treated special files to allow
    both historical implementations and those that chose to support -r with
    the same abilities as -R defined by this volume of POSIX.1-2008. The
    original -r flag, for historic reasons, did not handle special files any
    differently from regular files, but always read the file and copied its
    contents. This had obvious problems in the presence of special file
    types; for example, character devices, FIFOs, and sockets.
    ....

  ....

  Issue 6
    The -r option is marked obsolescent.
    ....

  Issue 7
    ....
    The obsolescent -r option is removed.
    ....

  (No "Issue 8" yet)

Therefore it's clear that "cp -R" is strictly better than "cp -r".

The issue was discovered when running tests on OS X after 0d87b1caed92.

[1]: pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html

30555:6a672c3b7860

Resulting changeset should conserve the phase of the original one whatever the
phases.new-commit option is.

New-commit as draft (default)

  $ cp -r base simple-draft
  $ cd simple-draft
  $ hg histedit -r 'b449568bf7fc' --commands - << EOF
  > edit b449568bf7fc 11 f
  > pick 6b70183d2492 12 g
  > pick 7395e1ff83bd 13 h

  $ cd ..


New-commit as secret (config)

  $ cp -r base simple-secret
  $ cd simple-secret
  $ cat >> .hg/hgrc << EOF
  > [phases]
  > new-commit=secret
  > EOF

-------------------------------------------

If a secret changeset is put before a draft one, all descendant should be secret.
It seems more important to present the secret phase.

  $ cp -r base reorder
  $ cd reorder
  $ hg histedit -r 'b449568bf7fc' --commands - << EOF
  > pick b449568bf7fc 11 f
  > pick 3a6c53ee7f3d 15 j
  > pick 6b70183d2492 12 g

Folding a secret changeset with a draft one turn the result secret (again,
better safe than sorry). Folding between same phase changeset still works

Note that there is a few reordering in this series for more extensive test

  $ cp -r base folding
  $ cd folding
  $ cat >> .hg/hgrc << EOF
  > [phases]
  > new-commit=secret
  > EOF

30556:c059286a0f9c

Resulting changeset should conserve the phase of the original one whatever the
phases.new-commit option is.

New-commit as draft (default)

  $ cp -R base simple-draft
  $ cd simple-draft
  $ hg histedit -r 'b449568bf7fc' --commands - << EOF
  > edit b449568bf7fc 11 f
  > pick 6b70183d2492 12 g
  > pick 7395e1ff83bd 13 h

  $ cd ..


New-commit as secret (config)

  $ cp -R base simple-secret
  $ cd simple-secret
  $ cat >> .hg/hgrc << EOF
  > [phases]
  > new-commit=secret
  > EOF

-------------------------------------------

If a secret changeset is put before a draft one, all descendant should be secret.
It seems more important to present the secret phase.

  $ cp -R base reorder
  $ cd reorder
  $ hg histedit -r 'b449568bf7fc' --commands - << EOF
  > pick b449568bf7fc 11 f
  > pick 3a6c53ee7f3d 15 j
  > pick 6b70183d2492 12 g

Folding a secret changeset with a draft one turn the result secret (again,
better safe than sorry). Folding between same phase changeset still works

Note that there is a few reordering in this series for more extensive test

  $ cp -R base folding
  $ cd folding
  $ cat >> .hg/hgrc << EOF
  > [phases]
  > new-commit=secret
  > EOF