Concurrent Versions System - Patches: patch #4573, Fix for keyword expansion...
You are not allowed to post comments on this tracker with your current authentication level.
patch #4573: Fix for keyword expansion problem/mis-feature during commit
Submitter: | Rahul Bhargava <b_rahul> | ||
Submitted: | Fri 28 Oct 2005 09:28:53 PM UTC | ||
Votes: | 100 | ||
Category: | None | Priority: | 9 - Immediate |
Status: | Wont Do | Privacy: | Public |
Assigned to: | None | Open/Closed: | Closed |
Fixed Release: | None | Fixed Feature Release: | None |
Jump to the original submission
Thu 16 Feb 2006 02:17:21 PM UTC, comment #19: |
Derek Robert Price <dprice> |
Sat 11 Feb 2006 12:56:50 AM UTC, comment #18: I think Mark's example about lost PERL code is a compelling argument for leaving the status quo. Your patch bypasses the inconvenience of extraneous checkins at the expense of potentially losing valuable information.
|
Jim Hyslop <jhyslop> |
Sat 11 Feb 2006 12:03:39 AM UTC, comment #17: It is really unfortunate that this bug will not be fixed. There has been no response to the case I made two and a half months ago FOR fixing the bug. It absolutely blows my mind that the CVS maintainers will not even consider implementing this patch as a non-default option.
|
Patrick Richardson <patjr> |
Tue 22 Nov 2005 10:19:52 PM UTC, comment #16: Here, for what it's worth is an end-user's perspective:
|
Patrick Richardson <patjr> |
Tue 15 Nov 2005 10:33:20 PM UTC, comment #15: Rahul Bhargava <rahul@wandisco.com> writes:
|
Mark D. Baushke <mdb> |
Tue 15 Nov 2005 09:55:37 PM UTC, comment #14: Which 100s of companies would those be? Perhaps some of their representatives would care to pipe up and provide example use cases as well as explaining why they can't ask their developers to stop changing keyword values?
|
Derek Robert Price <dprice> |
Tue 15 Nov 2005 09:26:10 PM UTC, comment #13: FEATURE branch already has the ability to disable
|
Mark D. Baushke <mdb> |
Tue 15 Nov 2005 08:03:03 PM UTC, comment #12: This isn't what I meant to suggest. I meant to suggest that your original patch be thrown away in favor of a patch that implemented:
|
Derek Robert Price <dprice> |
Tue 15 Nov 2005 04:32:03 PM UTC, comment #11: Derek Wrote:
|
Rahul Bhargava <b_rahul> |
Thu 10 Nov 2005 04:40:14 AM UTC, comment #10: Except that this is not a bug. CVS is working as designed. One of the primary design goals of all CVS development is to NEVER, EVER, EVER, EVER, EVER, EVER, EVER, EVER, EVER, EVER, throw away data. Even when merging local changes with changes from the server, CVS first creates a permanent backup file before editing changes into the local copy.
|
Derek Robert Price <dprice> |
Thu 10 Nov 2005 12:18:26 AM UTC, comment #9: This bug should be fixed for the following reasons:
|
Harry Muller <hmuller_adm> |
Wed 09 Nov 2005 03:51:05 PM UTC, comment #8: Another thought on uneducated users: not only do they probably only need to be educated about this once, but an admin can correct the keyword mode on an offending file once and never worry about that file again. Users uneducated about keywords and keyword modes are unlikely to change the keyword substitution mode back to the offending mode. |
Derek Robert Price <dprice> |
Wed 09 Nov 2005 03:40:06 PM UTC, comment #7: I believe that the behavior should be left as is for the following reasons:
|
Todd Denniston <tdennist> |
Wed 09 Nov 2005 03:01:19 PM UTC, comment #6: I'm not ready to change my mind but, please, vote for this patch using the Savannnah interface. We don't have an official policy about how to deal with user votes yet, but at least it will help track how popular bug fixes and features are. There are also several other maintainers who could outvote my single rejection vote, though this discussion appears to have failed to attract their attention as of yet. |
Derek Robert Price <dprice> |
Wed 09 Nov 2005 03:19:11 AM UTC, comment #5: The behavior implemented by the proposed patch is what I would like for our CVS deployment. The workarounds you suggest require user discipline (consistent use of -k* options, for example) and are therefore very problematic for a large team such as ours (we have our fair share of relatively inexperienced CVS users)
|
Harry Muller <hmuller_adm> |
Fri 04 Nov 2005 10:21:01 PM UTC, comment #4: The behavior implemented in this patch is something an organization could reasonably want. It is usually not practical, especially with a large and diverse development team, to impose a disciplined use of cvs command options across the entire team. Mistakes will happen. It would be much more desirable to implement the desired behavior in the server.
|
Yeturu Aahlad <aahlad> |
Fri 04 Nov 2005 07:31:42 PM UTC, comment #3: The data loss you refer to only occurs in the user's sandbox. The change is committed to the repository. If the original user or another user were to checkout/update the file in -kb or -ko modes, then they would see the data they committed. In fact, this could be used as a workaround for the problem you describe - if only the user in question wants to see their local changes inside key-values after commit, then they should mark text files -ko on checkout/update and binaries -kb. If all users should see what the user committed inside key-values, then `cvs add' or `cvs admin' should be used to mark the files default keyword mode as -ko or -kb. Either of these is even a more fine-grained solution than yours, since it allows this behavior to be selected on a file-by-file basis.
|
Derek Robert Price <dprice> |
Fri 04 Nov 2005 04:13:19 PM UTC, comment #2: Hi Derek -
|
Rahul Bhargava <b_rahul> |
Fri 04 Nov 2005 03:21:50 PM UTC, comment #1: I do not think it is CVS's place to second-guess the user here. It would be one thing if this was happening automatically due to some action on CVS's part, but if the user altered the keyword contents, then we must assume they intended to, regardless of the fact that a normal checkout would overwrite the change. A checkout using -kb or -ko could still retrieve the committed data. Ignoring the user's action is almost certainly not the correct course of action here.
|
Derek Robert Price <dprice> |
Fri 28 Oct 2005 09:28:53 PM UTC, original submission:
THE PROBLEM
|
Rahul Bhargava <b_rahul> |
Depends on the following items: None found
Items that depend on this one: None found
There are 100 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 7 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2005-11-22 | patjr | Carbon-Copy | - | Added patjr | |
2005-11-09 | b_rahul | Carbon-Copy | - | Added b_rahul | |
2005-11-09 | hmuller_adm | Carbon-Copy | - | Added hmuller_adm | |
2005-11-04 | dprice | Status | None | Wont Do | |
Open/Closed | Open | Closed | |||
2005-10-28 | b_rahul | Attached File | - | Added kwdiff.tbz2, #5393 | |
Carbon-Copy | - | Added -email is unavailable- |
Powered by Savane 3.13-cf05.
Corresponding source code
Pat, in your use cases, the user cannot "[control the server] metadata", spuriously or otherwise. The server will still substitute the correct keyword information on checkout, provided the user did not actually delete the keywords from the file, which this patch would not prevent.
The difference is that, currently, if a misguided user checks in a change after editing the keyword information in the file, it can still be recovered. After this patch, this would no longer be possible. The "very simple guarantee" guarantee we are attempting to provide is that user changes cannot be permanently lost.
Also, your second example, where a bug fix from a contractor contains differing RCS keyword information can be fixed by any of several simple procedural fixes: 1. Have your contractor send a diff rather than copies of every file, 2. import drops from your contractor into a special tree and generate the same diffs yourself, 3. use vendor branches to import code drops from your contractor.