Oh hell yes.
Jun. 29th, 2006 01:22 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kickahaSo as part of this death march in miniature, I'm having to submit a sufficicently chunky (~5kLOC) chunk of infrastructure code to a group of coders who aren't really design savvy. They're good functional coders, but large scale abstractions seem to give them a bit of fits.
So I wrote the original code in C++, for good reason. Got told no, they changed their minds, it needs to be done in C.
So I rewrite it in C.
Now I'm staring at this now ~8kLOC chunk of code (yes, there's a reason OO languages help you write more efficiently...) and wondering how the &*(%#$ I'm going to chop it up into meaningful incremental patches to give to them.
Because they won't accept a big patchbomb. (Ok, I can't blame them on that front, but it's damned annoying.) And each patch has to compile and pass regression testing. And they have to OK it. Which means it has to make sense to them. Dumping the whole thing at them is going to make them run in terra, so I have to lead them down the garden path gently.
So... how to go back to the original code, then artificially create patches that *lead to* the final design in a well-formed and meaningful way? Because my original design growth path won't work.
I'm using Subversion (it rawks my world) and have the C++ version off in its own branch, and the final C version in another, each moved out of trunk as it was finished.
The plan was to then start back with the original mostly blank slate from the group CVS repository (yes, it's under two management schemes right now - don't look at me that way, it works), and then start adding chunks as necessary, ensuring at each stage that it still worked. This has been, to put it lightly, a royal fucking pain in the ass.
Then it struck me just a bit ago.
Why not do it backwards?? Removing code should be easier to do than *adding* code, IMO.
Plop the *finished* C code into a new branch. Tag as Anti-Patch 0.
Remove a piece of code. Compile. Tag as Anti-Patch 1.
Remove another piece of code. Compile. Tag as Anti-Patch 2.
Continue this until I *end up at* the original code. Tag as original. Assume it takes M steps.
The last checkin prior to the original code will be Anti-Patch M-1. Retag this as Patch 1. Anti-Patch M-2 becomes tag Patch 2, and so until Anti-Patch 0 becomes Patch M.
Now... here's the fun bit. Start going *chronologically backwards* but *logically forwards* through the tags. Check out tag Patch 1. Send diff patch to CVS repository.
Check out tag Patch 2. Send as diff patch to CVS.
Continue this until I hit Patch M. At that point I can switch to the C branch (now moved into the trunk) and be on my merry way, with the CVS repository and my private SVN in sync. Use SVN to manage local changes until they're ready for submission, and then tag each as it goes to CVS.
This should be *much* easier... and at each publicly submitted stage, it looks like I did it on *purpose*. :D
Intelligent design? No, this is intelligent devolution.
So I wrote the original code in C++, for good reason. Got told no, they changed their minds, it needs to be done in C.
So I rewrite it in C.
Now I'm staring at this now ~8kLOC chunk of code (yes, there's a reason OO languages help you write more efficiently...) and wondering how the &*(%#$ I'm going to chop it up into meaningful incremental patches to give to them.
Because they won't accept a big patchbomb. (Ok, I can't blame them on that front, but it's damned annoying.) And each patch has to compile and pass regression testing. And they have to OK it. Which means it has to make sense to them. Dumping the whole thing at them is going to make them run in terra, so I have to lead them down the garden path gently.
So... how to go back to the original code, then artificially create patches that *lead to* the final design in a well-formed and meaningful way? Because my original design growth path won't work.
I'm using Subversion (it rawks my world) and have the C++ version off in its own branch, and the final C version in another, each moved out of trunk as it was finished.
The plan was to then start back with the original mostly blank slate from the group CVS repository (yes, it's under two management schemes right now - don't look at me that way, it works), and then start adding chunks as necessary, ensuring at each stage that it still worked. This has been, to put it lightly, a royal fucking pain in the ass.
Then it struck me just a bit ago.
Why not do it backwards?? Removing code should be easier to do than *adding* code, IMO.
Plop the *finished* C code into a new branch. Tag as Anti-Patch 0.
Remove a piece of code. Compile. Tag as Anti-Patch 1.
Remove another piece of code. Compile. Tag as Anti-Patch 2.
Continue this until I *end up at* the original code. Tag as original. Assume it takes M steps.
The last checkin prior to the original code will be Anti-Patch M-1. Retag this as Patch 1. Anti-Patch M-2 becomes tag Patch 2, and so until Anti-Patch 0 becomes Patch M.
Now... here's the fun bit. Start going *chronologically backwards* but *logically forwards* through the tags. Check out tag Patch 1. Send diff patch to CVS repository.
Check out tag Patch 2. Send as diff patch to CVS.
Continue this until I hit Patch M. At that point I can switch to the C branch (now moved into the trunk) and be on my merry way, with the CVS repository and my private SVN in sync. Use SVN to manage local changes until they're ready for submission, and then tag each as it goes to CVS.
This should be *much* easier... and at each publicly submitted stage, it looks like I did it on *purpose*. :D
Intelligent design? No, this is intelligent devolution.