History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: IDEABKL-5490
Type: New Feature New Feature
Status: Open Open
Priority: Normal Normal
Assignee: Unassigned
Reporter: Mark Schnitzius
Votes: 0
Watchers: 0
Available Workflow Actions

Mark as Stalled
Operations

If you were logged in you would be able to see more operations.
IDEA: Backlog

Feature request: ability to place markers in file that prevent check in to source control

Created: 17 Sep 08 11:35   Updated: 24 Oct 08 19:40
Component/s: Version Control Integration
Affects Version/s: None
Fix Version/s: None

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown

Build: 1
Severity: Low


 Description  « Hide
On our project we have a checkstyle key word that always causes a checkstyle failure. So, you can put a comment reading //NOCHECKIN on any line and it will cause the checkstyle to fail. We add this to lines such as debug prints that we don't want to ever check in – the checkstyle failure reminds the user to delete (or revert) whatever temporary change was done.

It would be great to have this feature generalized for any type of file. If it was a feature of the IDE (similar to a breakpoint), then the user wouldn't have to modify the file in any way to prevent a dodgy bit of code being checked in – they could just place a marker. That's the broad strokes of the idea – we've found our little hack implementation of it quite useful here, and I'm sure if it were cleanly integrated with the tool it would become a handy feature for the community at large.



 All   Comments   Work Log   Change History      Sort Order:
Dmitry Jemerov - 17 Sep 08 13:43
How is such a marker different from creating a changelist called "Do not commit" and moving the files you don't want to commit into that changelist?

Mark Schnitzius - 18 Sep 08 04:34
That would work similarly, I guess. The main differences would be:
1. Granularity. The markers would be line-based as opposed to file-based, so you could know exactly which lines (possibly more than one per file) needed to be fixed.
2. Moving such a file to a different change list might quite easily cause it to be forgotten when you go to check in the changes from the original change list, with a high probability of breaking a build.