info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvswrappers question


From: Eric Siegerman
Subject: Re: cvswrappers question
Date: Fri, 14 Sep 2001 16:25:55 -0400
User-agent: Mutt/1.2.5i

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 :-/

> 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.

If there are other reasons for CVS-tracking this generated file,
first think again whether they're truly compelling.  If they
are:

> o  move the local copy to .#whatever and bring down the repository
> version
> o  complain that no merge is possible and do nothing

As a workaround, when you get a conflict, you can duplicate these
alternatives by:
  $ rm scrambled-file
  $ cvs update scrambled-file
or:
  $ mv .#scrambled-file.1.X scrambled-file
respectively.

--

|  | /\
|-_|/  >   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)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]