On Fri, May 1, 2009 at 11:40 AM, Boroondas Gupte <[email protected]> wrote: > Soft schrieb: >> On Fri, May 1, 2009 at 8:26 AM, Boroondas Gupte >> <[email protected]> wrote: >> >>> If I remember correctly, Linden Lab once discouraged us from sending them >>> indentation-only patches, because the overhead to review and import them was >>> too much in relation to the benefit of such changes. Instead we should clean >>> up code while working on the specific parts for bigger bugs of features. >>> This is quite some while ago, so I don't know if that's still the current >>> recommendation. >>> >> >> The problem with indentation patches isn't review, it's merging. >> >> If 200 lines in one file are indented, they all show up as changed. >> What happens when that's merged with a branch without the indentation >> change, but where one line in that soup of 200 was changed? It's very >> likely that the change with a code effect will get lost without a >> very, very careful eye. > Hmm ... indeed. Forgot about that one. :-( >> It's also going to slow down the merge, which >> extends our critical path. >> >> LL's own future move to mercurial or better merge tools may change >> that. The remaining question would then be review time. Right now, a >> bunch of formatting changes wouldn't make it back to the tree, though. >> > I fear hg (or any other modern SCM) won't help very much here, as their > automatic merging is still line-based, so this will almost always > trigger a merge conflict to be resolved manually. I wonder how other big > projects handle this issue, as keeping false indentation in the code > until the specific part of code is touched for another reason can't be > the proper solution.
Honestly, I think they handle it by not having branches spend so long diverged from trunk/. The chances of merge conflicts go up exponentially with the number of changes made independently. Better compartmentalization of the code would also help. It would become more likely that cleanup changes could be made in the branch where other development on that code is happening. The take-away I get from this is that cleanup is hard if the code is already poorly structured. So that underscores the importance of cleaning up code when touching the code for other purposes. Maybe this means the best way for you to go forward with your project would be to look for ways to link pools of janitorial work to other patch submissions touching the same code. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
