Merge lp:~vila/bzr/split-diff-tests into lp:bzr
Proposed by
Vincent Ladeuil
Status: | Merged |
---|---|
Approved by: | Vincent Ladeuil |
Approved revision: | no longer in the source branch. |
Merged at revision: | 6601 |
Proposed branch: | lp:~vila/bzr/split-diff-tests |
Merge into: | lp:bzr |
Diff against target: |
136 lines (+43/-35) 2 files modified
bzrlib/diff.py (+13/-15) bzrlib/tests/test_diff.py (+30/-20) |
To merge this branch: | bzr merge lp:~vila/bzr/split-diff-tests |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Richard Wilbur | Approve | ||
Review via email: mp+236818@code.launchpad.net |
Commit message
Split some tests to be able to get finer grained failures
Description of the change
Some simple refactoring to get finer grained failures from tests.
I also noted that --forward-ed is not part of diff 3.3 and I'm wondering if
we really want to keep that option.
To post a comment you must log in.
Thanks, Vincent, for the improved granularity and specificity of the tests. The use of scenarios is powerful!
Regarding '--forward-ed' not part of diff v3.3:
How does diff v3.3 treat a command line which includes the removed option '--forward-ed'? Does it quietly ignore it or abort with an error code?
In either case, since the user is explicitly specifying the option, it seems benign to continue to regard it as a valid format option--at least as long as we are still supporting diff v3.2.
The other question to consider is, "How long would it be useful to support the diff v3.2 behaviour?" Ubuntu 12.04 has diff v3.2 while the first Ubuntu Linux release which includes diff v3.3 is 13.10.
1. If diff v3.3 quietly ignores the removed option, then we might regard it as important to determine which version of GNU diff is installed in order to either warn the user that this option no longer specifies a format or substitute '-u'. Maybe both.
2. If diff v3.3 aborts with an error message, then this will likely be a self-correcting problem--the user who explicitly specified the option will learn it is no longer supported and cease specifying that option on next invocation.
Regardless of these considerations, I approve of this patch.
+1