[patch #4573] Fix for keyword expansion problem/mis-feature during commit

[Mark D. Baushke]

Follow-up Comment #15, patch #4573 (project cvs):

Rahul Bhargava <rahul@wandisco.com> writes:

> We are already aware of this feature. If you
> read the initial post, we are not talking about
> disabling keywords or excluding certain keywords
> using CVS from feature branch.

I guess I missed the initial context. My apologies
for not paying closer attention.

> We are talking about the mis-feature that causes
> CVS to bump up revisions when a user commits a
> file which only differs in keywords.

This is not a mis-feature. It is the correct and
documented behavior.

I have known sites which favored this method of
doing 'forced' commits over use of the 'cvs commit
-f' option. Granted, I would hope those folks have
now moved to using 'cvs import -X' for the
purpose, but nevertheless, it was in operational
use explicitly.

CVS should never discard what might be important text
out of a file during a commit.

> The proposed patch preserves the admin's ability to use
> keywords without creating spurious versions on the tree.

Hmmm... This strikes me as an undesirable feature.

> We speak for 100s of companies using CVS today who would
> like to get the submitted patch as an optional feature in
> CVS.

That is an impressive number of companies. Do they all really
believe that CVS should be told to discard text they have put
into the file never to be able to retreive it again?

> No we are not asking that default behaviour be changed.

Okay.

> Iff an admin wants the behaviour we outlined in
> the initial post they can enable ignoring of
> keywords during classification phase of commit.

This seems like a dangerous knob to me. I have
seen more than one person using a PERL script who
has accidentally 'LOST' text because it turned out that
the text for the program they had working got munged
because CVS RCS keyword expansion broke their code
on checkout. They were able to retrieve the text
by doing a 'cvs update -ko -p file > file' and then
having a 'cvs admin -ko file' and committing without
any further loss of time or money.

Had an admin configured your new option, they
would have completely lost the information inside
of the keywords for all time.

Or, do I still misunderstand the feature?

> If an admin/user wants to use $..$ for their own
> needs they do not have to turn on the feature!

You lost me. I do not understand this sentence.

> All works as before. Again this is being
> proposed as an optional behavior, no need to
> change semantics if you don't want.

Let us look at user visible impact and tell me what
you are trying to accomplish.

A user is looking at a file and accidentally
modifies the $Id: ...$ text to use '1.14' instead
of '1.141' and saves it. The line looks like this:

my $VERSION =
    sprintf("%s", q$Id: file,v 1.14 2005/09/12 21:03:09 mdb Exp $
            =~ /(\d+\.\d+)/);

It should be noted that this 'spurious' difference
is actually a highly significant one that might
cause problems to users of the script who need
features that behave different in 1.14 of the file
versus 1.141 of the file.

What is the expected behavior for the following
operations?

  - cvs update

    Does the user see that a change has been made to the file?

  - cvs update -C

    Does the user's accidental change get reset?

  - cvs diff

    Does the user see that a change has been made to the file?

  - cvs commit

    If the change is just the change to the $Id$
    line, one presumes that the commit to the file
    would not occur. However, if the file
    contained an additional change to the text,
    would the text between the $Id: ... $ also be
    committed, or would it be silently lost?

My feeling is that a careless user needs to accept
the consequences of his actions and that the
behavior of CVS continues to be correct.

However, I suppose that I can see where an
administrator may find it desirable to know that a
commit only has changes to the RCS keywords in a
file and possibly make a decision as a part of the
commitinfo trigger concerning this situation to
enable them to fail the commit of the file in this
case.

So, if you want to propose a contrib/kwdiff
directory that contains a portable C89 program
that would let a user add kwdiff to their
environment such that commitinfo could be used to
run it and determine if the file being committed
only had that kind of change, then I would have no
big problems with the idea. Note that I would
probably consider that two files that differ only
in the RCS keywords to be the non-zero exit case
rather than two that are idential...

I hope I have understood the case correctly.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?func=detailitem&item_id=4573>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/