Merge lp:~jameinel/bzr-builddeb/changelog-parser into lp:bzr-builddeb
| Status: | Merged | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Merged at revision: | not available | ||||||||
| Proposed branch: | lp:~jameinel/bzr-builddeb/changelog-parser | ||||||||
| Merge into: | lp:bzr-builddeb | ||||||||
| Diff against target: |
609 lines (+271/-269) 2 files modified
merge_changelog.py (+104/-222) tests/test_merge_changelog.py (+167/-47) |
||||||||
| To merge this branch: | bzr merge lp:~jameinel/bzr-builddeb/changelog-parser | ||||||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Robert Collins (community) | 2010-02-03 | Approve on 2010-02-04 | |
|
Review via email:
|
|||
| John A Meinel (jameinel) wrote : | # |
- 402. By John A Meinel on 2010-02-03
-
Make sure that the blocks are in sorted order before we do anything else.
- 403. By John A Meinel on 2010-02-03
-
Fix bug #516060, implement 3-way changelog merge.
This uses a fairly crude 3-way changelog merge algorithm, but doesn't yet
introduce conflicts. That will be next, as it requires an api bump.
If left != right, then we check if the version is in base, and if
one side is identical to base, then we pick the other.
This doesn't:
a) Conflict when left != right != base
b) Allow deleting entries (present in base & this but not other, for instance)
etc. - 404. By John A Meinel on 2010-02-03
-
Conflict when appropriate.
We could try to do a textual merge, but it is just easier to
conflict on the whole region. Mostly because merge3.Merge3 is missing
a decent api for telling whether there was a conflict region :(.
| John A Meinel (jameinel) wrote : | # |
I just updated this branch. I was going to submit a separate proposal, but I did find a bug here, and just fixed it while doing the rest.
Anyway, this now does 3-way merging of the blocks. The basic logic is:
1) Find all blocks in THIS, OTHER and BASE
2) For all blocks in THIS and OTHER, include them in the output in sorted order.
3) If THIS and OTHER both contain a block (matched by Version) with different content, compare against the BASE content
a) If THIS == BASE, chose OTHER
b) if OTHER == BASE, chose THIS
c) If BASE is not present, or BASE is different from both, conflict
What this is missing:
1) If THIS or OTHER deletes a block it will be restored. (I assume that if a version is in THIS or OTHER then you always want it in the output)
2) 3c could use merge3.Merge3() to try to do a textual merge of the conflicted region.
I can open bugs on those two bits if you want.
- 405. By John A Meinel on 2010-02-03
-
Simplify the conflict logic slightly.
| Robert Collins (lifeless) wrote : | # |
On Wed, 2010-02-03 at 22:19 +0000, John A Meinel wrote:
>
> What this is missing:
>
> 1) If THIS or OTHER deletes a block it will be restored. (I assume
> that if a version is in THIS or OTHER then you always want it in the
> output)
> 2) 3c could use merge3.Merge3() to try to do a textual merge of the
> conflicted region.
>
> I can open bugs on those two bits if you want.
--
please do
-Rob
- 406. By John A Meinel on 2010-02-03
-
Trying to trigger the invalid code, only to find bugs in python-debian :(
| Robert Collins (lifeless) wrote : | # |
review: approve
On Wed, 2010-02-03 at 20:19 +0000, John A Meinel wrote:
>
> + elif right_block is None:
> + next_block = left_block
> + left_block = step(left_blocks)
> ...
> + elif left_block.version > right_block.
> + # left comes first
> + next_block = left_block
> + left_block = step(left_blocks)
The None and > cases are the same - I think it would be shorter to group
them.
elif right_block_is None or left_block.version > right_block.
-Rob
| John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert Collins wrote:
> Review: Approve
> review: approve
>
> On Wed, 2010-02-03 at 20:19 +0000, John A Meinel wrote:
>> + elif right_block is None:
>> + next_block = left_block
>> + left_block = step(left_blocks)
>> ...
>
>> + elif left_block.version > right_block.
>> + # left comes first
>> + next_block = left_block
>> + left_block = step(left_blocks)
>
>
> The None and > cases are the same - I think it would be shorter to group
> them.
>
> elif right_block_is None or left_block.version > right_block.
>
> -Rob
>
>
I believe I've updated to that style in more recent patches. But I'm
also trying to address some of James's concerns about always being
active. I'm trying to get Strict handling and fallback to regular
processing working (only to find that Strict isn't properly triggering
in some edge cases... :(
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkt
50gAn02X+
=271q
-----END PGP SIGNATURE-----
- 407. By John A Meinel on 2010-02-04
-
Sort out some more details for the 3-way merge code.
The main problem I was running into was that the constructor always suppressed parse failures.
| James Westby (james-w) wrote : | # |
I think what I would like to do is use strict=True and then let
merge3 do the merge if we can't parse it. That way we won't drop
text if we can't parse it.
Thanks,
James
| James Westby (james-w) wrote : | # |
Oh, it already has code for that, but I don't understand the comment
# BASE lines don't end up in the output, so we allow strict=False
Would it also be good to note to the user when we tried to merge but
it failed due to parsing?
Thanks,
James
| John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James Westby wrote:
> I think what I would like to do is use strict=True and then let
> merge3 do the merge if we can't parse it. That way we won't drop
> text if we can't parse it.
>
> Thanks,
>
> James
>
That is what I ended up with. I don't know if the current diff shows that.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkt
Bh0Anit1wIn+
=h8Ig
-----END PGP SIGNATURE-----

This removes the guts of the Changelog parsing code that I brought in, and replaces it by just importing debian_ bundle. changelog and having that do the parsing.
I don't really like depending on cl._blocks, but since import_dsc is doing so, I assumed that was the best we could do.
The tests all still pass, and the parsing is going to be as accurate as python-debian's parsing, which is what import_dsc uses anyway.