[sldev] [META] indentation fixes/changes and merging (was: [IDEA][META]hg branch for trivial changes)

[Soft]

On Fri, May 1, 2009 at 11:40 AM, Boroondas Gupte
<sllists at boroon.dasgupta.ch> wrote:
> Soft schrieb:
>> On Fri, May 1, 2009 at 8:26 AM, Boroondas Gupte
>> <sllists at boroon.dasgupta.ch> 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.