Re: Merging bug (wrong conflicts)

[Jacob Burckhardt]

Karl Tomlinson writes:
> "Derek R. Price" wrote:
> > 
> > > Karl, do you know what, specifically, was causing the merging problems?
> > I can't come up with a minimal test case based on the message and comments 
> > in
> > your patch.
> > 
> > I'm thinking that the eight cases Jacob has might all be examples of only a
> > few or even one error case...  Is it possible to pare those down into one 
> > or a
> > few simple tests?

...

> The problem would only occur if the differences between versions
> were complicated enough so that there was more than one possible
> diff output.  All the examples of this problem I have seen have been
> quite large files, and the problem goes away on trying to reduce the
> size of the files.

Those large files would be in sanity.sh if we wanted to follow the
current system that sanity.sh uses to test merges.  The current system
is to echo the contents of the file and redirect the echo command to a
file.  For example:

echo "contents of
file to
be merged" > file_to_be_merged

So if the file to be merged is a big file, this will make
sanity.sh be much bigger, and sanity.sh is already a very big file, so
it would better to have small test cases.

But, if as you say, the bug goes away when you reduce the file, then
maybe we should try to find a practical way to keep the files big.
Here is one idea: Instead of creating the files to be merged by
echoing the contents of those files and redirecting, instead I propose
copying the file to be merged.  For example:

cp cvs/src/file_to_be_merged ${TESTDIR}/working_dir

I.e. the sanity.sh script would have a cp command instead of an echo
command.  It would copy the file from the cvs/src/ directory (the same
directory where sanity.sh is).

One problem with this idea is how sanity.sh figures out where this
directory is.  One solution might be to add a command line option to
sanity.sh to specify this directory.  But that would make the
interface to sanity.sh change and probably many people are used to the
existing interface and some people might have scripts to call it.  So
maybe changing the interface is a bad idea.

Another idea is to have sanity.sh use the expression $0 to get the
pathname of sanity.sh, and then it removes the sanity.sh from that
string which leaves it with the directory name.  Then it appends the
name of the merge file to that directory name to get the source
location for the cp command.  Of course even this assumes that
sanity.sh and the files to be merged are in the same directory.  It
will not work if someone moves sanity.sh to another directory.  But
maybe someone moving it is unlikely?

Please comment on these ideas.  If you prefer that I do not use the cp
idea, then I suppose I could try to reduce the size of the test cases
to where the echo command would be practical to use.  But remember that
Karl pointed out that reducing it is difficult.