[darcs-users] [patch203] Implemented all 13 possible symlink handling scenarios...

[Trent W. Buck]

Trent W. Buck <trentbuck at gmail.com> added the comment:

Thanks for extending these tests, Dmitry.

Dmitry Astapov wrote:
> -darcs init      --repo R S      # Create our test repos.
> +mkdir -p R S                    # Create our test repos.
> +(cd R; darcs init)
> +(cd S; darcs init)

Mea culpa.  That should be

    darcs init --repo R
    darcs init --repo S

> +darcs --version

Superfluous.

> +# Rationale: Since darcs does not version-control symlinks, it should do a
> +# Sensible Thing handling them.
> +# All these tests are passed with darcs-2.2

This belongs in the introductory comment at the top of the file.

> +touch log
> +add_to_boring '^log$'

It's a reasonable idea to do this up-front to avoid log causing false
positives/negatives.  A better idea might be to simply use ../log
(i.e. store the buffer outside the repo).

> -echo 'Example content.' > f
> -darcs rec -lamf                 # business as usual...
> -ln -s f l                       # darcs should just ignore l
> -not darcs add -qr .             # add -r never had -l's problem.
> -darcs w -l >log                 # w -l shouldn't "see" the link.
> -grep 'No changes!' log
> -darcs rec -laml >log            # rec -l shouldn't record it.
> -grep 'No changes!' log
> -cd ..

Above, I made sure to check add, w -l *and* rec -l, since currently
their behaviour seems inconsistent.  The new version only tests w -l;
I think that is insufficient.

> +[ -z "$(grep -vE "(^ *$|a ./non-recorded-dir)" log)" ]

grep's exit status is meaningful; you should trust it instead of
wrapping in a [ -z "$()" ].

> hunk ./tests/failing-issue1645-ignore-symlinks.sh 129
> +# Case 12: link to device file
> +ln -s /dev/zero l

Should also test what happens when the device file occurs within the
repo (cp -a it in, I guess).

                                * * *

Suggest ref. symlink(7) and path_resolution(7) in introduction.
Suggest testing

 - dangling symlinks.
 - absolute (cf. relative) links.
 - historical drive letter idiom "/../C/vms".
 - links that cross filesystems.
 - symlinks to hard links.
 - case-folding links, e.g. ln -s Makefile makefile.
 - links to char vs. block devices.
 - links to Solaris "door" inodes?
 - links to sockets.

Suggest referring to "regular file" to disambiguate, since technically
directories and such are also files.

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch203>
__________________________________