Daniel Shahaf wrote on Fri, Mar 18, 2022 at 01:16:48 +0000: > Daniel Shahaf wrote on Thu, 17 Mar 2022 23:02 +00:00: > > Daniel Shahaf wrote on Tue, Mar 08, 2022 at 10:57:17 +0000: > >> Julian Foad wrote on Wed, Mar 02, 2022 at 13:04:51 +0000: > >> > Daniel Shahaf wrote: > >> > > multi-wc-format/BRANCH-README mentioned this: > >> > > > >> > >> [*] New externals working copies must inherit the format from their > >> > >> parent working copy, because [...] > >> > > > >> > > Upgrading a parent working copy upgrades external wc's too. However, > >> > > upgrading an external succeeds. Judging by the quoted remark, should > >> > > «svn upgrade --compatible-version=$N /path/to/external» error out > >> > > unless > >> > > the external's parent working copy is already at version $V? > >> > > >> > It isn't clear to me whether allowing it or disallowing it is more > >> > "right". > >> > > >> > Can anyone else chime in? > >> > > >> > >> Hmm. Considering that «svn update» recurses into externals by default, > >> but that nothing recurses upwards into parent wc's by default, perhaps > >> we should design things around making sure these two cases continue to > >> work? I.e., disallow selective upgrades that might make another > >> client's «svn update» of the outer wc fail because the outer wc and the > >> external wc are different formats? > >> > >> Following this train of thought, we'll forbid upgrading an external > >> without also upgrading a parent wc, but will entertain patches to make > >> «svn upgrade» _not_ descend into external wc's by default, should anyone > >> submit such. (I don't propose we add this ourselves for the MVP.) > >> > > > > Another perspective: If we aren't sure, we should make upgrading an > > external an error i n1.15, because that leaves users a workaround > > (upgrade the parent wc) and we can make it a non-error in the future, > > whereas if 1.15 allows upgrading only the external wc, backwards > > compatibility with that would be expected. > > > > If anyone thinks «svn upgrade /path/to/wc/path/to/external» should be > > allowed, do speak up.
In second (or third) thought: Isn't this orthogonal to the multi-wc-format work? To date it has always been possible to upgrade an external without upgrading its parent [1], and thereby make the parent not «svn update»able by older clients (cf. points (a) and (b) from multi-wc-format's BRANCH-README as quoted in SVN-4890's OP [2]). The fact that the client doing the upgrade has multi-wc-format support doesn't affect this logic. This would argue towards leaving SVN-4890 open, but making it not block SVN-4883. Cheers, Daniel [1] The test posted to SVN-4890 raises SVNExpectedStderr if run in trunk against 1.14.1, implying that upgrade succeeds. [2] [*] New externals working copies must inherit the format from their parent working copy, because mixed-format working copies are a) a Bad Thing, and b) defeat the purpose of this feature, which is support for multiple versions of the client in the same working copy. > How would one make «svn upgrade foo/bar» a failure if foo/bar is an > external within something? I guess by calling > svn_dirent_basename("foo/bar") and then running some svn_wc_* API on > that, but which? The same one that «svn status --depth=empty» uses, or > is there a better one? > > Thanks, > > Daniel