From: Panayotis K. <pan...@pa...> - 2009-10-13 23:31:50
|
On 14 Οκτ 2009, at 1:49 π.μ., Sascha Haeberling wrote: > Hi Panayotis, > > first of all, I think the earlier you have a patch that is > consistent and doesn't break anything, the better it is. If the > patch is too large it will take us too long to review it. So I think > it is your responsibility to try to break the patch down into > manageable chunks. > > 390.000 lines of code sounds strange to me. Does this include a > bunch of auto-generates empty stubs? > > // Sascha No, but it had some refactoring, since as I said I separated the view of the GUI elements from the model, and so the public methods (of the GUI elements again) are clear and reflect what they really support. They are not really 390K of code, since diff puts some extra headers in the beginning and in the end. A typical diff -ruN xmlvm xmlvm.patched | grep '^\+' | wc gives ~5600 lines of code The changes now are in *so* many places that I don't think it's possible to make smaller patches. I can only break it into (e.g.) patches for obj-c support library and patches for xmlvm core itself. But I'm not sure if this will help at all :) I can not even distinguish the patches for the demos, since some of them depend on the support library PS: I tried to upload the patch to http://xmlvm-reviews.appspot.com/ new but every time I select a file I get an error message saying Patch set contains no recognizable patches PS2: Is there already a tool to create auto-generated empty stubs? Because I am coding one right now, and if there is it will save my time. |