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
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
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
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
>
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
>>
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
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
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
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
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
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
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
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
[ 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:
>
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
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
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
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
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
19 matches
Mail list logo
