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
