Comments on: Pain vs Pay-Off http://www.symphonious.net/2008/05/28/pain-vs-pay-off/ Living in a state of accord. Tue, 02 Dec 2008 06:34:50 +0000 http://wordpress.org/?v=2.6.5 By: Adrian Sutton http://www.symphonious.net/2008/05/28/pain-vs-pay-off/#comment-160142 Adrian Sutton Thu, 29 May 2008 06:53:27 +0000 http://www.symphonious.net/?p=857#comment-160142 Smaller commits doesn't help all that much actually - even once you narrow it down to one file it's still a crap shoot as to what to fix and some things just need changes to multiple files. :) Yeah I did the diff thing yesterday with pretty limited success though it was an edge case because a lot of files had very small changes so line numbers changed in existing duplication all over the place. It's a cool idea though and it is definitely working to improve the code base - just got to get a decent report out of it somehow. Smaller commits doesn’t help all that much actually - even once you narrow it down to one file it’s still a crap shoot as to what to fix and some things just need changes to multiple files. :)

Yeah I did the diff thing yesterday with pretty limited success though it was an edge case because a lot of files had very small changes so line numbers changed in existing duplication all over the place.

It’s a cool idea though and it is definitely working to improve the code base - just got to get a decent report out of it somehow.

]]> By: Andrew Herron http://www.symphonious.net/2008/05/28/pain-vs-pay-off/#comment-160109 Andrew Herron Thu, 29 May 2008 00:35:11 +0000 http://www.symphonious.net/?p=857#comment-160109 My solution is to download the simian XML for the failing build and the last passing build (they're only about 1mb), then rather than viewing in a browser do a text diff between them. The problem with that is you have to diff between XML files generated on the same machine or the file locations don't match. It's incredibly annoying, and it doesn't solve trying to fix duplication before you check in - that's still a crapshoot. My solution is to download the simian XML for the failing build and the last passing build (they’re only about 1mb), then rather than viewing in a browser do a text diff between them. The problem with that is you have to diff between XML files generated on the same machine or the file locations don’t match.

It’s incredibly annoying, and it doesn’t solve trying to fix duplication before you check in - that’s still a crapshoot.

]]> By: Rob Dawson http://www.symphonious.net/2008/05/28/pain-vs-pay-off/#comment-160080 Rob Dawson Wed, 28 May 2008 20:39:37 +0000 http://www.symphonious.net/?p=857#comment-160080 smaller commits would help however ;) smaller commits would help however ;)

]]> By: Adrian Sutton http://www.symphonious.net/2008/05/28/pain-vs-pay-off/#comment-160017 Adrian Sutton Wed, 28 May 2008 10:32:16 +0000 http://www.symphonious.net/?p=857#comment-160017 Running it before you check in doesn't help - you still have to try and guess where the duplication is. Running it before you check in doesn’t help - you still have to try and guess where the duplication is.

]]> By: Doug http://www.symphonious.net/2008/05/28/pain-vs-pay-off/#comment-160015 Doug Wed, 28 May 2008 09:56:55 +0000 http://www.symphonious.net/?p=857#comment-160015 A simple solution would be to make sure you run the legacy-check before you commit, in the same way you run tests. Though I do agree that the reporting would be a far more effective solution. It might be possible for the check to keep better track of the changes and use this information to highlight new changes, but I'll need some more slack time to pull that one off. :) A simple solution would be to make sure you run the legacy-check before you commit, in the same way you run tests. Though I do agree that the reporting would be a far more effective solution. It might be possible for the check to keep better track of the changes and use this information to highlight new changes, but I’ll need some more slack time to pull that one off. :)

]]>