On 2020/12/31 8:59, Yasuhito FUTATSUKI wrote:
> During writing the test above I also found that on swig-py for Python 3
> wrapper functions using svn_string_t * or svn_stringbuf_t * for in
> input arguments don't accept str objects for their values. This was
> my overlook, so I'll fix it. However
On 2020/12/31 8:59, Yasuhito FUTATSUKI wrote:
> On 2020/12/28 19:10, Daniel Shahaf wrote:
>> Yasuhito FUTATSUKI wrote on Sat, 26 Dec 2020 11:02 +00:00:
>>> On 2020/12/26 3:38, Nathan Hartman wrote:
>>>
But the solution you suggest above, adding a new_rev attribute to the
exception and lea
On 2020/12/28 19:10, Daniel Shahaf wrote:
> Yasuhito FUTATSUKI wrote on Sat, 26 Dec 2020 11:02 +00:00:
>> On 2020/12/26 3:38, Nathan Hartman wrote:
>>
>>> But the solution you suggest above, adding a new_rev attribute to the
>>> exception and leaving the return value as it was, sounds like a good w
On 25.12.2020 18:00, Daniel Shahaf wrote:
In addition, we introduce a framework to add attributes to
'SubversionException' to return additional values to the caller in
situations such as above. (This new feature is mentioned for
completeness but is not part of the errata.)
"the erratum"
Usin
Yasuhito FUTATSUKI wrote on Sat, 26 Dec 2020 11:02 +00:00:
> On 2020/12/26 3:38, Nathan Hartman wrote:
>
> > But the solution you suggest above, adding a new_rev attribute to the
> > exception and leaving the return value as it was, sounds like a good way to
> > avoid the incompatibility and also
I'm sorry, but I'd like to make a correction.
On 2020/12/26 20:02, Yasuhito FUTATSUKI wrote:
> [[[
> Index: subversion/bindings/swig/python/svn/fs.py
> ===
> --- subversion/bindings/swig/python/svn/fs.py (revision 1884802)
> +++ su
On 2020/12/26 3:38, Nathan Hartman wrote:
> But the solution you suggest above, adding a new_rev attribute to the
> exception and leaving the return value as it was, sounds like a good way to
> avoid the incompatibility and also avoid the API bump.
I had written such a patch on typemaps at first
On Fri, Dec 25, 2020 at 12:00 PM Daniel Shahaf
wrote:
>
> I may be more than a bit late for this, but can we avoid the
> incompatibility in the first place? I.e., avoid requiring API users to
> check svn.core.SVN_VER_MINOR before interpreting an API's return value?
> Adding a new_rev attribute t
Nathan Hartman wrote on Wed, Dec 23, 2020 at 00:09:46 -0500:
> On Tue, Dec 22, 2020 at 10:13 AM Yasuhito FUTATSUKI
> wrote:
> >
> > On 2020/08/29 2:49, C. Michael Pilato wrote:
> > >>> Committed revision 1880967.
> > >>>
> > >>> I made only minor comment/formatting changes.
> > >>
> > >> Shouldn't
On Wed, Dec 23, 2020 at 1:02 PM Yasuhito FUTATSUKI
wrote:
> The last paragraph is for "== Impact on API Users ==" section, I
> think. (Yes, my draft also missed this mark of the section.)
>
> I think the error in this erratum is (3) only, and the fix might
> be a change type of return value of svn
On 2020/12/23 14:09, Nathan Hartman wrote:
> On Tue, Dec 22, 2020 at 10:13 AM Yasuhito FUTATSUKI
> wrote:
>>
>> On 2020/08/29 2:49, C. Michael Pilato wrote:
> Committed revision 1880967.
>
> I made only minor comment/formatting changes.
Shouldn't the change be documented some
On Tue, Dec 22, 2020 at 10:13 AM Yasuhito FUTATSUKI
wrote:
>
> On 2020/08/29 2:49, C. Michael Pilato wrote:
> >>> Committed revision 1880967.
> >>>
> >>> I made only minor comment/formatting changes.
> >>
> >> Shouldn't the change be documented somewhere for users of the
> >> bindings? (E.g., rel
On 2020/08/29 2:49, C. Michael Pilato wrote:
> On Fri, Aug 21, 2020 at 7:10 AM Daniel Shahaf
> wrote:
>
>> C. Michael Pilato wrote on Tue, 18 Aug 2020 10:23 -0400:
>>> Sendingsubversion/bindings/swig/include/svn_types.swg
>>> Sending
>> subversion/bindings/swig/python/libsvn_swig_py/swigu
C. Michael Pilato wrote on Fri, 28 Aug 2020 13:49 -0400:
> On Fri, Aug 21, 2020 at 7:10 AM Daniel Shahaf
> wrote:
>
> > C. Michael Pilato wrote on Tue, 18 Aug 2020 10:23 -0400:
> > > Sendingsubversion/bindings/swig/include/svn_types.swg
> > > Sending
> > subversion/bindings/swig/pytho
On Fri, Aug 21, 2020 at 7:10 AM Daniel Shahaf
wrote:
> C. Michael Pilato wrote on Tue, 18 Aug 2020 10:23 -0400:
> > Sendingsubversion/bindings/swig/include/svn_types.swg
> > Sending
> subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
> > Sending
> subversion/bindings/swig/pytho
C. Michael Pilato wrote on Tue, 18 Aug 2020 10:23 -0400:
> Sendingsubversion/bindings/swig/include/svn_types.swg
> Sendingsubversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
> Sendingsubversion/bindings/swig/python/libsvn_swig_py/swigutil_py.h
> Sendingsubve
Sendingsubversion/bindings/swig/include/svn_types.swg
Sendingsubversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
Sendingsubversion/bindings/swig/python/libsvn_swig_py/swigutil_py.h
Sendingsubversion/bindings/swig/svn_fs.i
Sendingsubversion/bindings/s
On 2020/07/31 10:19, Yasuhito FUTATSUKI wrote:
> On 2020/07/30 22:20, C. Michael Pilato wrote:
>> The patch seems to work pretty well (for svn_repos_fs_commit_txn), but
>> there are two issues I have with it.
>>
>> First, unless I'm mistaken, there's no way to get the conflict_p back as
>> part of
On 2020/07/30 22:20, C. Michael Pilato wrote:
> The patch seems to work pretty well (for svn_repos_fs_commit_txn), but
> there are two issues I have with it.
>
> First, unless I'm mistaken, there's no way to get the conflict_p back as
> part of the 2-tuple return value -- if there's a conflict,
>
The patch seems to work pretty well (for svn_repos_fs_commit_txn), but
there are two issues I have with it.
First, unless I'm mistaken, there's no way to get the conflict_p back as
part of the 2-tuple return value -- if there's a conflict,
svn.repos.fs_commit_txn() is going to raise an Exception.
On 2020/07/30 17:47, Yasuhito FUTATSUKI wrote:
> On 2020/07/29 23:43, C. Michael Pilato wrote:
>> Makes sense to me as a way to get access to all the things that can be
>> returned in an errorful situation.
>
> Okey, I implemented it. The attached patch add "conflict_p" and "new_rev"
> attributes
On 2020/07/29 23:43, C. Michael Pilato wrote:
> Makes sense to me as a way to get access to all the things that can be
> returned in an errorful situation.
Okey, I implemented it. The attached patch add "conflict_p" and "new_rev"
attributes to SubversionException instance on svn_fs.commit_txn and
Makes sense to me as a way to get access to all the things that can be
returned in an errorful situation.
On Wed, Jul 29, 2020 at 7:17 AM Yasuhito FUTATSUKI
wrote:
> On 2020/07/29 7:45, Yasuhito FUTATSUKI wrote:
> > On 2020/07/29 1:02, Yasuhito FUTATSUKI wrote:
> >> On 2020/07/28 23:34, C. Micha
On 2020/07/29 7:45, Yasuhito FUTATSUKI wrote:
> On 2020/07/29 1:02, Yasuhito FUTATSUKI wrote:
>> On 2020/07/28 23:34, C. Michael Pilato wrote:
>>> Hey, all.
>>>
>>> I'm writing some code that performs commits via the Subversion Python
>>> bindings, and I'm struggling to understand some things I see
On 2020/07/29 1:02, Yasuhito FUTATSUKI wrote:
> On 2020/07/28 23:34, C. Michael Pilato wrote:
>> Hey, all.
>>
>> I'm writing some code that performs commits via the Subversion Python
>> bindings, and I'm struggling to understand some things I see there.
>>
>> In the svn_fs.i interface file, there's
On 2020/07/28 23:34, C. Michael Pilato wrote:
> Hey, all.
>
> I'm writing some code that performs commits via the Subversion Python
> bindings, and I'm struggling to understand some things I see there.
>
> In the svn_fs.i interface file, there's this block of code:
>
> /* ---
Hey, all.
I'm writing some code that performs commits via the Subversion Python
bindings, and I'm struggling to understand some things I see there.
In the svn_fs.i interface file, there's this block of code:
/* ---
Fix the re
27 matches
Mail list logo
