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