view tests/test-convert-cvs-synthetic.t @ 24790:baa11dde8c0e

match: add a subclass for dirstate normalizing of the matched patterns

This class is only needed on case insensitive filesystems, and only
for wdir context matches. It allows the user to not match the case of
the items in the filesystem- especially for naming directories, which
dirstate doesn't handle[1]. Making dirstate handle mismatched
directory cases is too expensive[2].

Since dirstate doesn't apply to committed csets, this is only created by
overriding basectx.match() in workingctx, and only on icasefs.  The default
arguments have been dropped, because the ctx must be passed to the matcher in
order to function.

For operations that can apply to both wdir and some other context, this ends up
normalizing the filename to the case as it exists in the filesystem, and using
that case for the lookup in the other context.  See the diff example in the
test.

Previously, given a directory with an inexact case:

  - add worked as expected

  - diff, forget and status would silently ignore the request

  - files would exit with 1

  - commit, revert and remove would fail (even when the commands leading up to
    them worked):

        $ hg ci -m "AbCDef" capsdir1/capsdir
        abort: CapsDir1/CapsDir: no match under directory!

        $ hg revert -r '.^' capsdir1/capsdir
        capsdir1\capsdir: no such file in rev 64dae27060b7

        $ hg remove capsdir1/capsdir
        not removing capsdir1\capsdir: no tracked files
        [1]

Globs are normalized, so that the -I and -X don't need to be specified with a
case match.  Without that, the second last remove (with -X) removes the files,
leaving nothing for the last remove.  However, specifying the files as
'glob:**.Txt' does not work.  Perhaps this requires 're.IGNORECASE'?

There are only a handful of places that create matchers directly, instead of
being routed through the context.match() method.  Some may benefit from changing
over to using ctx.match() as a factory function:

  revset.checkstatus()
  revset.contains()
  revset.filelog()
  revset._matchfiles()
  localrepository._loadfilter()
  ignore.ignore()
  fileset.subrepo()
  filemerge._picktool()
  overrides.addlargefiles()
  lfcommands.lfconvert()
  kwtemplate.__init__()
  eolfile.__init__()
  eolfile.checkrev()
  acl.buildmatch()

Currently, a toplevel subrepo can be named with an inexact case.  However, the
path auditor gets in the way of naming _anything_ in the subrepo if the top
level case doesn't match.  That is trickier to handle, because there's the user
provided case, the case in the filesystem, and the case stored in .hgsub.  This
can be fixed next cycle.

  --- a/tests/test-subrepo-deep-nested-change.t
  +++ b/tests/test-subrepo-deep-nested-change.t
  @@ -170,8 +170,15 @@
     R sub1/sub2/test.txt
     $ hg update -Cq
     $ touch sub1/sub2/folder/bar
  +#if icasefs
  +  $ hg addremove Sub1/sub2
  +  abort: path 'Sub1\sub2' is inside nested repo 'Sub1'
  +  [255]
  +  $ hg -q addremove sub1/sub2
  +#else
     $ hg addremove sub1/sub2
     adding sub1/sub2/folder/bar (glob)
  +#endif
     $ hg status -S
     A sub1/sub2/folder/bar
     ? foo/bar/abc

The narrowmatcher class may need to be tweaked when that is fixed.


[1] http://www.selenic.com/pipermail/mercurial-devel/2015-April/068183.html
[2] http://www.selenic.com/pipermail/mercurial-devel/2015-April/068191.html

#require cvs112

This feature requires use of builtin cvsps!

  $ echo "[extensions]" >> $HGRCPATH
  $ echo "convert = " >> $HGRCPATH

create cvs repository with one project

  $ mkdir cvsrepo
  $ cd cvsrepo
  $ CVSROOT=`pwd`
  $ export CVSROOT
  $ CVS_OPTIONS=-f
  $ export CVS_OPTIONS
  $ cd ..
  $ rmdir cvsrepo
  $ cvscall()
  > {
  >     cvs -f "$@"
  > }

output of 'cvs ci' varies unpredictably, so just discard it

  $ cvsci()
  > {
  >     sleep 1
  >     cvs -f ci "$@" >/dev/null
  > }
  $ cvscall -d "$CVSROOT" init
  $ mkdir cvsrepo/proj
  $ cvscall -q co proj

create file1 on the trunk

  $ cd proj
  $ touch file1
  $ cvscall -Q add file1
  $ cvsci -m"add file1 on trunk" file1

create two branches

  $ cvscall -q tag -b v1_0
  T file1
  $ cvscall -q tag -b v1_1
  T file1

create file2 on branch v1_0

  $ cvscall -Q up -rv1_0
  $ touch file2
  $ cvscall -Q add file2
  $ cvsci -m"add file2" file2

create file3, file4 on branch v1_1

  $ cvscall -Q up -rv1_1
  $ touch file3
  $ touch file4
  $ cvscall -Q add file3 file4
  $ cvsci -m"add file3, file4 on branch v1_1" file3 file4

merge file2 from v1_0 to v1_1

  $ cvscall -Q up -jv1_0
  $ cvsci -m"MERGE from v1_0: add file2"
  cvs commit: Examining .

Step things up a notch: now we make the history really hairy, with
changes bouncing back and forth between trunk and v1_2 and merges
going both ways.  (I.e., try to model the real world.)
create branch v1_2

  $ cvscall -Q up -A
  $ cvscall -q tag -b v1_2
  T file1

create file5 on branch v1_2

  $ cvscall -Q up -rv1_2
  $ touch file5
  $ cvs -Q add file5
  $ cvsci -m"add file5 on v1_2"
  cvs commit: Examining .

create file6 on trunk post-v1_2

  $ cvscall -Q up -A
  $ touch file6
  $ cvscall -Q add file6
  $ cvsci -m"add file6 on trunk post-v1_2"
  cvs commit: Examining .

merge file5 from v1_2 to trunk

  $ cvscall -Q up -A
  $ cvscall -Q up -jv1_2 file5
  $ cvsci -m"MERGE from v1_2: add file5"
  cvs commit: Examining .

merge file6 from trunk to v1_2

  $ cvscall -Q up -rv1_2
  $ cvscall up -jHEAD file6
  U file6
  $ cvsci -m"MERGE from HEAD: add file6"
  cvs commit: Examining .

cvs rlog output

  $ cvscall -q rlog proj | egrep '^(RCS file|revision)'
  RCS file: $TESTTMP/cvsrepo/proj/file1,v
  revision 1.1
  RCS file: $TESTTMP/cvsrepo/proj/Attic/file2,v
  revision 1.1
  revision 1.1.4.2
  revision 1.1.4.1
  revision 1.1.2.1
  RCS file: $TESTTMP/cvsrepo/proj/Attic/file3,v
  revision 1.1
  revision 1.1.2.1
  RCS file: $TESTTMP/cvsrepo/proj/Attic/file4,v
  revision 1.1
  revision 1.1.2.1
  RCS file: $TESTTMP/cvsrepo/proj/file5,v
  revision 1.2
  revision 1.1
  revision 1.1.2.1
  RCS file: $TESTTMP/cvsrepo/proj/file6,v
  revision 1.1
  revision 1.1.2.2
  revision 1.1.2.1

convert to hg (#1)

  $ cd ..
  $ hg convert --datesort proj proj.hg
  initializing destination proj.hg repository
  connecting to $TESTTMP/cvsrepo
  scanning source...
  collecting CVS rlog
  15 log entries
  creating changesets
  9 changeset entries
  sorting...
  converting...
  8 add file1 on trunk
  7 add file2
  6 MERGE from v1_0: add file2
  5 file file3 was initially added on branch v1_1.
  4 add file3, file4 on branch v1_1
  3 add file5 on v1_2
  2 add file6 on trunk post-v1_2
  1 MERGE from HEAD: add file6
  0 MERGE from v1_2: add file5

hg log -G output (#1)

  $ hg -R proj.hg log -G --template "{rev} {desc}\n"
  o  8 MERGE from v1_2: add file5
  |
  | o  7 MERGE from HEAD: add file6
  | |
  o |  6 add file6 on trunk post-v1_2
  | |
  | o  5 add file5 on v1_2
  | |
  | | o  4 add file3, file4 on branch v1_1
  | | |
  o | |  3 file file3 was initially added on branch v1_1.
  |/ /
  | o  2 MERGE from v1_0: add file2
  |/
  | o  1 add file2
  |/
  o  0 add file1 on trunk
  

convert to hg (#2: with merge detection)

  $ hg convert \
  >   --config convert.cvsps.mergefrom='"^MERGE from (\S+):"' \
  >   --datesort \
  >   proj proj.hg2
  initializing destination proj.hg2 repository
  connecting to $TESTTMP/cvsrepo
  scanning source...
  collecting CVS rlog
  15 log entries
  creating changesets
  9 changeset entries
  sorting...
  converting...
  8 add file1 on trunk
  7 add file2
  6 MERGE from v1_0: add file2
  5 file file3 was initially added on branch v1_1.
  4 add file3, file4 on branch v1_1
  3 add file5 on v1_2
  2 add file6 on trunk post-v1_2
  1 MERGE from HEAD: add file6
  0 MERGE from v1_2: add file5

hg log -G output (#2)

  $ hg -R proj.hg2 log -G --template "{rev} {desc}\n"
  o  8 MERGE from v1_2: add file5
  |
  | o  7 MERGE from HEAD: add file6
  | |
  o |  6 add file6 on trunk post-v1_2
  | |
  | o  5 add file5 on v1_2
  | |
  | | o  4 add file3, file4 on branch v1_1
  | | |
  o | |  3 file file3 was initially added on branch v1_1.
  |/ /
  | o  2 MERGE from v1_0: add file2
  |/
  | o  1 add file2
  |/
  o  0 add file1 on trunk