v2t9402: sed -i is not portable

On some systems sed allows the usage of e.g. sed -i -e "s/line1/line2/" afile to edit the file "in place". Other systems don't allow that: one observed behaviour is that sed -i -e "s/line1/line2/" afile creates a backup file called afile-e, which breaks the test. As sed -i is not part of POSIX, avoid it.

Use test_cmp, makes the test easier to debug. Chain all shell commands with && to detect all kinds of failure.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
Changes since v1:
No correction of TABs to make it easier to review

If this is OK: Matthew would you like to send a complete re-roll, because the credit should be on you ?

 t/t9402-git-cvsserver-refs.sh | 44 ++++++++++++++++++++++---------------------
 1 file changed, 23 insertions(+), 21 deletions(-)

Torsten Bögershausen <tboegi@web.de> writes:

Thanks.

The intention is good, but see comments on this part in the patch below.

I see a few other remaining issues in the code after this patch is applied. If we are doing other fixes like these, we may want to fix them as well:

 - test_must_fail is used to run cvs; it shouldn't (instead of
   saying "test_must_fail cvs ...", just say "! cvs ...").

 - A shell function should begin like this: "shellfunc () {"

 - Redirection should not have SP before the filename (i.e. ">out",
   not "> out").

 - It is OK to spell single-liner subshell like this:

    ( cd cvswork3 && ! cvs -f diff -N -u ) &&
    ...

   but a multi-line subshell should start its first command on a
   separate line, like this:

    (
        cd cvswork3 &&
        cvs update foo
    ) &&
    ...

 - quite a few "[cvswork$n]" comments are truncated to "[cvswork$n"
   in the test titles.

I think you missed the one in 'merge early [cvswork3] b3 with b1' where a merge is done in a subshell; a failed merge is not detected.

This is another reason why I asked you not to mix different things in a single patch; if this patch is rerolled to cover missing "&&" that you missed, it needs to be re-reviewed for the "sed -i" fix we review during this round again.

You replaced the original "find" that was perfectly correct with "pipe to grep -v" which is more expensive. Why?

The file stores the lines to be counted; why is it called a "Count"?

As "check.list" is really the "expected list of files", it may want to be renamed to "list.expected" or something like that. Then the output from this "find" would naturally become "list.actual", i.e.

	find "$sandbox" -name CVS -type d -prune \
            -o -type f -print >"$WORKDIR/list.actual"

Even though you are comparing only the number of lines in the file in this function, are they expected to name the same set of paths? The other function check_end_full_tree used to compare only the count, but you changed it to compare the actul names of paths, which may be a more robust and correct test, so it might make more sense to redefine $WORKDIR/list.{expect,actual} to be a sorted list of paths relative to the top of the working tree and do something like this:

	(
        	cd "$sandbox" &&
	        find . -name CVS -type d -prune -o -type f -print
	) | sed -e "s|^./||" | sort >"$WORKDIR/list.actual"

and make sure "$WORKDIR/list.expect" is also sorted. Then you can lose the "wc -l" based check from here and compare the list of paths.

It is probably easier for a later patch to fix the indentation, if these new lines followed the existing indentation.

You can say "git ls-tree --name-only -r" and lose the sed.