Testing/feedback wanted: Using dpkg-mergechangelogs in bzr-builddeb

James Westby james.westby at canonical.com
Thu Jul 7 23:58:13 UTC 2011


On Fri, 8 Jul 2011 09:16:53 +1000, Andrew Bennetts <andrew.bennetts at canonical.com> wrote:
> James Westby wrote:
> […]
> > bzrlib.plugins.builddeb.tests.test_merge_changelog.TestMergeChangelog.test_not_valid_changelog
> > 
> > This is testing what happens with an invalid changelog. I'm not sure
> > what the effect of returning "not_applicable" versus "success" with the
> > invalid text would be. I don't think it's a particularly important case
> > though.
> 
> “not_applicable” gives other merge hooks, including the default one
> (which is always applicable, but might conflict), a chance to try the
> merge.  The other outcomes (“success”, “conflicted” and “deleted”) are
> final result for the merge.
> 
> So that test is saying “if it's not a valid changelog, give up and let
> the default logic (or other plugins) merge it.”  I agree that that
> doesn't seem particularly important.  The main thing I think is that
> invalid changelogs shouldn't cause tracebacks or other completely
> unreasonable output (and *perhaps* ideally also produce a gentle warning).
> If so, “success” vs. “not_applicable” are both fine, assuming the
> apparent success isn't actually total garbage.

Yeah, sounds about right, given that it only acts on files called
"debian/changelog."

> another…” line.  BASE → THIS just adds “But more is better”.  So that
> output looks like a sensible and expected combination of those changes:
> it's what I'd do if I had to merge those by hand.  But as a VCS
> developer perhaps my sense of what's expected is skewed ;)
> 
> Given that one side does discard a line, do you still find it odd that
> the merge also discards that line?

I'm not sure now. I think I read it too quickly the first time, but your
explanation about sounds pretty convincing.

Thanks,

James



More information about the ubuntu-distributed-devel mailing list