Comments posted to this topic are about the item Should your Source Control System understand your code?
Why would source control need to understand the code? That is the responsibility of the Programmer/s.
The advancements being made in languages is making entry into the Computation Sciences workforce much easier. As a result, there is a plethora of unqualified individuals coming into the field. By unqualified I mean individuals who:
-Have bad coding practices
-Lack discipline that is required to be a programmer
-Refuse to/Do not follow standards and design. Their errors usually go unchecked, even with code review, because management will not take the time to make them correct things if the code works. As a result the entire department deals with the fallout.
-Lack the fundamentals(knowledge of alternate number systems, ADT programming, SET Theory etc.)
-Think commenting is a waste of time
If a shop is scared of Branching and Merging because it impedes their ability to deliver rapidly then that tells me a few things.
1) They lack discipline
2) They lack the ability to put policies and procedures in place to support B&M as a result of 1.
3) They lack the backing from management to enforce 2 because of 1
From where I sit it takes much more time and is much riskier to use flags in code instead of B&M(It will also make the thought of merging scarier because of all the silly extra code). If a shop is so immature that it does this, I do not see how they can support concurrent projects on overlapping code without chaos.
Having said that I would like to see source control allow for a programmer to lock a version of code in one layer to a version of code to another. I.E. Lock a version of a stored procedure to a version of a Service that uses,
P.S. What would Automatic Testing accomplish that Unit Tests can't?
There are some processes that are better left to humans than forms of automation. I find that many people mistake the term "Source Control" for "Configuration Management". While "Source Control" is certainly an important part of "Configuration Management", it is not "Configuration Management" in and of itself. In the 34 years that I've been a part of the "public" world, I've worked with only one company that practiced anything close to what "Configuration Management" actually is. It was a major DOD company and it made fewer "Source Control" mistakes even in software than even some of the smaller companies I've worked for because of good and proper "Configuration Management".
Change is inevitable... Change for the better is not.
Viewing 3 posts - 1 through 2 (of 2 total)