RE: Info-cvs Digest, Vol 5, Issue 5

[Matthew Herrmann]

To force a Makefile file to be uncommitable, but still stay more-or-less
up-to-date with the current branch, you could put this in your build script:

"
cp Makefile Makefile_
cvs up -C -rANY_FIXED_TAG Makefile
cp Makefile_ Makefile
rm Makefile_
"

Then if anyone tries to commit changes to the file, they will get an error
since they are committing to a non-sticky tag.

And of course, never use "cvs tag" to tag versions if you are using this
technique (use "cvs rtag" instead).

HTH

Matthew Herrmann
--------------------------------------
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/

------------------------------

Date: Wed, 02 Apr 2003 10:28:08 -0800
From: Steve Madsen <address@hidden>
To: CVS-II Discussion Mailing List <address@hidden>
Subject: Re: Ignore local changes?
Message-ID: <address@hidden>
In-Reply-To: <address@hidden>
References: <address@hidden>
Content-Type: text/plain; charset=us-ascii; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 6

Wade Williams wrote:
> I can't imagine I'm the only developer that makes local changes to try
> something out, but wants to be sure those changes do not end up in the
> repository.

You're not the only developer that has had to deal with a problem like this.
  I agree with others who have said that allowing CVS to circumvent its own
controls is not a wise idea.

My advice is to be more specific when you commit.  You don't need to commit
from the top-level of your project.  You likely already know where you made
changes you do want to commit.  If you've arranged your tree well, this
configuration file should be somewhere else.  In this case, commit closer to
the real changes and CVS won't try to also commit your configuration
changes.

If you happen to make changes in the same place as the configuration file,
then commit files one by one.

--
Steve Madsen <address@hidden>
Tadpole Computer, Inc.  http://www.tadpole.com