Merge lp:~vila/bzr/673637-temp-commit-file into lp:bzr
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | John A Meinel | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 5541 | ||||
Proposed branch: | lp:~vila/bzr/673637-temp-commit-file | ||||
Merge into: | lp:bzr | ||||
Diff against target: |
76 lines (+19/-15) 3 files modified
bzrlib/msgeditor.py (+9/-12) bzrlib/tests/test_msgeditor.py (+6/-3) doc/en/release-notes/bzr-2.3.txt (+4/-0) |
||||
To merge this branch: | bzr merge lp:~vila/bzr/673637-temp-commit-file | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
John A Meinel | Approve | ||
Review via email: mp+40625@code.launchpad.net |
Commit message
Create commit message files in TMPDIR instead of the current dir
Description of the change
This brings in the patch proposed for bug #673637 with some small tweaks to keep the test coverage.
The issue is that:
msgeditor.py creates the temporary log file in the directory where "bzr ci" is invoked,
which is normally inside the branch. When you save the log message inside Emacs, Emacs
runs "bzr status", because the log message file is in a versioned directory, and Emacs
tries to get its revision and status, to show that in the modeline. But because "bzr ci"
is still running, the branch is locked, and "bzr status" fails, this failing the commit.
Long story short: using the working directory for a temporary file is not needed there and the above is true only on windows so OLMD (bug #98836).
Since the previous related fix was about making sure we could create such files in a directory with a fancy name, I kept the test but tweaked it to still force a specified directory.
I'm "ok" with this fix. It seems to solve a problem that someone was having.
The concerns are:
1) it seems like the problem is actually in emacs, and we are papering around it in bzr rollback/ etc.)
2) It means that you won't use the cwd for staging the commit log, in case someone wants to save it off somewhere for later (in case of failure to commit/
3) I don't have any personal stake, because I always use "-m" and shell as my commit message editor. (With the other benefit that 'bzr diff' always continues to work.) As such, I don't have a feel for how this will impact people, since I don't use it.
4) I think this might also solve a bug people were having, where they wanted to commit it /etc, and had rights to /etc/.bzr but *not* rights to /etc/ itself. (sysadmins not wanting to commit as root, I guess.)
On the whole, I think I'm for it, just concerned about possible fallout.