Re: cvswrappers question

[David Carson]

Eric Siegerman <address@hidden> wrote in message news:<address@hidden>...
> On Fri, Sep 14, 2001 at 11:15:03AM -0700, David Carson wrote:
> > I have tried every method I know
> > about to prevent merging:
> > 
> > o  $CVSROOT/CVSROOT/cvswrappers
> > o  ~/.cvswrappers
> > o  <dir_to_file>/.cvswrappers
> > o  cvs update -W "-m COPY"
> > 
> > None of them seems to do anything at all.  
> 
> Which CVS version (client and server if appropriate)?  Which
> platform?  The usual basic support questions :-/
> 

server: 1.11.1p1 on Linux
client: 1.11 on cygwin (WinNT 4.0)

However, the cvswrappers seem to have no effect even if I do the
offending update on the server.

> > This leads me to believe I have misunderstood the meaning of the COPY
> > option.
> 
> I don't think so.
> 
> > Here is the situation: The file in question is text, not
> > binary
> 
> I would have thought COPY would work for this.  Hence the version
> question.  But then, some of the cvswrappers stuff doesn't work
> client/server.  Perhaps none of it does?
> 
> > but it gets modified during a build.
> 
> The usual recommendation is not to track generated files in CVS
> in the first place, but just let them get regenerated from
> scratch by the build process.  If necessary, change the
> architecture to make this possible.  That's one of the advantages
> of Autoconf'ed packages (including CVS itself) generating
> Makefile from Makefile.in, as opposed to Smail's (perhaps former)
> scheme of modifying the Makefile in place.
> 

Yes, I was expecting this response.  We could change -- and might at
some point -- but that is not the point.  I want to understand how
this is supposed to work and why it does not work for me.  By the way,
I have implemented a workaround for the time being: I made the file in
question binary.  Now, it will not merge as I had hoped for with -m
COPY (and, of course, does not do keyword subst. or EOL translation
either).

While on the subject of merging against the user's will:
I have just finished moving a group of developers from another version
control system to CVS.  One of the most popular questions is: How can
I update my tree so that CVS will _not_ perform the automerge? 
Granted, it may or may not make sense to do this.  I was just
wondering if there is a way to turn off automerge for a user's whole
working copy via an option.  (I expect someone will tell me to put "*
-m COPY" in my cvswrappers file!)  I think the fear is that automerge,
while it will work syntactically on the file, might introduce logical
inconsistencies in the file.  We are used to merging by hand, which is
tedious but allows users to use logic beyond the ability of automerge
in process.  Perhaps if CVS could invoke a user's own diff program (we
use Visual SlickEdit's diffzilla) when it encounters (1) any merge, or
(2) a conflict in a merge.