Such a situation usually occurs for configuration purposes.  Configuration
parameters usually get set within makefiles and header files.

Therefore, if possible, factor out the configurable stuff into another file
(that's not in the repository) and include (possibly optionally) this file into
the file that is in the repository.  For example (assuming gnu makefiles):
Within makefile:
# set default makefile macros
...

# local makefile exists, include it
-include makefile.override

An alternative would be, say, to have a file MAKEFILE within the repository and
copy that file into something usable like Makefile.

I hope this helps.  If your situation isn't a configuration problem (or if the
above doesn't fit), a more in-depth description of your specific problem would
help.

Noel





[EMAIL PROTECTED] on 05/22/2000 12:25:33 PM

To:   [EMAIL PROTECTED]
cc:   (bcc: Noel L Yap)
Subject:  ignoring files




Is there a way to have a file checked into the repository but not let
subsequent check-ins check it in by default?  .cvsignore only seems to
work with files that are not already in the repository.

We have a few files that developers change for testing fairly often,
but these changes shouldn't go into the repository. Yes, it's easy to
just not check them in, but it would be even easier not have to worry
about it at all :)

I thought about doing something with commitinfo, but I don't know how I
would be able to tell if the changes were really supposed to be checked
in or not.

Thanks,
JR

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/






This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.

Reply via email to