The run up to Subversion 1.13.0

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

The run up to Subversion 1.13.0

Julian Foad-5
1.13.0 is due to be released in mid-October, 6 or 7 weeks away. We need
to put out a release candidate in mid-September. I can do this.

I have just updated the CHANGES file on trunk to list the minor changes.
There are no significant feature changes. That's OK.

It will be the last 'regular release' before the next LTS (1.14) so we
might want to consider any changes towards stabilization.

1. Hide experimental features, by default:

   - let 'svn help' omit experimental commands and options
   - let 'svn help -v' include them

The idea is that users wanting a stable experience should not be
distracted by experimental features unless they choose to see them.

I could implement this.

2. As 1.13 is only weeks away, there is little point in making any
further 1.12.x patch releases from now on, so I will not plan to do so.

Any other thoughts on anything we ought to include, or to do?

- Julian
Reply | Threaded
Open this post in threaded view
|

Re: The run up to Subversion 1.13.0

James McCoy-3
On Fri, Aug 30, 2019 at 05:12:21PM +0100, Julian Foad wrote:
> 2. As 1.13 is only weeks away, there is little point in making any further
> 1.12.x patch releases from now on, so I will not plan to do so.
>
> Any other thoughts on anything we ought to include, or to do?

Finishing(?) and merging the Python3 support would be ideal.  That would
give one release for broader feedback before being in an LTS release.

I haven't kept up with the status of that branch, nor can I guarantee
any time to helping with this, but since you asked... :)

Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
Reply | Threaded
Open this post in threaded view
|

Re: The run up to Subversion 1.13.0

Troy Curtis Jr


On Fri, Aug 30, 2019, 7:13 PM James McCoy <[hidden email]> wrote:
On Fri, Aug 30, 2019 at 05:12:21PM +0100, Julian Foad wrote:
> 2. As 1.13 is only weeks away, there is little point in making any further
> 1.12.x patch releases from now on, so I will not plan to do so.
>
> Any other thoughts on anything we ought to include, or to do?

Finishing(?) and merging the Python3 support would be ideal.  That would
give one release for broader feedback before being in an LTS release.

I haven't kept up with the status of that branch, nor can I guarantee
any time to helping with this, but since you asked... :)

It needs to get reintegrated with trunk again with the latest changes, but the linux side of the house was looking good. It was in trying to get my Windows Dev environment back up and running again that got me frustrated and gave me an excuse to wander off doing other things... IIRC, there is a build issue with the Py2 bindings in that branch on Windows, but I never got far enough to check it out.

If there was someone who could help out on the Windows side, I can jump in and get the branch up to trunk and retested in order to get this thing over the finish line.


Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Troy
Reply | Threaded
Open this post in threaded view
|

Re: The run up to Subversion 1.13.0

Stefan Sperling
On Sun, Sep 01, 2019 at 09:41:47PM -0400, Troy Curtis Jr wrote:
> It needs to get reintegrated with trunk again with the latest changes, but
> the linux side of the house was looking good. It was in trying to get my
> Windows Dev environment back up and running again that got me frustrated
> and gave me an excuse to wander off doing other things... IIRC, there is a
> build issue with the Py2 bindings in that branch on Windows, but I never
> got far enough to check it out.

If it helps, we could require Py3-only on Windows, going forward.
That particular ecosystem has been dragging its feet for long enough ;)
Reply | Threaded
Open this post in threaded view
|

Re: The run up to Subversion 1.13.0

Johan Corveleyn-3
In reply to this post by Troy Curtis Jr
On Mon, Sep 2, 2019 at 3:42 AM Troy Curtis Jr <[hidden email]> wrote:

>
>
>
> On Fri, Aug 30, 2019, 7:13 PM James McCoy <[hidden email]> wrote:
>>
>> On Fri, Aug 30, 2019 at 05:12:21PM +0100, Julian Foad wrote:
>> > 2. As 1.13 is only weeks away, there is little point in making any further
>> > 1.12.x patch releases from now on, so I will not plan to do so.
>> >
>> > Any other thoughts on anything we ought to include, or to do?
>>
>> Finishing(?) and merging the Python3 support would be ideal.  That would
>> give one release for broader feedback before being in an LTS release.
>>
>> I haven't kept up with the status of that branch, nor can I guarantee
>> any time to helping with this, but since you asked... :)
>
>
> It needs to get reintegrated with trunk again with the latest changes, but the linux side of the house was looking good. It was in trying to get my Windows Dev environment back up and running again that got me frustrated and gave me an excuse to wander off doing other things... IIRC, there is a build issue with the Py2 bindings in that branch on Windows, but I never got far enough to check it out.
>
> If there was someone who could help out on the Windows side, I can jump in and get the branch up to trunk and retested in order to get this thing over the finish line.
>

I might be able to devote some time to this in the coming week(s), if
you can tell me what I need to do / test / validate / ... :-).

--
Johan
Reply | Threaded
Open this post in threaded view
|

Python3 work [was: The run up to Subversion 1.13.0]

Julian Foad-5
> Troy Curtis Jr wrote:
>> James McCoy wrote:
>>> Finishing(?) and merging the Python3 support would be ideal.  That would
>>> give one release for broader feedback before being in an LTS release.
>>
>> It needs to get reintegrated with trunk again with the latest changes, but the linux side of the house was looking good. It was in trying to get my Windows Dev environment back up and running again that got me frustrated and gave me an excuse to wander off doing other things... IIRC, there is a build issue with the Py2 bindings in that branch on Windows, but I never got far enough to check it out.

Stefan Sperling wrote:
> If it helps, we could require Py3-only on Windows, going forward.
> That particular ecosystem has been dragging its feet for long enough ;)

What Py3 support are we talking about anyway? svn build? svn test suite?
swig-py bindings?

Stefan Kueng, how would that be for you and TortoiseSVN? If it's fine
for you, I would be very happy to release Subversion 1.13.0 with Py3 the
only supported version on Windows, if we can get it integrated to trunk
in the next few days.


>> If there was someone who could help out on the Windows side, I can jump in and get the branch up to trunk and retested in order to get this thing over the finish line.

Johan Corveleyn wrote:
> I might be able to devote some time to this in the coming week(s), if
> you can tell me what I need to do / test / validate / ... :-).

Until Troy says something more specific, if you could switch to the
branch, catch-up merge from trunk, and see how much works on Py3 and on
Py2, that would be helpful.

Can someone else check the same on *nix please?

1.13 is a "regular release" with emphasis on new features etc. rather
than stability. Of course we always like to have as much stability as
possible as well, but please let's take this opportunity to get
something of this important work integrated right now rather than
waiting until it's absolutely finished.

- Julian
Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Branko Čibej
On 02.09.2019 11:45, Julian Foad wrote:

>> Troy Curtis Jr wrote:
>>> James McCoy wrote:
>>>> Finishing(?) and merging the Python3 support would be ideal.  That
>>>> would
>>>> give one release for broader feedback before being in an LTS release.
>>>
>>> It needs to get reintegrated with trunk again with the latest
>>> changes, but the linux side of the house was looking good. It was in
>>> trying to get my Windows Dev environment back up and running again
>>> that got me frustrated and gave me an excuse to wander off doing
>>> other things... IIRC, there is a build issue with the Py2 bindings
>>> in that branch on Windows, but I never got far enough to check it out.
>
> Stefan Sperling wrote:
>> If it helps, we could require Py3-only on Windows, going forward.
>> That particular ecosystem has been dragging its feet for long enough ;)
>
> What Py3 support are we talking about anyway? svn build? svn test
> suite? swig-py bindings?

This is about the work that's happening on the swig-py3 branch. So: that
would be support for building the swig-py bindings for both Python3 and
Python2. Trunk only support Python2 which has reached end of life.

Our build and test scripts have already been modified to work with both
variants of Python, or rather, with Python 2.7.x and 3.something, for
some unknown value of "something."

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Julian Foad-5
Branko Čibej wrote:

>> What Py3 support are we talking about anyway? svn build? svn test
>> suite? swig-py bindings?
>
> This is about the work that's happening on the swig-py3 branch. So: that
> would be support for building the swig-py bindings for both Python3 and
> Python2. Trunk only support Python2 which has reached end of life.
>
> Our build and test scripts have already been modified to work with both
> variants of Python, or rather, with Python 2.7.x and 3.something, for
> some unknown value of "something."

Thanks. I see no reason to make a special effort to have swig-py
bindings still support Python 2 for Subversion 1.13 and 1.14-LTS. In
fact, it's probably best if we explicitly remove Py2 support for 1.14,
to avoid getting trapped in maintenance difficulties.

Py2 support is needed if we want to backport Py3 support to 1.10.x,
which would be a good thing to aim for; and given that dual-Py-version
capability is mostly in place but unfinished, that sounds like we are on
the right track to be confident that if we put it on trunk now we would
be able to fix up the Py2 support for backport to 1.10.x later, when
it's ready.

It may be tempting to "just" try to fix the remaining Py2 issues right
now before merge to trunk, but I need to prepare a 1.13 branch within
the next 10 days to stay on schedule, so please consider prioritising
merge to trunk with Py3 working, leaving Py2 to be fixed up after that.

- Julian
Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Nathan Hartman
On Mon, Sep 2, 2019 at 8:23 AM Julian Foad <[hidden email]> wrote:
Thanks. I see no reason to make a special effort to have swig-py
bindings still support Python 2 for Subversion 1.13 and 1.14-LTS. In
fact, it's probably best if we explicitly remove Py2 support for 1.14,
to avoid getting trapped in maintenance difficulties.

Py2 is EOL 1/1/2020. Keeping it in 1.14 which implies support until 2024 would be a mistake because support will only get harder. Imagine what happens when your OS vendor removes Py2 packages. Even if Py2 still technically "works" with 1.14 (because that makes it easier to support Py3 for the remainder of 1.10), I suggest to document that Py2 is explicitly NOT supported in the 1.14 release notes. The internal policy should be that once 1.10 support ends, changes are allowed to break Py2 support and/or not be tested with Py2.

I have (among other things) a Windows 10 machine available to me with Python 2 and 3. I'll be glad to help, with a little guidance. At the very least I can help with testing.


Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Johan Corveleyn-3
In reply to this post by Julian Foad-5
On Mon, Sep 2, 2019 at 11:45 AM Julian Foad <[hidden email]> wrote:

> > Troy Curtis Jr wrote:
> >> James McCoy wrote:
> >>> Finishing(?) and merging the Python3 support would be ideal.  That would
> >>> give one release for broader feedback before being in an LTS release.
> >>
> >> It needs to get reintegrated with trunk again with the latest changes, but the linux side of the house was looking good. It was in trying to get my Windows Dev environment back up and running again that got me frustrated and gave me an excuse to wander off doing other things... IIRC, there is a build issue with the Py2 bindings in that branch on Windows, but I never got far enough to check it out.
>
> >> If there was someone who could help out on the Windows side, I can jump in and get the branch up to trunk and retested in order to get this thing over the finish line.
>
> Johan Corveleyn wrote:
> > I might be able to devote some time to this in the coming week(s), if
> > you can tell me what I need to do / test / validate / ... :-).
>
> Until Troy says something more specific, if you could switch to the
> branch, catch-up merge from trunk, and see how much works on Py3 and on
> Py2, that would be helpful.

I'm sorry I missed the 1.13.x-branch deadline, but I finally got
around to playing with the swig-py3 branch on Windows.
Downloaded the latest Python release: 3.7.4. And using swig 3.0.12.

Of course I didn't reread INSTALL, so I first ran into:

[[[
WARNING: "C:\research\svn\dev\swig-py3\py3c\include\py3c.h" not found
Use "--with-py3c" to configure py3c location.
]]]

No problem, after downloading py3c from Github, and adding
--with-py3c, I can start building it.

However, I ran into the following error:

[[[
c:\python37\include\pytime.h(123): error C4115: 'timeval': named type
definition in parentheses
[C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
]]]

(PS: before firing up the swig-py3 branch, I double-checked that I
could successfully build the swig-python bindings on trunk with Python
2.7.16 and swig 3.0.12, and ran the swig-python tests successfully)

--
Johan
Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Branko Čibej
On 18.09.2019 02:48, Johan Corveleyn wrote:

> On Mon, Sep 2, 2019 at 11:45 AM Julian Foad <[hidden email]> wrote:
>>> Troy Curtis Jr wrote:
>>>> James McCoy wrote:
>>>>> Finishing(?) and merging the Python3 support would be ideal.  That would
>>>>> give one release for broader feedback before being in an LTS release.
>>>> It needs to get reintegrated with trunk again with the latest changes, but the linux side of the house was looking good. It was in trying to get my Windows Dev environment back up and running again that got me frustrated and gave me an excuse to wander off doing other things... IIRC, there is a build issue with the Py2 bindings in that branch on Windows, but I never got far enough to check it out.
>>>> If there was someone who could help out on the Windows side, I can jump in and get the branch up to trunk and retested in order to get this thing over the finish line.
>> Johan Corveleyn wrote:
>>> I might be able to devote some time to this in the coming week(s), if
>>> you can tell me what I need to do / test / validate / ... :-).
>> Until Troy says something more specific, if you could switch to the
>> branch, catch-up merge from trunk, and see how much works on Py3 and on
>> Py2, that would be helpful.
> I'm sorry I missed the 1.13.x-branch deadline, but I finally got
> around to playing with the swig-py3 branch on Windows.
> Downloaded the latest Python release: 3.7.4. And using swig 3.0.12.
>
> Of course I didn't reread INSTALL, so I first ran into:
>
> [[[
> WARNING: "C:\research\svn\dev\swig-py3\py3c\include\py3c.h" not found
> Use "--with-py3c" to configure py3c location.
> ]]]
>
> No problem, after downloading py3c from Github, and adding
> --with-py3c, I can start building it.
>
> However, I ran into the following error:
>
> [[[
> c:\python37\include\pytime.h(123): error C4115: 'timeval': named type
> definition in parentheses
> [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
> ]]]

That makes no sense, my copy of pytime.h on Windows for Python 3.7.4 has
this on line 123:

PyAPI_FUNC(int) _PyTime_FromTimeval(_PyTime_t *tp, struct timeval *tv);


Looks like perfectly valid C to me. So we'll need a bit more context to
see where the actual error is coming from.


-- Brane
Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Johan Corveleyn-3
On Wed, Sep 18, 2019 at 5:36 AM Branko Čibej <[hidden email]> wrote:

>
> On 18.09.2019 02:48, Johan Corveleyn wrote:
> > On Mon, Sep 2, 2019 at 11:45 AM Julian Foad <[hidden email]> wrote:
> >>> Troy Curtis Jr wrote:
> >>>> James McCoy wrote:
> >>>>> Finishing(?) and merging the Python3 support would be ideal.  That would
> >>>>> give one release for broader feedback before being in an LTS release.
> >>>> It needs to get reintegrated with trunk again with the latest changes, but the linux side of the house was looking good. It was in trying to get my Windows Dev environment back up and running again that got me frustrated and gave me an excuse to wander off doing other things... IIRC, there is a build issue with the Py2 bindings in that branch on Windows, but I never got far enough to check it out.
> >>>> If there was someone who could help out on the Windows side, I can jump in and get the branch up to trunk and retested in order to get this thing over the finish line.
> >> Johan Corveleyn wrote:
> >>> I might be able to devote some time to this in the coming week(s), if
> >>> you can tell me what I need to do / test / validate / ... :-).
> >> Until Troy says something more specific, if you could switch to the
> >> branch, catch-up merge from trunk, and see how much works on Py3 and on
> >> Py2, that would be helpful.
> > I'm sorry I missed the 1.13.x-branch deadline, but I finally got
> > around to playing with the swig-py3 branch on Windows.
> > Downloaded the latest Python release: 3.7.4. And using swig 3.0.12.
> >
> > Of course I didn't reread INSTALL, so I first ran into:
> >
> > [[[
> > WARNING: "C:\research\svn\dev\swig-py3\py3c\include\py3c.h" not found
> > Use "--with-py3c" to configure py3c location.
> > ]]]
> >
> > No problem, after downloading py3c from Github, and adding
> > --with-py3c, I can start building it.
> >
> > However, I ran into the following error:
> >
> > [[[
> > c:\python37\include\pytime.h(123): error C4115: 'timeval': named type
> > definition in parentheses
> > [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
> > ]]]
>
> That makes no sense, my copy of pytime.h on Windows for Python 3.7.4 has
> this on line 123:
>
> PyAPI_FUNC(int) _PyTime_FromTimeval(_PyTime_t *tp, struct timeval *tv);
>
>
> Looks like perfectly valid C to me. So we'll need a bit more context to
> see where the actual error is coming from.

Not at my pc right now (I'll check again tonight), but from memory: I
think my copy of pytime.h looks the same. Line 123 seems to be the
first usage of 'timeval' though ... Is it possible that some include
is missing, so there is no declaration of the timeval struct type?

--
Johan
Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Daniel Shahaf-2
In reply to this post by Johan Corveleyn-3
Johan Corveleyn wrote on Wed, 18 Sep 2019 00:48 +00:00:
> No problem, after downloading py3c from Github, and adding
> --with-py3c, I can start building it.

What version of py3c did you download?  HEAD or a release?
Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Johan Corveleyn-3
On Wed, Sep 18, 2019 at 9:31 AM Daniel Shahaf <[hidden email]> wrote:
>
> Johan Corveleyn wrote on Wed, 18 Sep 2019 00:48 +00:00:
> > No problem, after downloading py3c from Github, and adding
> > --with-py3c, I can start building it.
>
> What version of py3c did you download?  HEAD or a release?

Hm, I downloaded from master at https://github.com/encukou/py3c. Maybe
not such a good choice?
Should I go for 0.9 from https://github.com/encukou/py3c/releases instead?

--
Johan
Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Daniel Shahaf-2
Johan Corveleyn wrote on Wed, 18 Sep 2019 07:44 +00:00:

> On Wed, Sep 18, 2019 at 9:31 AM Daniel Shahaf <[hidden email]> wrote:
> >
> > Johan Corveleyn wrote on Wed, 18 Sep 2019 00:48 +00:00:
> > > No problem, after downloading py3c from Github, and adding
> > > --with-py3c, I can start building it.
> >
> > What version of py3c did you download?  HEAD or a release?
>
> Hm, I downloaded from master at https://github.com/encukou/py3c. Maybe
> not such a good choice?
> Should I go for 0.9 from https://github.com/encukou/py3c/releases instead?

I didn't intend to imply that; I merely wanted to know which version to
use for investigations and replication attempts.

Note that on the /releases page there's a v1.0 dated three months after
the v0.9, if you click "Show newer tags" at the top.  I'm not sure why github
doesn't offer that one.

Cheers,

Daniel
Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Branko Čibej
In reply to this post by Johan Corveleyn-3
On 18.09.2019 09:20, Johan Corveleyn wrote:

> On Wed, Sep 18, 2019 at 5:36 AM Branko Čibej <[hidden email]> wrote:
>> On 18.09.2019 02:48, Johan Corveleyn wrote:
>>> On Mon, Sep 2, 2019 at 11:45 AM Julian Foad <[hidden email]> wrote:
>>>>> Troy Curtis Jr wrote:
>>>>>> James McCoy wrote:
>>>>>>> Finishing(?) and merging the Python3 support would be ideal.  That would
>>>>>>> give one release for broader feedback before being in an LTS release.
>>>>>> It needs to get reintegrated with trunk again with the latest changes, but the linux side of the house was looking good. It was in trying to get my Windows Dev environment back up and running again that got me frustrated and gave me an excuse to wander off doing other things... IIRC, there is a build issue with the Py2 bindings in that branch on Windows, but I never got far enough to check it out.
>>>>>> If there was someone who could help out on the Windows side, I can jump in and get the branch up to trunk and retested in order to get this thing over the finish line.
>>>> Johan Corveleyn wrote:
>>>>> I might be able to devote some time to this in the coming week(s), if
>>>>> you can tell me what I need to do / test / validate / ... :-).
>>>> Until Troy says something more specific, if you could switch to the
>>>> branch, catch-up merge from trunk, and see how much works on Py3 and on
>>>> Py2, that would be helpful.
>>> I'm sorry I missed the 1.13.x-branch deadline, but I finally got
>>> around to playing with the swig-py3 branch on Windows.
>>> Downloaded the latest Python release: 3.7.4. And using swig 3.0.12.
>>>
>>> Of course I didn't reread INSTALL, so I first ran into:
>>>
>>> [[[
>>> WARNING: "C:\research\svn\dev\swig-py3\py3c\include\py3c.h" not found
>>> Use "--with-py3c" to configure py3c location.
>>> ]]]
>>>
>>> No problem, after downloading py3c from Github, and adding
>>> --with-py3c, I can start building it.
>>>
>>> However, I ran into the following error:
>>>
>>> [[[
>>> c:\python37\include\pytime.h(123): error C4115: 'timeval': named type
>>> definition in parentheses
>>> [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
>>> ]]]
>> That makes no sense, my copy of pytime.h on Windows for Python 3.7.4 has
>> this on line 123:
>>
>> PyAPI_FUNC(int) _PyTime_FromTimeval(_PyTime_t *tp, struct timeval *tv);
>>
>>
>> Looks like perfectly valid C to me. So we'll need a bit more context to
>> see where the actual error is coming from.
> Not at my pc right now (I'll check again tonight), but from memory: I
> think my copy of pytime.h looks the same. Line 123 seems to be the
> first usage of 'timeval' though ... Is it possible that some include
> is missing, so there is no declaration of the timeval struct type?


You do *not* need a definition of 'struct foo' in order to use a 'struct
foo*' pointer. So, no, that's not the problem.

-- Brane
Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Johan Corveleyn-3
On Wed, Sep 18, 2019 at 12:08 PM Branko Čibej <[hidden email]> wrote:

>
> On 18.09.2019 09:20, Johan Corveleyn wrote:
> > On Wed, Sep 18, 2019 at 5:36 AM Branko Čibej <[hidden email]> wrote:
> >> On 18.09.2019 02:48, Johan Corveleyn wrote:
> >>> On Mon, Sep 2, 2019 at 11:45 AM Julian Foad <[hidden email]> wrote:
> >>>>> Troy Curtis Jr wrote:
> >>>>>> James McCoy wrote:
> >>>>>>> Finishing(?) and merging the Python3 support would be ideal.  That would
> >>>>>>> give one release for broader feedback before being in an LTS release.
> >>>>>> It needs to get reintegrated with trunk again with the latest changes, but the linux side of the house was looking good. It was in trying to get my Windows Dev environment back up and running again that got me frustrated and gave me an excuse to wander off doing other things... IIRC, there is a build issue with the Py2 bindings in that branch on Windows, but I never got far enough to check it out.
> >>>>>> If there was someone who could help out on the Windows side, I can jump in and get the branch up to trunk and retested in order to get this thing over the finish line.
> >>>> Johan Corveleyn wrote:
> >>>>> I might be able to devote some time to this in the coming week(s), if
> >>>>> you can tell me what I need to do / test / validate / ... :-).
> >>>> Until Troy says something more specific, if you could switch to the
> >>>> branch, catch-up merge from trunk, and see how much works on Py3 and on
> >>>> Py2, that would be helpful.
> >>> I'm sorry I missed the 1.13.x-branch deadline, but I finally got
> >>> around to playing with the swig-py3 branch on Windows.
> >>> Downloaded the latest Python release: 3.7.4. And using swig 3.0.12.
> >>>
> >>> Of course I didn't reread INSTALL, so I first ran into:
> >>>
> >>> [[[
> >>> WARNING: "C:\research\svn\dev\swig-py3\py3c\include\py3c.h" not found
> >>> Use "--with-py3c" to configure py3c location.
> >>> ]]]
> >>>
> >>> No problem, after downloading py3c from Github, and adding
> >>> --with-py3c, I can start building it.
> >>>
> >>> However, I ran into the following error:
> >>>
> >>> [[[
> >>> c:\python37\include\pytime.h(123): error C4115: 'timeval': named type
> >>> definition in parentheses
> >>> [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
> >>> ]]]
> >> That makes no sense, my copy of pytime.h on Windows for Python 3.7.4 has
> >> this on line 123:
> >>
> >> PyAPI_FUNC(int) _PyTime_FromTimeval(_PyTime_t *tp, struct timeval *tv);
> >>
> >>
> >> Looks like perfectly valid C to me. So we'll need a bit more context to
> >> see where the actual error is coming from.
> > Not at my pc right now (I'll check again tonight), but from memory: I
> > think my copy of pytime.h looks the same. Line 123 seems to be the
> > first usage of 'timeval' though ... Is it possible that some include
> > is missing, so there is no declaration of the timeval struct type?
>
>
> You do *not* need a definition of 'struct foo' in order to use a 'struct
> foo*' pointer. So, no, that's not the problem.

Hmm, okay, just tried again ... same problem. Here is some more output:

[[[
C:\research\svn\dev\swig-py3> msbuild subversion_vcnet.sln /nologo
/v:q /p:Configuration=release /t:__SWIG_PYTHON__
c:\python37\include\pytime.h(123): error C4115: 'timeval': named type
definition in parentheses
[C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
C:\research\svn\dev\swig-py3\subversion\bindings\swig\proxy\swig_python_external_runtime.swg(2459):
warning C4459: declaration of 'swig_this' hides global declaration
[C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
C:\research\svn\dev\swig-py3\subversion\bindings\swig\proxy\swig_python_external_runtime.swg(2534):
warning C4459: declaration of 'swig_this' hides global declaration
[C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(2363):
warning C4101: 'tmp': unreferenced local variable
[C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(2772):
warning C4018: '>': signed/unsigned mismatch
[C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
]]]

I tried with both the x86-64 and the x86 builds of Python 3.7.4 ...
same result. Weird. I'm continuing to investigate.


In other news, building the swig-py3 branch (after sync-merge from
trunk) with Python 2.7.16 (and swig 3.0.12) was successful.
Running the testsuite gives some failures though:

[[[
Testing Release configuration on local repository.
-- Running Swig Python tests --
..............s..............EE........F....F...........................................................................
..................................
======================================================================
ERROR: test_conflict (client.SubversionClientTestCase)
Test conflict api.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
line 593, in test_conflict
    conflict = client.conflict_get(trunk_path, self.client_ctx, pool)
  File "R:\test_release--swigpython\swig\pylib\libsvn\client.py", line
1642, in svn_client_conflict_get
    return _client.svn_client_conflict_get(*args)
SubversionException: 155007 - 'R:\temp\tmpyeizeh-conflict\trunk' is
not a working copy

======================================================================
ERROR: test_conflict (client.SubversionClientTestCase)
Test conflict api.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
line 94, in tearDown
    self.temper.cleanup()
  File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\utils.py",
line 44, in cleanup
    clean_func(target)
  File "R:\test_release--swigpython\swig\pylib\libsvn\core.py", line
8453, in svn_io_remove_dir
    return _core.svn_io_remove_dir(*args)
SubversionException: 720032 - Can't remove
'R:\temp\tmpyeizeh-conflict\.svn\wc.db'
720032 - Can't remove file 'R:\temp\tmpyeizeh-conflict\.svn\wc.db':
The process cannot access the file because it is being used by another
process.

======================================================================
FAIL: test_merge_peg3 (client.SubversionClientTestCase)
Test svn_client_merge_peg3.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
line 442, in test_merge_peg3
    self.assertEqual(readme_text, b'This is a test.\n')
AssertionError: 'This is a test.\r\n' != 'This is a test.\n'

======================================================================
FAIL: test_shelf (client.SubversionClientTestCase)
Test shelf api.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
line 644, in test_shelf
    self.assertIn(new_subpath, statused_paths)
AssertionError: 'trunk\\new-shelf-test.txt' not found in
['trunk/new-shelf-test.txt', 'trunk/new-shelf-test.txt', None]

----------------------------------------------------------------------
Ran 153 tests in 38.984s

FAILED (failures=2, errors=2, skipped=1)
Exception svn.core.SubversionException: SubversionException("Can't
open file 'R:\\temp\\tmp9ubdal-client\\db\\fs-type':
The system cannot find the path specified.  ", 720003) in <bound
method Temper.__del__ of <utils.Temper object at 0x02B8B4F0>> ignored
[Test runner reported failure]
]]]

(Running the swig-python tests on trunk, with Python 2.7.16, was fully
successful)

--
Johan
Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Yasuhito FUTATSUKI
On 2019/09/19 8:21, Johan Corveleyn wrote:
> On Wed, Sep 18, 2019 at 12:08 PM Branko Čibej <[hidden email]> wrote:
>>
>> On 18.09.2019 09:20, Johan Corveleyn wrote:
>>> On Wed, Sep 18, 2019 at 5:36 AM Branko Čibej <[hidden email]> wrote:
>>>> On 18.09.2019 02:48, Johan Corveleyn wrote:
<snip>

>>>>> [[[
>>>>> c:\python37\include\pytime.h(123): error C4115: 'timeval': named type
>>>>> definition in parentheses
>>>>> [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
>>>>> ]]]
>>>> That makes no sense, my copy of pytime.h on Windows for Python 3.7.4 has
>>>> this on line 123:
>>>>
>>>> PyAPI_FUNC(int) _PyTime_FromTimeval(_PyTime_t *tp, struct timeval *tv);
>>>>
>>>>
>>>> Looks like perfectly valid C to me. So we'll need a bit more context to
>>>> see where the actual error is coming from.
>>> Not at my pc right now (I'll check again tonight), but from memory: I
>>> think my copy of pytime.h looks the same. Line 123 seems to be the
>>> first usage of 'timeval' though ... Is it possible that some include
>>> is missing, so there is no declaration of the timeval struct type?
>>
>>
>> You do *not* need a definition of 'struct foo' in order to use a 'struct
>> foo*' pointer. So, no, that's not the problem.

Actually C4115 is only a warning.

https://docs.microsoft.com/cpp/error-messages/compiler-warnings/compiler-warning-levels-1-and-4-c4115?view=vs-2019

However, it seems we are treating it as an error by specifyinging build
option in build/generator/templates/vcnet_vcxproj.ezt .

(Is it related to https://bugs.python.org/issue25878, especially
msg256496 ?)


<snip>

> In other news, building the swig-py3 branch (after sync-merge from
> trunk) with Python 2.7.16 (and swig 3.0.12) was successful.
> Running the testsuite gives some failures though:
>
> [[[
> Testing Release configuration on local repository.
> -- Running Swig Python tests --
> ..............s..............EE........F....F...........................................................................
> ..................................
> ======================================================================
> ERROR: test_conflict (client.SubversionClientTestCase)
> Test conflict api.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
> line 593, in test_conflict
>      conflict = client.conflict_get(trunk_path, self.client_ctx, pool)
>    File "R:\test_release--swigpython\swig\pylib\libsvn\client.py", line
> 1642, in svn_client_conflict_get
>      return _client.svn_client_conflict_get(*args)
> SubversionException: 155007 - 'R:\temp\tmpyeizeh-conflict\trunk' is
> not a working copy
>
> ======================================================================
> ERROR: test_conflict (client.SubversionClientTestCase)
> Test conflict api.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
> line 94, in tearDown
>      self.temper.cleanup()
>    File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\utils.py",
> line 44, in cleanup
>      clean_func(target)
>    File "R:\test_release--swigpython\swig\pylib\libsvn\core.py", line
> 8453, in svn_io_remove_dir
>      return _core.svn_io_remove_dir(*args)
> SubversionException: 720032 - Can't remove
> 'R:\temp\tmpyeizeh-conflict\.svn\wc.db'
> 720032 - Can't remove file 'R:\temp\tmpyeizeh-conflict\.svn\wc.db':
> The process cannot access the file because it is being used by another
> process.
>
> ======================================================================
> FAIL: test_merge_peg3 (client.SubversionClientTestCase)
> Test svn_client_merge_peg3.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
> line 442, in test_merge_peg3
>      self.assertEqual(readme_text, b'This is a test.\n')
> AssertionError: 'This is a test.\r\n' != 'This is a test.\n'
>
> ======================================================================
> FAIL: test_shelf (client.SubversionClientTestCase)
> Test shelf api.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
> line 644, in test_shelf
>      self.assertIn(new_subpath, statused_paths)
> AssertionError: 'trunk\\new-shelf-test.txt' not found in
> ['trunk/new-shelf-test.txt', 'trunk/new-shelf-test.txt', None]
>
> ----------------------------------------------------------------------
> Ran 153 tests in 38.984s
>
> FAILED (failures=2, errors=2, skipped=1)
> Exception svn.core.SubversionException: SubversionException("Can't
> open file 'R:\\temp\\tmp9ubdal-client\\db\\fs-type':
> The system cannot find the path specified.  ", 720003) in <bound
> method Temper.__del__ of <utils.Temper object at 0x02B8B4F0>> ignored
> [Test runner reported failure]
> ]]]
>
> (Running the swig-python tests on trunk, with Python 2.7.16, was fully
> successful)
>

The FAIL on test_merge_peg3 is a newline style issue on reading file
in raw mode, which is introduced by my patch.
(https://svn.apache.org/viewvc/subversion/branches/swig-py3/subversion/bindings/swig/python/tests/client.py?view=annotate#l438)

Rest of those errors and failures are in the tests that were added only
to swig-py, and it seems most of the causes of them are confusion of
paths in platform specific format and Subversion's canoical format,
as the comment in SubversionClientTestCase.test_update4() says.

(I'll try to fix those issues on check-swig-py later, hopefully
next weekend.)
--
Yasuhito FUTATSUKI
Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Daniel Shahaf-2
Yasuhito FUTATSUKI wrote on Thu, 19 Sep 2019 06:41 +00:00:

> On 2019/09/19 8:21, Johan Corveleyn wrote:
> > On Wed, Sep 18, 2019 at 12:08 PM Branko Čibej <[hidden email]> wrote:
> >> You do *not* need a definition of 'struct foo' in order to use a 'struct
> >> foo*' pointer. So, no, that's not the problem.
>
> Actually C4115 is only a warning.
>
> https://docs.microsoft.com/cpp/error-messages/compiler-warnings/compiler-warning-levels-1-and-4-c4115?view=vs-2019
>
> However, it seems we are treating it as an error by specifyinging build
> option in build/generator/templates/vcnet_vcxproj.ezt .
>
> (Is it related to https://bugs.python.org/issue25878, especially
> msg256496 ?)
>

That certainly sounds similar.

For comparison, on a toy example, I get a warning if I use a pointer to
an undeclared struct type:

[[[
% cat foo.c
void f(struct foo *);
% cc -c -Wall foo.c
foo.c:1:15: warning: declaration of 'struct foo' will not be visible outside of
      this function [-Wvisibility]
void f(struct foo *);
              ^
1 warning generated.
%
]]]

That doesn't happen if the struct type has been declared:

[[[
% cat bar.c
struct bar;
void g(struct bar *);
% cc -c -Wall bar.c
%
]]]

I think that -Wvisibility warning is basically what that C4115 is about?
pytime.h doesn't declare 'struct timeval', neither directly nor via
an #include.

I haven't checked whether my build warns about -Wvisibility there.

> The FAIL on test_merge_peg3 is a newline style issue on reading file
> in raw mode, which is introduced by my patch.
> (https://svn.apache.org/viewvc/subversion/branches/swig-py3/subversion/bindings/swig/python/tests/client.py?view=annotate#l438)
>
> Rest of those errors and failures are in the tests that were added only
> to swig-py, and it seems most of the causes of them are confusion of
> paths in platform specific format and Subversion's canoical format,
> as the comment in SubversionClientTestCase.test_update4() says.
>
> (I'll try to fix those issues on check-swig-py later, hopefully
> next weekend.)

Thanks!  No rush.

Cheers,

Daniel
Reply | Threaded
Open this post in threaded view
|

Re: Python3 work [was: The run up to Subversion 1.13.0]

Paul Hammant-3
One more thing re Python3 - there's Svn Homebrew fu for Mac folks - https://github.com/Homebrew/homebrew-core/blob/master/Formula/subversion.rb - that work admirably for Python 2.7.x but has no code for Python 3.  I don't think this brew formula is maintained in the svn dev team. Of course, pull-requests are processed as you'd expected for a project hosted on GitHub.
12