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.

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

Reply via email to