On Wed, Aug 4, 2021 at 6:58 AM Bert Huijben wrote:
> Historic note:
> A long time ago we had to be very strict not to do this, as some major
> Subversion hosting provider (of which I don't know the name) just copied a
> blank repository to create new repositories. So all repositories hosted
>
Historic note:
A long time ago we had to be very strict not to do this, as some major
Subversion hosting provider (of which I don't know the name) just copied a
blank repository to create new repositories. So all repositories hosted
there had the same UUID.
(And they couldn't just 'fix' this, as
Thanks a lot for fixing these! And kudos for giving the case-by-case details ☺
On Tue, Apr 20, 2021 at 5:02 PM Daniel Shahaf wrote:
>
> Nathan Hartman wrote on Tue, Apr 20, 2021 at 16:07:58 -0400:
> > On Tue, Apr 20, 2021 at 3:29 PM Daniel Shahaf
wrote:
> > > (Aside: those 's don't have the self-link pilcrows that all
other 's do.)
> >
> > Good catch! That's fixed in
Daniel Shahaf wrote:
> Release notes text for 1.15.html (or possibly 1.16.html)? An API
> erratum in notes/? Is either of these needed?
I don't think this needs an API erratum. We should pick up the change in the
change log and perhaps release notes as part of the usual process. I don't
Julian Foad wrote on Tue, 20 Apr 2021 13:58 +00:00:
> This appears to complete the issue. Do say if I have missed something.
Release notes text for 1.15.html (or possibly 1.16.html)? An API
erratum in notes/? Is either of these needed?
Cheers,
Daniel
Nathan Hartman wrote on Tue, Apr 20, 2021 at 16:07:58 -0400:
> On Tue, Apr 20, 2021 at 3:29 PM Daniel Shahaf wrote:
> > (Aside: those 's don't have the self-link pilcrows that all other
> > 's do.)
>
> Good catch! That's fixed in r1889033 now :-)
Thank you!
I have now looked for other
On Tue, Apr 20, 2021 at 3:29 PM Daniel Shahaf wrote:
> (Aside: those 's don't have the self-link pilcrows that all other
> 's do.)
Good catch! That's fixed in r1889033 now :-)
I don't have specific input (yet) about the SVN-4874 changes but since
I'm running a trunk build as my "daily driver"
Daniel Shahaf wrote:
> There's actually an svntest.main.SVN_VER_MINOR constant to test. [...]
Huh. So there is. All by itself with no _MAJOR sibling, and used only in
relation to the server-minor-version test option.
Thank you. Done and tested (with 1.15-dev, and by changing the constant
Julian Foad wrote on Tue, 20 Apr 2021 13:58 +00:00:
> Julian Foad wrote on 2021-04-14:
> > If we are not looking at back-porting it to 1.14.x, then we could
> > [...]
> > - use the checks in libsvn_client; add a new 'notification' type for
> > the warnings
>
> That way was easiest and didn't
Julian Foad wrote on 2021-04-14:
> If we are not looking at back-porting it to 1.14.x, then we could
> [...]
> - use the checks in libsvn_client; add a new 'notification' type for
> the warnings
That way was easiest and didn't require much boiler-plate code at all. Done in
Daniel Shahaf wrote:
> > > #if (SVN_VER_MAJOR > 1 || SVN_VER_MINOR >= 16)
> > (in which I assume you meant MINOR >= 15)...
>
> I assumed it would be a warning in 1.15 and an error in 1.16.
Oh, OK. I was thinking nearer term (back-porting to 1.14.x as a warning, then
error in 1.15), but I
Julian Foad wrote on Wed, 14 Apr 2021 07:34 +00:00:
> Re. this suggestion to issue a warning:
> > #if (SVN_VER_MAJOR > 1 || SVN_VER_MINOR >= 16)
> > hard_error();
> > #else
> > warning();
> > #endif
> (in which I assume you meant MINOR >= 15)...
>
I assumed it would be a warning in 1.15
Re. this suggestion to issue a warning:
> #if (SVN_VER_MAJOR > 1 || SVN_VER_MINOR >= 16)
> hard_error();
> #else
> warning();
> #endif
(in which I assume you meant MINOR >= 15)...
Meh. This is library code. We can't just issue a warning in-line. We don't
have a generic warning
Daniel Shahaf wrote:
> Julian Foad wrote:
>> [...]. I wouldn't want to see
>> us introduce any half-measure, but only a full policy of "we
>> distinguish repositories by their UUID rather than any given URL, in
>> all cases" which should include non-merge cases such as diff as well,
>> and I think
Daniel Sahlberg wrote on Sun, 11 Apr 2021 10:59 +00:00:
> Den fre 9 apr. 2021 kl 22:20 skrev Julian Foad :
> > Daniel and Daniel, thanks for your replies.
> >
> > Responding in summary, after taking all your points and questions into
> > consideration.
> >
> > 1. I agree with softening this to
Daniel Sahlberg wrote:
> Would this be something that should go in the "Most wanted" list in
> https://subversion.apache.org/roadmap.html?
Not in my opinion.
- Julian
Den fre 9 apr. 2021 kl 22:20 skrev Julian Foad :
> Daniel and Daniel, thanks for your replies.
>
> Responding in summary, after taking all your points and questions into
> consideration.
>
> 1. I agree with softening this to be a warning rather than a hard error in
> a patch release, and then a
Julian Foad wrote on Fri, 09 Apr 2021 20:20 +00:00:
> 1. I agree with softening this to be a warning rather than a hard error
> in a patch release, and then a hard error in 1.15. I hadn't thought of
> doing a preprocessor-based time-bomb; good idea. I will retract my
> backport until I have
Daniel and Daniel, thanks for your replies.
Responding in summary, after taking all your points and questions into
consideration.
1. I agree with softening this to be a warning rather than a hard error in a
patch release, and then a hard error in 1.15. I hadn't thought of doing a
Julian Foad wrote on Wed, Apr 07, 2021 at 11:33:35 +0100:
> Daniel Shahaf wrote:
> > Julian Foad wrote:
> > > If we warn [...] it also has Bad properties:
> > > supporting misleading assumptions about how other variations of the
> > > scenario might behave.
> >
> > Could you be more concrete
Den ons 7 apr. 2021 kl 15:34 skrev Julian Foad :
> > Ack, and thanks for picking up on this omission. Does that all stack up
> now?
>
> I have committed it now, https://svn.apache.org/r1888474 , as I have just
> got to the point of a complete implementation and tests. I am going to
> nominate
Nominated for backport to 1.14.x. Would anyone be kind enough to review and/or
test it?
--
- Julian
> Ack, and thanks for picking up on this omission. Does that all stack up now?
I have committed it now, https://svn.apache.org/r1888474 , as I have just got
to the point of a complete implementation and tests. I am going to nominate it
for backport.
That doesn't imply that I assume all your
Daniel Shahaf wrote:
> Julian Foad wrote:
> > If we warn [...] it also has Bad properties:
> > supporting misleading assumptions about how other variations of the
> > scenario might behave.
>
> Could you be more concrete about those assumptions?
It's not the warning itself but that continuing
Julian Foad wrote on Tue, 06 Apr 2021 09:12 +00:00:
> Daniel Shahaf wrote:
> > The write-up doesn't seem to consider the possibility of issuing
> > a warning rather than a fatal error. This would negate the "does not
> > introduce a silent behavioural change" argument and not constitute
> > a
Daniel Shahaf wrote:
> The write-up doesn't seem to consider the possibility of issuing
> a warning rather than a fatal error. This would negate the "does not
> introduce a silent behavioural change" argument and not constitute
> a flag day to anyone who may be "intentionally or unintentionally
Julian Foad wrote on Fri, 02 Apr 2021 19:02 +00:00:
> Daniel Shahaf wrote:
> > Are you looking for feedback on the write-up and/or patch? I assume
> > not since you haven't mentioned any of this on dev@.
>
> I would be glad of any feedback. I was going to wait until I had a
> patch ready for
(Bringing to dev@.)
Daniel Shahaf wrote:
> Are you looking for feedback on the write-up and/or patch? I assume
> not since you haven't mentioned any of this on dev@.
I would be glad of any feedback. I was going to wait until I had a patch ready
for review. Now there is a patch attached to
29 matches
Mail list logo
