Community
Participate
Working Groups
Could we have a facility for preventing CVS commits to resources with errors or warnings. Such a facility should ideally be controllable from the Team\CVS preferences tree and consist of two checkboxes - [ ] Allow commit of resources with warnings [ ] Allow commit of resources with errors. By default both of these options should be switched on, in which case the CVS system performs as it currently does. Switching off either of these two checkboxes results in the appropriate files not appearing in the CVS window in the outgoing mode view.
I think this would be useful but I think the default shoudl be for errors to be on and warnings to be off by default. If a team doesn't want a particular type of warning committed, they can just switch the Java (or other tool) preference for that problem to be an error. Also, I think it is dangerous to exclude elements with errors. Either we abort the operation or prompt the user to adsk them if they are sure they want to commit the errors (i.e. if I am working on a branch, I may decide that committing errors is OK). We could probably offer options similar for what we do for empty commit comments.
The reason I requested this feature for warnings as well as errors is that my current boss has a policy of not committing anything with warnings. Could we have a three options for both warnings and errors ? 1. Commit 2. Confirm commit 3. Never commit. And set it to 1 by default (which would leave default behaviour as it is now) ?
That makes sense. The options could be 1 for both of them and teams could tailor them as they see fit.
We won't have time to address this in 3.2
*** Bug 12580 has been marked as a duplicate of this bug. ***
We should also consider prompting if there are other projects in the workspace with errors since the errors may be caused by what is being committed.
We do not plan on addressing this issue in 3.3.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
