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. Cheers, Daniel > Cheers, > > Daniel > > > In the meantime, I filed your question as > > https://subversion.apache.org/issue/4890 > > > > - Julian > >
