Breakpoints should not be stored in VIs

[MGiacomet]

The way breakpoints are stored (IN the VI!!!) makes working under source control very hard.

In every language I've worked before, breakpoints are items related to the debugging session (thus the debugger), not the source file. Storing breakpoint information in the VI makes it very hard to work under source control (as one is prompted to save a VI, just because a breakpoint was set.) Breakpoints should be stored in some other structure (the project perhaps) or, at least, if the only change to the VI is the breakpoint it should not require the VI to be checked out/saved.

[GuenterMueller]

I would suggest an enhancement to how breakpoints are stored in VIs. I personally prefer that breakpoints are a property of a VI and I would not like to see LabVIEW change this behaviour. My way of working: Before committing to source code control, I usually make sure that all breakpoints have been removed.

[MGiacomet]

Except that your way of working doesn't work with RT Targets... Deploying to an RT target (for debugging) requires that the file be saved.

[dan.p.sweeney]

I agree entirely with the original post.  Breakpoints are a property of the debug session, not the essence (source) of what a VI does.  It's an unnecessary and distracting headache to juggle them within the source control workflow.

[GregSands]

I like the idea that breakpoints could be a Project property.  I wonder how feasible that is?