Why can't I be paid per LOC?
-
Just checked in a revision containing a bunch of refactoring and pluginification carried out over the past 3 days. In those 3 days, I touched 105,000 lines out of this 150,000 line codebase. The lines that I didn't touch are almost entirely within Whatever.Designer.cs files (i.e. Visual Studio autogenerated code) and thirdparty.dll (where, oddly enough, we keep miscelleneous third party code).
And yes, this did constitute a single atomic change. One change required one restructuring, which required another, which required yet another restructuring, etc. - and any one of those layers would have broken the whole thing if it were applied without the others. I did incidentally fix a few other defects along the way, most of them caused by the cumbersome way in which data was handled and passed around.
Since this is TDWTF, TRWTF is that the database isn't under version control.
-
@Weng said:
Just checked in a revision containing a bunch of refactoring and pluginification carried out over the past 3 days.
In those 3 days, I touched 105,000 lines out of this 150,000 line
codebase. The lines that I didn't touch are almost entirely within
Whatever.Designer.cs files (i.e. Visual Studio autogenerated code) and
thirdparty.dll (where, oddly enough, we keep miscelleneous third party
code).And yes, this did constitute a single atomic change. One change required one restructuring, which required another, which required yet another restructuring, etc. - and any one of those layers would have broken the whole thing if it were applied without the others. I did incidentally fix a few other defects along the way, most of them caused by the cumbersome way in which data was handled and passed around.
Since this is TDWTF, TRWTF is that the database isn't under version control.
Are they taking regular backup of databsae?
If yes, version control is not necesary.
If they pay by LoC, they will have to hire one person to count all line of codes that you touched Better they pay by hour or day.
-
@Nagesh said:
Are they taking regular backup of databsae?
If yes, version control is not necesary.
He's probably referring to the database schema, not the data itself. And yes, the schema should definitely be in the source control.
-
@blakeyrat said:
@Nagesh said:
Are they taking regular backup of databsae?
If yes, version control is not necesary.
He's probably referring to the database schema, not the data itself. And yes, the schema should definitely be in the source control.
Yes and No. The schema should be in there, but if you can restore from backup, you will get your schema + data back.
You can use restore to some non-production instant, to get copy of everything.Also some DBA are very fond of encrypting all object. If that is case, then she should definately use version control.
-
@Nagesh said:
Yes and No. The schema should be in there, but if you can restore from backup, you will get your schema + data back.
The point of putting the schema in source control isn't for restoring backups, but for being able to quickly create new deployments. When you get that critical error, you need to be able to repro it as quick as possible, and involving a DBA in the process is going to slow it way down.
-
@blakeyrat said:
and involving a DBA in the process is going to slow it way down.
A DBA? You mean 'one of the developers that knows how to use SQL Server Management Studio', right? Because that's all we've got.There's no change control on the trunk database. Make your changes in the database, make them on the code, and commit it ASAP so your changes don't interrupt anyone else (for long)
Personally, I'd have used a Visual Studio DB project so it falls under source control, but I wasn't here at the time the SSMS decision was made.
-
@Weng said:
Personally, I'd have used a Visual Studio DB project so it falls under source control, but I wasn't here at the time the SSMS decision was made.
Depending on what you do for source control Microsoft SSMS (nice accronym) does support project files full of scripts hooking into source control, so do your SQL stuff that way.
-
@locallunatic said:
@Weng said:
Personally, I'd have used a Visual Studio DB project so it falls under source control, but I wasn't here at the time the SSMS decision was made.
Depending on what you do for source control Microsoft SSMS (nice accronym) does support project files full of scripts hooking into source control, so do your SQL stuff that way.
Yeah, but it's a real pain in the ass to actually use that way. I dunno, maybe it fits your workflow, but I gave up trying to use SSMS projects and just ad-hoc it now.
-
@blakeyrat said:
Yeah, but it's a real pain in the ass to actually use that way. I dunno, maybe it fits your workflow, but I gave up trying to use SSMS projects and just ad-hoc it now.
True, most of my SQL changes are tweaks to stored procedures (so it's easy to script as drop if it exists and then a create), but I can see how regularly modifying schema would be problematic.
