launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #04402
Re: New coding standard for formatting imports
Jeroen Vermeulen wrote:
[...]
> I'm not married to the notion that the lists have to be generated at
> build time; the same work could well be triggered from the editor.
> I'm just worried that editor tools would leave us with the spurious
> merge conflicts, whereas taking the imports out of revision control
> would fix them.
As mentioned elsewhere in this thread, you can write custom merge hooks
for bzr. It would be entirely possible to write one that can automate a
merge of changes to imports in a Python file, similar to how the
news_merge plugin that is distributed with bzr works. Aside from
parsing the Python, the logic of doing a 3-way merge on a set of adds
and deletes is quite simple[*]. Perhaps such a bzr plugin could share
some code with an editor plugin. And speaking as a bzr dev the more
real-world use our hooks get the better for bzr.
That said, the new sorted, one-per-line style will help reduce spurious
conflicts a great deal, so the situation is already about to improve
significantly. So perhaps it's not worth spending much time to improve
it further. I don't suppose anyone has any stats on many conflicts
Launchpad devs have to resolve in e.g. an average week? Or how many PQM
requests are rejected due to conflicts?
-Andrew.
[*] It'd be harder to automatically get right the case of “one side deletes
an unused import, the other side adds some code that uses it,”
because it involves analysing more than just the changes to the
imports. But a) I bet that's a very rare case in practice, and b)
pyflakes already provides a way to automatically detect that case,
so it can be solved if someone cared enough.
References