Merge lp:~abentley/bzr/is_executable into lp:bzr
Status: | Merged |
---|---|
Approved by: | John A Meinel |
Approved revision: | no longer in the source branch. |
Merged at revision: | 5555 |
Proposed branch: | lp:~abentley/bzr/is_executable |
Merge into: | lp:bzr |
Prerequisite: | lp:bzr/2.2 |
Diff against target: |
121 lines (+46/-5) (has conflicts) 6 files modified
bzrlib/revisiontree.py (+1/-1) bzrlib/tests/per_tree/__init__.py (+1/-0) bzrlib/tests/per_tree/test_is_executable.py (+37/-0) bzrlib/tests/test_transform.py (+3/-3) bzrlib/workingtree_4.py (+1/-1) doc/en/release-notes/bzr-2.3.txt (+3/-0) Text conflict in bzr Text conflict in bzrlib/__init__.py Text conflict in doc/en/release-notes/bzr-2.3.txt |
To merge this branch: | bzr merge lp:~abentley/bzr/is_executable |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
John A Meinel | Approve | ||
Review via email: mp+42204@code.launchpad.net |
This proposal supersedes a proposal from 2010-11-30.
Description of the change
Hi all,
This branch fixes RevisionTree.
the same way as other Tree implementations-- to return False rather than None.
The revised behaviour is also consistent with RevisionTree.
This problem filters up and affects Launchpad's incremental diffs for merge
proposals (which are disabled until this issue can be resolved), causing them
to erroneously report property changes on directories and symlinks
that have not changed.
Three tests have been affected, but FWICT, they were testing actual behaviour,
not desirable behaviour. Specifically, the ROOT_ENTRY should only be included
in iter_changes-style output when it has changed, when it has a new child, or
when include_unchanged is specified.
The fix itself seems good.
(I already said this on IRC, but for the benefit of people looking at this page) The change to behaviour seems in principle reasonable, but I'd be nervous about landing it in the stable branch. I'm not sure how likely this is, but it's at least plausible that a plugin might be depending on the root entry being emitted in that case. So my preference is to land this just on lp:bzr.
One extremely minor nit is that the preferred way to do locking and addCleanup is now as a one-liner:
self. addCleanup( tree.lock_ read(). unlock)
So if you wish, you could make that tweak, but it's not a big deal at all.
I'm going to vote "Abstain" because the key decision about whether to land this on 2.2 is up to the RM rather than a reviewer, I think.