Daniel Shahaf wrote on Tue, Mar 08, 2022 at 12:29:42 +0000: > Julian Foad wrote on Thu, Mar 03, 2022 at 10:53:13 +0000: > > In exposing WC format numbers in the APIs, certainly we should treat > > them as opaque identifiers with no intrinsic meaning to their numeric > > value. We could of course also introduce non-numeric identifiers for > > them, for avoidance of 'magic constants' in source code. > > > > I'm not sure I understand what you have in mind here. Suppose we have > a non-numeric identifier SVN_WC_F31, what now? The cmdline client would > need either to have a --format-31 [sic] flag or to accept a string and > map it to SVN_WC_F31. The former is a pattern we switched away from in > «svnadmin upgrade». The latter adds a layer of indirection, but what
s/upgrade/create/ > is gained by that? How is having svn(1) pass SVN_WC_F31 an improvement > over having it pass the int «31»? > > > At first we were trying to keep knowledge of WC format numbers internal > > to libsvn_wc. However it seems clear to me now that we need to expose > > them. The rest of the system does need to know about different formats. > > Compatible-version numbers are not such good identifiers because a range > > of version numbers maps to each single format (even though there is one > > version number where the format was first introduced). To be more > > specific, our UI currently accepts > > '--wc-compatible-version=1.14.0-alpha' to specify the format introduced > > in 1.8; that mapping is not one-to-one, leading to slightly awkward > > input and output semantics and conversion APIs, quite possibly already > > having inconsistencies. > > Would you elaborate? This is the one sentence in this long paragraph > that actually explains _why_ you think the API should be written in > terms of format numbers rather than version numbers (as opposed to > stating that that is your opinion), and it's not very specific. Sorry, I didn't mean to be this critical. > What are the awkward semnatics? What are the inconsistencies? What > questions would API users be able to answer for themselves if we hand > them format numbers, that they can't easily answer with trunk@HEAD? Cheers, Daniel
