[Top][All Lists]

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

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

From: Patrick Richardson
Subject: [patch #4573] Fix for keyword expansion problem/mis-feature during commit
Date: Tue, 22 Nov 2005 22:19:53 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

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

Here, for what it's worth is an end-user's perspective:

In the context of a given file, I want one of two things:

RCS keywords are disabled - $DATE: xxx$ is data - not metadata. I absolutely
DO NOT WANT the server mucking with what may appear to be an RCS keyword. For
these files, I want a very simple guarantee - each new revision represents a
change (any change) to the file.

Example 1. I am writing an article on RCS keywords

Example 2. My strange, in-house scripting language has syntax elements that
can easily be confused for RCS keywords.

I can get this today with the appropriate sticky -k option. No problem!

RCS keywords are enabled - $DATE: xxx$ is metadata - not data. I want the
server AND ONLY THE SERVER controlling the content of the metadata. I want a
dependable mechanism to protect the repository from spurious (usually
accidental) user changes to the metadata. For these files, I want a very
simple guarantee - each new revision represents a change to the file DATA,

Example 1. I have scripts that analyze the RCS metadata in the repository,
and publish information to a relational database. This information is then
used in generating reports including some elaborate productivity statistics.
We don't want records of spurious checkins influencing these reports.

Example 2. Jane had received a bug fix from a contractor. The cover letter
accompanying the code drop said that only three files have changed. The
contractor uses an RCS-savvy source-code repository (perforce, cvs ...) Jane
checked out a clean sandbox, untarred the contractor's code-drop over that,
subjected the result to our QA processes, and did a global checkin. Yikes -
although the bug fix affected only three files, all 723 files were revved up,
because of differences in RCS keyword content. Every engineer trying to check
in a change encountered a conflict, even if the change was not to one of the
three files changed by the contractor. When they synced up with the
repository, they saw 720 spurious updates. The proposed patch here would have
been a god-send.

To summarize, I am asking for clear-cut exclusive ownership of RCS keywords -
either ONLY the user or ONLY the server should be allowed to dictate their
content for a given file. The default keyword-handling behavior of CVS does
not give me this clean sepatation today - an RCS keyword field is neither
strictly metadata nor strictly data. CVS with this patch gives me exactly
what I want. With this patch, I can ensure that an RCS keyword is strictly
metadata by default.

In this message, I am making the case for a clean model where an RCS keyword
is either just metadata or just data. If there is a case for the mixed model,
i.e., the status quo - one based on plausible use-cases, not historical
precedent - it has not been made. Even if such use-cases exist, why would one
object if this patch can be enabled or disabled by a simple configuration

Finally, another nuisance for us is interference from RCS keywords when we
merge branches. It would be cool if the work done in this patch could be
extended in the future to disregard metadata differences when merging CVS


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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