Hi everyone, I have a general question about Subversion development and instead of assuming, thought I better seek an answer. Outside of my limited exposure as the PM - I have no Open Source coding experience - so there may well be an "expectation" of coding that I simply don't know about.
This email stems from the last paragraph in this message by Johan Corveleyn; Which I have copied into this email. If you're already familiar with the diff-optimisation you can get the full message here; http://svn.haxx.se/dev/archive-2011-01/0241.shtml And if you want some more background the full thread is here; http://svn.haxx.se/dev/archive-2011-01/0004.shtml and, http://svn.haxx.se/dev/archive-2011-01/0005.shtml which I was tempted to just reply to - but thought I had better not hijack the existing thread. To save you from having to find the post, here is the paragraph I'm referring to; > Actually, what's a little bit troubling is that there are currently > only 3 possible "file_len's", of which only 2 are used in practice: > diff2 and diff3 (diff4 is not used in svn core, only in > tools/diff/diff4). So, if we make a slow and a fast version, we could > just as well make a XXX2 and an XXX3 version explicitly, and dispense > with the need to pass arrays and array lenghts. Hmmm... generic (but > more complex) code vs. a couple of specialized versions. The goal of the thread / patch submission is to increase the speed of "diffing". So, does the design, truly, matter? As the underlying design of all software should be to create the simplest / cleanest / loosely-coupled code that addresses the problem. Surely the answer is; Man-power is limited - as long as you observe the coding guidelines / styles etc. Is the answer not; Code to the manner that provides the greatest return on a developer's time for THIS problem. Assuming the "specialised" version is indeed faster; If for whatever reason - it is decided that an API is required (public or private) - then an appropriate wrapper can be added when the specific requirement of having an API for those functions becomes a requirement as opposed to simply being a nice design goal to aim for upfront? As always - thanks for patience / assistance. Gavin.
