Merge lp://staging/~hakan/calibre/calibre-pluginize-dirnames-0.9.1 into lp://staging/calibre
Proposed by
hakan
Status: | Needs review |
---|---|
Proposed branch: | lp://staging/~hakan/calibre/calibre-pluginize-dirnames-0.9.1 |
Merge into: | lp://staging/calibre |
Diff against target: |
410 lines (+193/-16) 7 files modified
src/calibre/customize/__init__.py (+66/-1) src/calibre/customize/builtins.py (+19/-1) src/calibre/customize/ui.py (+11/-1) src/calibre/library/database2.py (+32/-13) src/calibre/library/pathnames/__init__.py (+7/-0) src/calibre/library/pathnames/byauthor/__init__.py (+7/-0) src/calibre/library/pathnames/byauthor/strategy.py (+51/-0) |
To merge this branch: | bzr merge lp://staging/~hakan/calibre/calibre-pluginize-dirnames-0.9.1 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Kovid Goyal | Disapprove | ||
Review via email:
|
Description of the change
As described in http://
To post a comment you must log in.
Some issues:
1) No testing file_name( ) as well.
2) Breaks database restore, particularly in the case when the user changes pathname configuration on an already populated library
3) You have changed only the folder naming not the file naming. For that you would need construct_
Thinking about it some more, I am not really comfortable with making this part of calibre configurable. There is too much potential for data loss. The only way to mitigate that potential is to do comprehensive testing of new code + restore on multiple filesystem/OS combinations. I dont think the gain from having configurable path name generation is worth the effort that would be needed to implement that testing.
So I am refusing the merge, sorry. You are of course welcome to continue to use the code in your own calibre installs.