bug-cvs
[Top][All Lists]
Advanced

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

Re: [patch #4573] Fix for keyword expansion problem/mis-feature during c


From: Rahul Bhargava
Subject: Re: [patch #4573] Fix for keyword expansion problem/mis-feature during commit
Date: Mon, 28 Nov 2005 07:54:44 -0800
User-agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)

Hi Patrick -

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


Your comments and scenarios make total sense.  As you pointed out
the -k options today will allow pure data to reside inside the RCS
keywords. Usecases like the ones you described warrant a clear
separation.

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
branches.
If you read the initial post that was indeed the intent. I have played with
the patch in the context of merges (cvs updates) and it wont be hard to
use the keyword diffing algorithm to avoid spurious conflicts on keywords.
Also note the algorithm avoids loading up the entire file in memory unlike
the current CVS implementation.


Patrick Richardson wrote:

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:

EITHER
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!

OR
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,
not METADATA.

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
option?

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

   _______________________________________________________

Reply to this item at:

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

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





--
Rahul Bhargava,
CTO, WANdisco
(650) 242-8352
Mountain View, CA
http://www.wandisco.com





reply via email to

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