And therein lies the rub with line-based source control software. It ceases to just be a tool for managing and documenting what the programmer does and begins to dictate what the programmer can and cannot do.

No longer is the maintenance prgrammer just concerned with making changes to fix bug or add new features, they also have to ensure that the do not 'upset' the source code control trail by making 'unnecessary' changes. Hence comments get left unchanged and go out of date; badly formatted code, incorrect indentation et al. must be left uncorrected. Obvious refactoring gets left undone if it is percieved to affect too large a portion of the codebase.

Not always and not everywhere, but "maintaning the integrity of the VCS change history" can take on too great a significance and become a major influence on what gets done and what does not.

20 years ago, I got to play a little with a piece of source control software that understood the C language syntax, and maintained projects at the language structure level. For example, if it was desirable to move a function from one file to another, the change history reflected that as the function having been moved, not the deletion of a bunch of lines from one file and the addition of a bunch of lines to another. And if a function was renamed, that was logged as the renaming of the function, and when commited, it threw up all the points of use of that function as conflicts that needed to be resolved before the commit would be accepted. Comment blocks were seen as single entities, and were 'attached' to the code they documented. They either moved with that code, or had to be deleted if the code was deleted.

Now that is source control.

Unfortunately, the company that wrote it went to the wall. They were simply unable to sell it, because it was too radical. People are too wedded to their 30 year old line-based tools and do not want to change.