Re: cvs update; merge

[Eric Siegerman]

On Wed, Aug 29, 2001 at 01:42:31PM -0400, Jimm Grimm wrote:
>       I updated my cvswrappers file to look like:
> *.* -k 'b'
> * -k 'b'
> *.txt -m MERGE
> 
> But this doesn't seem to do any good.  In cvs.pdf, it says the -m option is
> for non-binary files, so I guess I shouldn't expect this to work.

1. cvswrappers is searched linearly; the first match wins, so
   your *.txt line is never reached.

2. As you suspect, "-k 'b'" overrides "-m MERGE", so even if you
   reorder the lines, it won't help.

>       What do you suggest I do?  We make lots of binary files (test
> vectors) with all sorts of extensions, and have both win32 and linux
> platforms.  It is impossible to predict what extensions will be binary or
> what machines they will be on, but we sure don't want any to get messed up
> if they are mistaken for ASCII.  At the same time, we do want to be able to
> merge ASCII source code.

Can you at least guarantee that *.txt are text files?   If so,
put something like this into your cvswrappers:
        *.txt -k 'kv'
        * -k 'b'

or, for *.txt, whichever other -k value makes sense for you.

If you can't guarantee that, have cvswrappers treat *everything*
as binary:
        * -k 'b'
and manually change the setting for each text file:
        cvs admin -k<whatever> foo.txt bar.txt ...
You can specify a -k value at add time:
        cvs add -k<whatever> foo.txt
but you'd better test that before depending on it.  Of course one
of these needs doing every time someone adds a new text file, but
if things are as disorganized as you imply, there's not much
choice.  At least this way it fails safe...

Of course I have to ask why you can't get people to stick to some
standard set of extensions for test-vector files.  Seems as though
that'd make life easier for humans, not just for CVS...

>       Is there any way to get CVS to ignore CRLF conversions, yet still do
> merges?

By "ignore CRLF conversions", do you mean not do them, and just
copy the file byte-for-byte?  If so, I don't think you can get
that behaviour along with merging.  All three other combinations,
but not that one.  The assumption is that if the file is
mergeable, it's text and thus needs CRLF conversions -- CVS's
merge algorithm is inherently line-oriented, after all.  (The
converse doesn't hold; some text files that need CRLF conversion
aren't (meaningfully) mergeable; I think the save formats for
some CAD programs are an example.)

What do your test files look like, that merging would would make
sense for them, but CRLF conversions wouldn't?

> I hope I am not touching a sore spot...

Oh, several :-)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)