Branko Čibej wrote on Mon, 26 Nov 2018 05:38 +0100: > I really like the idea of 'svn ls -vH' as a sort of mnemonic of 'ls -lh'. > Note that whilst the actual option letters are different -- on > purpose, we had a long discussion about -v vs. -l a long time ago -- the > use of single-letter options in this case would be nice. I suspect -H > would be used almost as often as -v, but no-one would probably bother > with --human-readable. (OK, bash-completion helps.)
I don't run 'svn ls' often. > >> I'd though about adding a --base-10 flag, so '-H' is base-2 units and > >> '-H --base-10' would use base-10 units. I do think that the default > >> should be base-2, because users are probably more used to thinking that > >> way. Well, at least programmers are, and they are, after all, the main > >> users of version control. > > I'm not a fan of having one flag modify another flag's meaning. I'd prefer > > > > --base=2 > > --base=10 > > Not so bad. I'd call it --unit-base then, to avoid confusion with number > bases. > > > (we needn't support other values (except perhaps --base=1 for the 1.11 > > behaviour)) > > ?:\ Which behaviour? The default behaviour: printing the filesize as an integer (possibly with thousands separator). Mathematically, base-2 means the printed value N stands for N * 2**foo, so the 1.11 behaviour is equivalent to --unit-base=1. It might be clearer to just call it --unit-base=none. > > I suppose we could then have --human-readable as "currently, an alias to > > --base=10", with an option to extend it --- like 'diff --patch-compatible'. > > I like this approach. But I'd make --human-readable === --unit-base=2, > for reasons already mentioned. Sorry, yes. In context of filesizes base-2 as default makes sense. >