1. How can a user ask a working copy what range of minor versions it
supports? Cf. "Compatible With Version:" in `svnadmin info` output.
I see these:
% subversion/svn/svn info wc --show-item=wc-format
31
% subversion/svn/svn info wc --show-item=wc-format-min
31
% subversion/s
I guess I'm a little late to this discussion, but I just upgraded today
to the svn trunk and saw the new APIs.
From what I understand is that new clients can choose which WC format
to use during checkout/upgrade?
If that's correct, I'd like to propose a small enhancement:
* provide an env vari
Stefan Kueng wrote on Sat, Feb 19, 2022 at 16:11:59 +0100:
> I guess I'm a little late to this discussion, but I just upgraded today to
> the svn trunk and saw the new APIs.
> From what I understand is that new clients can choose which WC format to use
> during checkout/upgrade?
>
Yes. By defaul
On 19.02.2022 16:31, Daniel Shahaf wrote:
Stefan Kueng wrote on Sat, Feb 19, 2022 at 16:11:59 +0100:
I guess I'm a little late to this discussion, but I just upgraded today to
the svn trunk and saw the new APIs.
From what I understand is that new clients can choose which WC format to use
dur
On Sat, Feb 19, 2022 at 10:39 AM Stefan Kueng wrote:
> > This use-case is already supported by the use of the oldest WC format by
> > default, isn't it?
>
> ah, yes. If the oldest supported format is used then of course the env
> variable isn't necessary. I was under the impression that the newes
Daniel,
Thank you for reviewing multi-wc-format.
I think it would be good for us to be able to refer to the issue
tracker. I'll file a 'multi-wc-format' issue and we can add sub-issues
for changes we need or want.
https://subversion.apache.org/issue/4883 "multi-wc-format"
Daniel Shahaf wrote
[ Aside: in each of your paragraphs, every line other than the first
starts with a U+200B ZERO WIDTH SPACE. While replying $EDITOR renders
those as «<200b>» (six characters, and six terminal columns) by default. ]
Julian Foad wrote on Thu, Feb 24, 2022 at 13:59:08 +:
> Daniel Shahaf wrote:
>
On Feb 25 2022, Daniel Shahaf wrote:
>> [...] we are now deliberately choosing compatibility as the default,
>
> OK. However, in this case we should document this explicitly, since the
> book explicitly documents that «svn upgrade» would upgrade to the "most
> recent metadata format supported by
I can think of a number of further API clean-ups possible, related to
multi-WC-format support.
Commentary:
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
Julian Foad wrote on Wed, Mar 02, 2022 at 13:35:06 +:
> On Feb 25 2022, Daniel Shahaf wrote:
> >> [...] we are now deliberately choosing compatibility as the default,
> >
> > OK. However, in this case we should document this explicitly, since the
> > book explicitly documents that «svn upgra
Julian Foad wrote on Thu, Mar 03, 2022 at 10:53:13 +:
> I can think of a number of further API clean-ups possible, related to
> multi-WC-format support.
>
>
> Commentary:
>
> At first we were trying to keep knowledge of WC format numbers internal
> to libsvn_wc. However it seems clear to me
Daniel Shahaf wrote on Tue, Mar 08, 2022 at 12:29:42 +:
> Julian Foad wrote on Thu, Mar 03, 2022 at 10:53:13 +:
> > 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 al
On Mar 8 2022, Daniel Shahaf wrote:
>> By default Subversion will upgrade the working copy to a version
>> compatible with Subversion 1.8 and newer.
>
> Are we assuming that future minor versions (1.16, 1.17, etc.) will all
> continue to be able to read/write f31? This seems to be implied by
On Wed, Mar 9, 2022 at 2:53 PM Julian Foad wrote:
> This is why I think we should do at least one of:
>
> - require the exact first-introduced version (1.8 or 1.15)
> - rename the option to use a less ambiguous language, to something like
> '--wc-format-version=1.8' (meaning the version in which t
Den ons 9 mars 2022 kl 20:53 skrev Julian Foad :
> This is why I think we should do at least one of:
>
> - require the exact first-introduced version (1.8 or 1.15)
> - rename the option to use a less ambiguous language, to something like
> '--wc-format-version=1.8' (meaning the version in which th
Nathan Hartman wrote:
> Suggestion: The user provides the earliest SVN version with which they
> want compatibility, and SVN picks the latest WC format version that is
> compatible with it. [...]
And Daniel Sahlberg wrote:
>> Regarding how to handle --wc-format-version=1.9, I'm leaning towards
>>
Julian Foad wrote on Wed, Mar 09, 2022 at 19:53:12 +:
> On Mar 8 2022, Daniel Shahaf wrote:
> >> By default Subversion will upgrade the working copy to a version
> >> compatible with Subversion 1.8 and newer.
> >
> > Are we assuming that future minor versions (1.16, 1.17, etc.) will all
>
On Thu, Mar 10, 2022 at 5:59 AM Julian Foad wrote:
>
> Nathan Hartman wrote:
> > Suggestion: The user provides the earliest SVN version with which they
> > want compatibility, and SVN picks the latest WC format version that is
> > compatible with it. [...]
>
> And Daniel Sahlberg wrote:
> >> Regar
Daniel Shahaf wrote:
> + The upgraded working copy will be compatible with Subversion 1.8 and
> + newer (this default may change ...
Sure, +1, a bit clearer.
Also see Nathan's option-naming proposal at the end of this message.
>> Which WC format did our hypothetical user want? (Rhetorical.) The
Julian Foad wrote on Thu, Mar 17, 2022 at 11:10:32 +:
> Daniel Shahaf wrote:
> > + The upgraded working copy will be compatible with Subversion 1.8 and
> > + newer (this default may change ...
>
> Sure, +1, a bit clearer.
>
Committed.
> Also see Nathan's option-naming proposal at the end of
20 matches
Mail list logo
