##// END OF EJS Templates
largefiles: access to specific fields only if largefiles enabled (issue4547)...
largefiles: access to specific fields only if largefiles enabled (issue4547) Even if largefiles extension is enabled in a repository, "repo" object, which isn't "largefiles.reposetup()"-ed, is passed to overridden functions in the cases below unexpectedly, because extensions are enabled for each repositories strictly. (1) clone without -U: (2) pull with -U: (3) pull with --rebase: combination of "enabled@src", "disabled@dst" and "not-required@src" cause this situation. largefiles requirement @src @dst @src result -------- -------- --------------- -------------------- enabled disabled not-required aborted unexpectedly required requirement error (intentional) -------- -------- --------------- -------------------- enabled enabled * success -------- -------- --------------- -------------------- disabled enabled * success (only for "pull") -------- -------- --------------- -------------------- disabled disabled not-required success required requirement error (intentional) -------- -------- --------------- -------------------- (4) update/revert with a subrepo disabling largefiles In these cases, overridden functions cause accessing to largefiles specific fields of not "largefiles.reposetup()"-ed "repo" object, and execution is aborted. - (1), (2), (4) cause accessing to "_lfstatuswriters" in "getstatuswriter()" invoked via "updatelfiles()" - (3) causes accessing to "_lfcommithooks" in "overriderebase()" For safe accessing to these fields, this patch examines whether passed "repo" object is "largefiles.reposetup()"-ed or not before accessing to them. This patch chooses examining existence of newly introduced "_largefilesenabled" instead of "_lfcommithooks" and "_lfstatuswriters" directly, because the former is better name for the generic "largefiles is enabled in this repo" mark than the latter. In the future, all other overridden functions should avoid largefiles specific processing for efficiency, and "_largefilesenabled" is better also for such purpose. BTW, "lfstatus" can't be used for such purpose, because some code paths set it forcibly regardless of existence of it in specified "repo" object.

File last commit:

r20741:f1dfef0a default
r24158:d414c28d stable
Show More
test-install.t
26 lines | 866 B | text/troff | Tads3Lexer
Pradeepkumar Gayam
tests: unify test-install
r11917 hg debuginstall
$ hg debuginstall
Martin Geisler
debuginstall: lowercase status messages
r16934 checking encoding (ascii)...
Matt Mackall
debuginstall: change showing to checking for consistency and future checking
r20741 checking Python executable (*) (glob)
checking Python version (2.*) (glob)
Adrian Buehlmann
debuginstall: show directory for Python lib...
r17392 checking Python lib (*lib*)... (glob)
Martin Geisler
debuginstall: lowercase status messages
r16934 checking installed modules (*mercurial)... (glob)
checking templates (*mercurial?templates)... (glob)
checking commit editor...
checking username...
no problems detected
Pradeepkumar Gayam
tests: unify test-install
r11917
hg debuginstall with no username
$ HGUSER= hg debuginstall
Martin Geisler
debuginstall: lowercase status messages
r16934 checking encoding (ascii)...
Matt Mackall
debuginstall: change showing to checking for consistency and future checking
r20741 checking Python executable (*) (glob)
checking Python version (2.*) (glob)
Adrian Buehlmann
debuginstall: show directory for Python lib...
r17392 checking Python lib (*lib*)... (glob)
Martin Geisler
debuginstall: lowercase status messages
r16934 checking installed modules (*mercurial)... (glob)
checking templates (*mercurial?templates)... (glob)
checking commit editor...
checking username...
Matt Mackall
ui: suggest config --edit when no username is set
r20574 no username supplied
Martin Geisler
Merge with stable
r12084 (specify a username in your configuration file)
Pradeepkumar Gayam
tests: unify test-install
r11917 1 problems detected, please check your install!
Matt Mackall
tests: add exit codes to unified tests
r12316 [1]