Doing massive source changes

[Tomáš Chvátal]

Hi,

I would recommend going with the last option,
when i looked on the reviews it is pretty mindless search and replace
so the only issue is to make sure the replace script wont bork stuff.

Cheers

Tom

2013/1/4 Lubos Lunak <l.lunak at suse.cz>:
>
>  Hello,
>
>  I have a patch that is 32M big and I rather wonder when to commit it.
>
>  The patch specifically is string rtl:: prefix removal. These changes
> regularly show up in gerrit patches for review, but I think we have somewhat
> better EasyHacks for new developers than rather mindless search&replace, and
> it's somewhat annoying to review such diffs as well. So instead I've done the
> change over the entire codebase where possible.
>
>  The problem is, the change is so extensive that it touches pretty much
> everything ("9117 files changed, 92833 insertions(+), 95662 deletions(-)").
> Given that we branched 4-0 a short time back, this will probably mean
> backporting will often need adjusting. So the options I see:
>
> - wait until before 4-1 branch-off (or do not do such a big change at all) -
> this would mean there still would be these changes done in small bits by
> other people (including the gerrit review overhead)
>
> - push now, only to master - this would mean more likely conflicts when
> backporting changes
>
> - push now, including to 4-0 - I can successfully do a full build, including
> make check, and I've avoided public API modules (sal, salhelper, cppu,
> cppuhelper, odk - any others?), so this hopefully should be safe, but most of
> the changes have been done using sed, so there may be something that I've
> missed
>
>  Does somebody have a preference? I consider the last one to be the best
> option.
>
> --
>  Lubos Lunak
>  l.lunak at suse.cz
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice