On Wed, Aug 15, 2012 at 12:03 PM, Carlos Rovira <carlos.rov...@codeoscopic.com> wrote: > ...In our case we have a core piece called UIComponent composed over 14-15k > lines of code that are "flex" itself. > > If we plan to refactor and rethink that core piece we will do over several > weeks until it was done. People doing it can't made in whiteboards and it's > not a one-man-task. > > This kind of task need to be done in team and with a SCM prepared for that....
I don't know the details of that issue, so I might be off-base but in general here's how I would tackle such a job: 1. Fork/branch the code and create a proof of concept prototype, to see more clearly what needs to change. Maybe several prototypes if people have different ideas. Make sure to concentrate on the core problem. 2. Review the differences between the prototype and trunk to see the impact 3. Discuss the best strategy for implementing the actual change, based on the proof of concept 4. Make sure the changed areas are covered by automated tests 5. Implement the changes, over a relatively short period of time as the proof of concept has shown how to do that, and hopefully its code can partially be reused. In this scenario 5. is where the bulk of the merging/refactoring happens in trunk - if it has big impact it might need some coordination to make sure enough manpower is available to make it happen with minimal disruption. I don't think using Git or svn makes much of a difference in such a scenario - 5. is going to be somewhat painful anyway. -Bertrand
