[jira] [Updated] (SVN-4915) Ruby bindings contain type error in NIL_P usage
[
https://issues.apache.org/jira/browse/SVN-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Stieger updated SVN-4915:
-
Fix Version/s: trunk
> Ruby bindings contain type error in NIL_P usage
> ---
>
> Key: SVN-4915
> URL: https://issues.apache.org/jira/browse/SVN-4915
> Project: Subversion
> Issue Type: Bug
> Components: bindings_swig_ruby
>Affects Versions: 1.14.2
>Reporter: Florian Weimer
>Assignee: Yasuhito Futatsuki
>Priority: Minor
> Fix For: trunk
>
> Attachments: subversion-ruby-c99.patch
>
>
> The Ruby bindings apply the Ruby {{NIL_P}} macro to an {{apr_hash_t *}}
> value, which some compilers flag as a type error. We see this while building
> the bindings against Ruby 3.2 with a compiler that roughly behaves like
> {{-Werror=int-conversion}} (no implicit conversions between integers and
> pointers).
> The attached patch should fix this issue.
> Related to:
> * [https://fedoraproject.org/wiki/Changes/PortingToModernC]
> * [https://fedoraproject.org/wiki/Toolchain/PortingToModernC]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SVN-4915) Ruby bindings contain type error in NIL_P usage
[
https://issues.apache.org/jira/browse/SVN-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Stieger resolved SVN-4915.
--
Resolution: Fixed
Fixed in
[r1915236|https://svn.apache.org/viewvc?view=revision&revision=1915236].
> Ruby bindings contain type error in NIL_P usage
> ---
>
> Key: SVN-4915
> URL: https://issues.apache.org/jira/browse/SVN-4915
> Project: Subversion
> Issue Type: Bug
> Components: bindings_swig_ruby
>Affects Versions: 1.14.2
>Reporter: Florian Weimer
>Assignee: Yasuhito Futatsuki
>Priority: Minor
> Attachments: subversion-ruby-c99.patch
>
>
> The Ruby bindings apply the Ruby {{NIL_P}} macro to an {{apr_hash_t *}}
> value, which some compilers flag as a type error. We see this while building
> the bindings against Ruby 3.2 with a compiler that roughly behaves like
> {{-Werror=int-conversion}} (no implicit conversions between integers and
> pointers).
> The attached patch should fix this issue.
> Related to:
> * [https://fedoraproject.org/wiki/Changes/PortingToModernC]
> * [https://fedoraproject.org/wiki/Toolchain/PortingToModernC]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SVN-4915) Ruby bindings contain type error in NIL_P usage
[
https://issues.apache.org/jira/browse/SVN-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Stieger reassigned SVN-4915:
Assignee: Yasuhito Futatsuki
> Ruby bindings contain type error in NIL_P usage
> ---
>
> Key: SVN-4915
> URL: https://issues.apache.org/jira/browse/SVN-4915
> Project: Subversion
> Issue Type: Bug
> Components: bindings_swig_ruby
>Affects Versions: 1.14.2
>Reporter: Florian Weimer
>Assignee: Yasuhito Futatsuki
>Priority: Minor
> Attachments: subversion-ruby-c99.patch
>
>
> The Ruby bindings apply the Ruby {{NIL_P}} macro to an {{apr_hash_t *}}
> value, which some compilers flag as a type error. We see this while building
> the bindings against Ruby 3.2 with a compiler that roughly behaves like
> {{-Werror=int-conversion}} (no implicit conversions between integers and
> pointers).
> The attached patch should fix this issue.
> Related to:
> * [https://fedoraproject.org/wiki/Changes/PortingToModernC]
> * [https://fedoraproject.org/wiki/Toolchain/PortingToModernC]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4440) Subversion sets permissions on files, when it shouldn't
[
https://issues.apache.org/jira/browse/SVN-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17802048#comment-17802048
]
Daniel Sahlberg commented on SVN-4440:
--
Regarding on Brian's comment:
The changing of the executable flag is by design. If a file should be
executable, it should have the property svn:executable set:
{{# svn propset svn:executable '*' test.py}}
{{property 'svn:executable' set on 'test.py'}}
This issue should stay resolved.
> Subversion sets permissions on files, when it shouldn't
> ---
>
> Key: SVN-4440
> URL: https://issues.apache.org/jira/browse/SVN-4440
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_subr
>Affects Versions: 1.8.x
>Reporter: Subversion Importer
>Priority: Critical
> Fix For: ---
>
>
> {noformat:nopanel=true}
> As discussed in this thread:
> http://svn.haxx.se/users/archive-2013-10/0095.shtml, subversion sets file
> permissions on files at commit.
> The file doesn't have svn:eol-style, svn:keywords or svn:needs-lock properties
> set, and subversion doesn't rewrite it (it has the same inode before and after
> the commit).
> So according to these and judging from this mail:
> http://svn.haxx.se/users/archive-2013-10/0180.shtml, I consider this a bug,
> which not only prevents one from maintaining file permissions and ownership in
> subversion properties (subversion will set the file to umask permissions on
> every commit), but this behaviour is not expected from the user, and can pose
> ill effects.
> Please remove this by deleting the chmod from the commit codepath (from a
> simple
> grep, it seems to be called from subversion/libsvn_subr/io.c, so I choose that
> subcomponent).
> I set "found in version" to 1.8.x, but I'm sure it's in 1.7, and not sure
> about
> earlier versions.
> Thanks.
> {noformat}
> Original issue reported by *bra*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SVN-4917) swig-py: Python ref-cont leak in wrapper of *svn_delta_editor_t() and *svn_repos_parse_fns3_t()
[ https://issues.apache.org/jira/browse/SVN-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg updated SVN-4917: - Affects Version/s: (was: trunk) > swig-py: Python ref-cont leak in wrapper of *svn_delta_editor_t() and > *svn_repos_parse_fns3_t() > > > Key: SVN-4917 > URL: https://issues.apache.org/jira/browse/SVN-4917 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Daniel Sahlberg >Priority: Major > > Wrapper functions of C APIs which drive *svn_delta_editor_t() and > svn_repos_parse_fns3_t does not release reference of intermediate baton which > are created during processing call back of the API when an error is occured > during proccessing call back of the API. > > I think this affects all versions after those functions were implemented, > but I didn't check. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SVN-4918) swig-py: parse_fns3 driver object and parse_baton can make a circular reference which causes Python reference leak
[ https://issues.apache.org/jira/browse/SVN-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg updated SVN-4918: - Affects Version/s: (was: trunk) > swig-py: parse_fns3 driver object and parse_baton can make a circular > reference which causes Python reference leak > -- > > Key: SVN-4918 > URL: https://issues.apache.org/jira/browse/SVN-4918 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Daniel Sahlberg >Priority: Major > > parse_fns3 driver object and parse_baton can make a circular references > through the pool cleanup callback registration which is not visible by Python > interpreter. > > If parse_fn3 driver and parse_baton object are allocated from same pool, the > python wrapper object of the pool and its entity pool can't clean up. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SVN-4916) swig-py: Python ref-count leak on delta.editor object and repos.make_parse_fns3 object
[ https://issues.apache.org/jira/browse/SVN-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg updated SVN-4916: - Affects Version/s: (was: trunk) > swig-py: Python ref-count leak on delta.editor object and > repos.make_parse_fns3 object > -- > > Key: SVN-4916 > URL: https://issues.apache.org/jira/browse/SVN-4916 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Daniel Sahlberg >Priority: Major > > An edit baton made by delta.make_editor / a parse_fns3 baton made by > repos.make_parse_fns3 hold a reference of editor object / parse_fns3 object > and they never release it. > > This was pointed out in the Trac Open Source Project ticket #13112[1], > #13129[2], and #13356[3]. > > [1] repository sync with large Subversion repository has memory leaks > [https://trac.edgewall.org/ticket/13112] > [2] trac-admin resync leaks memory > [https://trac.edgewall.org/ticket/13129] > [3] Subversion pool is destroyed more than once while testing > trac/versioncontrol/tests/functional.py, comment 6 > [https://trac.edgewall.org/ticket/13356#comment:6] > > I think this affects all versions after those functions were implemented, > but I didn't check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SVN-4622) revert as root always notifies for files
[ https://issues.apache.org/jira/browse/SVN-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17800539#comment-17800539 ] Daniel Sahlberg commented on SVN-4622: -- Started a discussion on dev@: https://lists.apache.org/thread/sfkzqzgwr4wvvwfdcyhqgymhx6lmv24h > revert as root always notifies for files > > > Key: SVN-4622 > URL: https://issues.apache.org/jira/browse/SVN-4622 > Project: Subversion > Issue Type: Bug > Components: libsvn_subr >Affects Versions: all >Reporter: Philip Martin >Priority: Minor > > $ svnadmin create repo > $ svn import -mm repo/format file://`pwd`/repo/f > $ umask 0022 > $ svn co file://`pwd`/repo wc > $ sudo svn revert wc/f > Reverted 'wc/f' > The function svn_io__is_finfo_read_only() will check the world permissions > when invoked with uid=root. A typical umask removes world write so this means > that root sees every file as read-only. This causes the revert code to invoke > svn_io_set_file_read_write() and notify. However svn_io_set_file_read_write() > sets the owner permissions, an operation that succeeds when run as root, and > obeys the umask so the world permissions remain read-only. > Reported by: > https://mail-archives.apache.org/mod_mbox/subversion-users/201602.mbox/%3C56C0738E.9010508%40i.ua%3E > http://svn.haxx.se/users/archive-2016-02/0061.shtml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SVN-4735) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/SVN-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg closed SVN-4735. > Please delete old releases from mirroring system > > > Key: SVN-4735 > URL: https://issues.apache.org/jira/browse/SVN-4735 > Project: Subversion > Issue Type: Task >Reporter: Sebb >Priority: Major > > To reduce the load on the ASF mirrors, projects are required to delete old > releases [1] > Please can you remove all non-current releases? > It's unfair to expect the 3rd party mirrors to carry old releases. > It looks like only 1.10.0 and 1.9.7 are still supported so all other versions > should please be removed from the mirrors. > The mirrors also contain two files which are not listed on the download page: > svn_version.h.dist-1.9.7 > svn_version.h.dist-1.8.19 > These don't appear to belong on the mirrors. > Thanks! > [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SVN-4785) Fix foreign repo copy with peg/operative revisions
[ https://issues.apache.org/jira/browse/SVN-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg closed SVN-4785. Didn't check actual version but surely included in 1.14. > Fix foreign repo copy with peg/operative revisions > -- > > Key: SVN-4785 > URL: https://issues.apache.org/jira/browse/SVN-4785 > Project: Subversion > Issue Type: Task > Components: libsvn_client >Affects Versions: 1.8.0, 1.8.19, 1.9.0, 1.10.0, 1.11.0, 1.9.9, 1.10.3 >Reporter: Julian Foad >Priority: Major > Fix For: 1.14.0 > > > It has been broken since first introduced in 1.8. > It was resolving to given URL by following to the operative revision, and > then trying to resolve it again. If the URL differed (that is, if the source > was moved between its operative and peg revisions), this would lead to > copying from the wrong source URL or failing to find the source URL. > Found by code inspection; no bug reports seen. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SVN-4785) Fix foreign repo copy with peg/operative revisions
[ https://issues.apache.org/jira/browse/SVN-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg updated SVN-4785: - Fix Version/s: 1.14.0 > Fix foreign repo copy with peg/operative revisions > -- > > Key: SVN-4785 > URL: https://issues.apache.org/jira/browse/SVN-4785 > Project: Subversion > Issue Type: Task > Components: libsvn_client >Affects Versions: 1.8.0, 1.8.19, 1.9.0, 1.10.0, 1.11.0, 1.9.9, 1.10.3 >Reporter: Julian Foad >Priority: Major > Fix For: 1.14.0 > > > It has been broken since first introduced in 1.8. > It was resolving to given URL by following to the operative revision, and > then trying to resolve it again. If the URL differed (that is, if the source > was moved between its operative and peg revisions), this would lead to > copying from the wrong source URL or failing to find the source URL. > Found by code inspection; no bug reports seen. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SVN-4532) assert abort with -rprev for wc at r0
[
https://issues.apache.org/jira/browse/SVN-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg closed SVN-4532.
didn't check actual released version but surely in 1.14
> assert abort with -rprev for wc at r0
> -
>
> Key: SVN-4532
> URL: https://issues.apache.org/jira/browse/SVN-4532
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_wc
>Affects Versions: trunk
>Reporter: Philip Martin
>Priority: Major
> Fix For: 1.14.0
>
>
> {noformat:nopanel=true}
> With trunk:
> $ svnadmin create repo
> $ svn co file://`pwd`/repo wc
> $ svn diff -rprev wc
> svn: E235000: In file '../src/subversion/libsvn_client/ra.c' line 679:
> assertion
> failed (SVN_IS_VALID_REVNUM(start_revnum))
> Aborted
> 1.8 also has the abort, 1.7 and 1.6 exit with an error:
> svn: E160006: Invalid revision number '-1'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SVN-4532) assert abort with -rprev for wc at r0
[
https://issues.apache.org/jira/browse/SVN-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg updated SVN-4532:
-
Fix Version/s: 1.14.0
> assert abort with -rprev for wc at r0
> -
>
> Key: SVN-4532
> URL: https://issues.apache.org/jira/browse/SVN-4532
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_wc
>Affects Versions: trunk
>Reporter: Philip Martin
>Priority: Major
> Fix For: 1.14.0
>
>
> {noformat:nopanel=true}
> With trunk:
> $ svnadmin create repo
> $ svn co file://`pwd`/repo wc
> $ svn diff -rprev wc
> svn: E235000: In file '../src/subversion/libsvn_client/ra.c' line 679:
> assertion
> failed (SVN_IS_VALID_REVNUM(start_revnum))
> Aborted
> 1.8 also has the abort, 1.7 and 1.6 exit with an error:
> svn: E160006: Invalid revision number '-1'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-4782) Using (const char*)1 in Apache HTTP server modules as value for r->notes cause httpd to crash
[ https://issues.apache.org/jira/browse/SVN-4782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg closed SVN-4782. Didn't check actual version including this fix but it has surely been released. Closing. > Using (const char*)1 in Apache HTTP server modules as value for r->notes > cause httpd to crash > - > > Key: SVN-4782 > URL: https://issues.apache.org/jira/browse/SVN-4782 > Project: Subversion > Issue Type: Bug >Affects Versions: 1.9.x, trunk, 1.10.x, 1.11.x > Environment: All environments >Reporter: Ruediger Pluem >Priority: Major > Labels: patch > Fix For: 1.14.0 > > Attachments: notes_fix.diff > > > *mod_authz_svn.c* and *mod_dav_svn.c* add keys to *r->notes* to memorize > boolean states (*FORCE_AUTHN_NOTE*, *IN_SOME_AUTHN_NOTE*, > *authz_svn-anon-ok*, *NO_MAP_TO_STORAGE_NOTE*). They use _(const char*)1_ as > values for the keys. This causes any call to *apr_table_clone* for *r->notes* > to crash with a SEGFAULT, because _(const char*)1_ is an invalid address. > *mod_http2* in httpd calls *apr_table_clone* for *r->notes* and hence the > httpd process crashes. The attached patch (against trunk) replaces the value > of _(const char*)1_ in these cases with a value of _"1"_. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SVN-4782) Using (const char*)1 in Apache HTTP server modules as value for r->notes cause httpd to crash
[ https://issues.apache.org/jira/browse/SVN-4782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg updated SVN-4782: - Fix Version/s: 1.14.0 > Using (const char*)1 in Apache HTTP server modules as value for r->notes > cause httpd to crash > - > > Key: SVN-4782 > URL: https://issues.apache.org/jira/browse/SVN-4782 > Project: Subversion > Issue Type: Bug >Affects Versions: 1.9.x, trunk, 1.10.x, 1.11.x > Environment: All environments >Reporter: Ruediger Pluem >Priority: Major > Labels: patch > Fix For: 1.14.0 > > Attachments: notes_fix.diff > > > *mod_authz_svn.c* and *mod_dav_svn.c* add keys to *r->notes* to memorize > boolean states (*FORCE_AUTHN_NOTE*, *IN_SOME_AUTHN_NOTE*, > *authz_svn-anon-ok*, *NO_MAP_TO_STORAGE_NOTE*). They use _(const char*)1_ as > values for the keys. This causes any call to *apr_table_clone* for *r->notes* > to crash with a SEGFAULT, because _(const char*)1_ is an invalid address. > *mod_http2* in httpd calls *apr_table_clone* for *r->notes* and hence the > httpd process crashes. The attached patch (against trunk) replaces the value > of _(const char*)1_ in these cases with a value of _"1"_. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SVN-4773) Release 1.11
[ https://issues.apache.org/jira/browse/SVN-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg closed SVN-4773. > Release 1.11 > > > Key: SVN-4773 > URL: https://issues.apache.org/jira/browse/SVN-4773 > Project: Subversion > Issue Type: Task >Reporter: Julian Foad >Assignee: Julian Foad >Priority: Major > Fix For: 1.11.0 > > > An umbrella issue to contain the sub-tasks for 1.11 release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SVN-4793) ACEs for inverted groups in authz rules are not applied
[
https://issues.apache.org/jira/browse/SVN-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg closed SVN-4793.
> ACEs for inverted groups in authz rules are not applied
> ---
>
> Key: SVN-4793
> URL: https://issues.apache.org/jira/browse/SVN-4793
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_repos
>Affects Versions: 1.10.x, 1.11.0
>Reporter: Branko Čibej
>Assignee: Branko Čibej
>Priority: Major
>
> With the following authorization file:
> {noformat}
> [groups]
> readonly = jconstant
> [/]
> $anonymous =
> ~@readonly = rw
> @readonly = r
> {noformat}
> access to any repository fails for an authenticated user that is not in the
> _@readonly_ group.
> {noformat}
> $ svn list --username jrandom .../repo
> svn: E170001: Authorization failed
> {noformat}
> Reported [on
> dev@|https://lists.apache.org/thread.html/6cc7b22b211827ff946373407a516a3ab4d866fe03cdc85d22ff276b@%3Cdev.subversion.apache.org%3E]
> by Pavel Goran.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-4801) JavaHL blame() callback tries to send arbitrary line data in a String parameter
[ https://issues.apache.org/jira/browse/SVN-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg closed SVN-4801. > JavaHL blame() callback tries to send arbitrary line data in a String > parameter > --- > > Key: SVN-4801 > URL: https://issues.apache.org/jira/browse/SVN-4801 > Project: Subversion > Issue Type: Bug > Components: bindings_javahl >Affects Versions: 1.11.x >Reporter: Julian Foad >Assignee: Branko Čibej >Priority: Major > Fix For: 1.12.0 > > > BlameCallback::singleLine(..., String line, ...) > should be > BlameCallback::singleLine(..., byte[] line, ...) > otherwise non-UTF-8 file data is likely to throw an exception here, with no > good work-around. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SVN-4804) wc-queries-tests fail with SQLite's profiling enabled
[
https://issues.apache.org/jira/browse/SVN-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg closed SVN-4804.
> wc-queries-tests fail with SQLite's profiling enabled
> -
>
> Key: SVN-4804
> URL: https://issues.apache.org/jira/browse/SVN-4804
> Project: Subversion
> Issue Type: Improvement
> Components: libsvn_wc
>Affects Versions: all
> Environment: Reproduced on macOS amd64 with amalgamated SQLite 3.26.0.
>Reporter: Branko Čibej
>Assignee: Branko Čibej
>Priority: Major
>
> See: [https://bugs.gentoo.org/605438].
> (Please notify downstream when this issue is resolved.)
> Adding {{-DSQLITE_ENABLE_STMT_SCANSTATUS}} to {{CPPFLAGS}} causes on of the
> {{wc-query-tests}} to fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-4760) Missing children when svnadmin dump --include/exclude converts copy-dir to add-dir
[
https://issues.apache.org/jira/browse/SVN-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg closed SVN-4760.
> Missing children when svnadmin dump --include/exclude converts copy-dir to
> add-dir
> --
>
> Key: SVN-4760
> URL: https://issues.apache.org/jira/browse/SVN-4760
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_repos
>Affects Versions: 1.10.0
> Environment: CentOS 6.5
>Reporter: Nathan.qian
>Assignee: Julian Foad
>Priority: Major
> Attachments: image-2018-07-04-13-07-26-602.png
>
>
> During I am testing the '{{\-\-include}}' and '{{\-\-exclude}}' options on
> '{{svnadmin dump}}' , I found that if I copy a non-include file, the dump
> result is to add a file with file content; But if the copy is a non-include
> directory, the dump only adds this directory.
> I think, this may be wrong, it should be copy of the directory and all the
> files under the directory .
>
> {noformat}
> [root@RD-230 subversion]# svnadmin dump /data1/svnroot/Dev --incremental -r
> 13386 --include "/CM Action/Tools" > /tmp/test.dmp
> * 已转存版本 13386。
> [root@RD-230 subversion]# cat /tmp/test.dmp
> SVN-fs-dump-format-version: 2UUID: 313b818e-f7ce-944b-8d5d-4aca2895b6b9
> Revision-number: 13386
> Prop-content-length: 89
> Content-length: 89
> K 10
> svn:author
> V 11
> qianhaiyuan
> K 8
> svn:date
> V 27
> 2018-07-04T04:18:48.877124Z
> PROPS-END
> Node-path: CM Action/Tools/diffcount
> Node-kind: dir
> Node-action: add
> Prop-content-length: 10
> Content-length: 10
> PROPS-END
> {noformat}
>
> In fact, the copy directory has many files. But the dump file is only add a
> new dir.
> !image-2018-07-04-13-07-26-602.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-4803) Enable SVN AuthZ parsing to emit Warning messages
[ https://issues.apache.org/jira/browse/SVN-4803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg closed SVN-4803. > Enable SVN AuthZ parsing to emit Warning messages > - > > Key: SVN-4803 > URL: https://issues.apache.org/jira/browse/SVN-4803 > Project: Subversion > Issue Type: Improvement > Components: libsvn_repos, mod_authz_svn, svnauthz, svnserve >Reporter: Douglas Robinson >Assignee: Branko Čibej >Priority: Major > > It would really help if, when parsing the SVN AuthZ file, warnings could be > emitted for various types of issues that are not really errors but could > point to a mistake. > +Examples+: > # Group definition with no accounts > # Reference to an undefined group -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SVN-4802) Allow empty groups in AuthZ files
[
https://issues.apache.org/jira/browse/SVN-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg closed SVN-4802.
> Allow empty groups in AuthZ files
> -
>
> Key: SVN-4802
> URL: https://issues.apache.org/jira/browse/SVN-4802
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_repos, svnauthz
>Affects Versions: 1.10.x, 1.11.x
>Reporter: Douglas Robinson
>Assignee: Branko Čibej
>Priority: Major
> Fix For: 1.12.0
>
>
> If a group is defined in an AuthZ file without an associated account that SVN
> is, as of 1.10, generating an error and failing to allow the use of that
> AuthZ file.
> Example:
> {noformat}
> [groups]
> goodGroup = acct1
> goodGroup2 = acct1, acct2
> badGroup =
>
> [repoName:/someplace]
> @badGroup = rw
> {noformat}
> results in:
> {noformat}
> svnauthz: E220003: Error while parsing authz file: ...
> svnauthz: E220003: Access entry refers to undefined group ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-4822) "svn diff --changelist ARG" broken in subdirectories
[ https://issues.apache.org/jira/browse/SVN-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg closed SVN-4822. > "svn diff --changelist ARG" broken in subdirectories > - > > Key: SVN-4822 > URL: https://issues.apache.org/jira/browse/SVN-4822 > Project: Subversion > Issue Type: Bug >Affects Versions: 1.12.x >Reporter: Julian Foad >Assignee: Julian Foad >Priority: Major > Fix For: 1.13.0 > > > "svn diff --changelist ARG" only works in the root of a working copy. In any > subdirectory of the working copy, there's no output at all. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SVN-4828) svn help: hide experimental, deprecated, and global commands and options
[ https://issues.apache.org/jira/browse/SVN-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg closed SVN-4828. > svn help: hide experimental, deprecated, and global commands and options > > > Key: SVN-4828 > URL: https://issues.apache.org/jira/browse/SVN-4828 > Project: Subversion > Issue Type: Improvement > Components: cmdline client >Affects Versions: trunk >Reporter: Julian Foad >Assignee: Julian Foad >Priority: Major > > 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. > Further, I have been thinking for years we should hide by default: > - deprecated commands and options > - the "Global Options" section of "svn help " > The global options are sometimes useful, but really only for power users; > take up the last half a screenful of output; are shown even for commands > where they are irrelevant (all commands accept them but not all use them). > There are only a few deprecated options, so not such a big distraction, but > users don't need to see or learn or care about them at all, except in the > most extreme cases like debugging an old script that uses them. > I plan to hide these three categories by default. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SVN-4744) SVN 1.10 aborts during merge: assertion failed (start_rev > end_rev)
[ https://issues.apache.org/jira/browse/SVN-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg closed SVN-4744. > SVN 1.10 aborts during merge: assertion failed (start_rev > end_rev) > > > Key: SVN-4744 > URL: https://issues.apache.org/jira/browse/SVN-4744 > Project: Subversion > Issue Type: Bug > Components: libsvn_client >Affects Versions: 1.10.0 > Environment: $ svn --version > svn, version 1.10.0 (r1827917) > compiled Apr 17 2018, 08:38:15 on x86_64-redhat-linux-gnu > > Fedora28 (up to date) > Linux rolf-linux 4.16.7-300.fc28.x86_64 #1 SMP Wed May 2 20:09:13 UTC 2018 > x86_64 x86_64 x86_64 GNU/Linux >Reporter: Rolf >Assignee: Stefan Sperling >Priority: Major > Fix For: 1.10.3 > > Attachments: issue-4744.sh, svnlog1.txt, svnlog2.txt > > > I'm running a 2-URL merge, and svn is aborting when trying to resolve > conflicts on a directory that's been added both locally and as part of the > other branch being merged in. I cannot reproduce this using simple setups, I > have not been able to isolate what exactly triggers this behaviour, but it is > reproducable on my repository. > Here's the exact command that I run: > svn merge ^/trunk ^/branches/feature/sempv2_vpn_mon_7 . > It produces many pages of add/modifies/deletes (the merge involve thousands > of files), and then it starts interactive resolution of the conflicts. > Summary of conflicts: > Text conflicts: 40 > Tree conflicts: 64 > I start by choosing "mf" for the first 5 conflicts, and then when it get to > the 6th conflict, it prints this: > > Merge conflicts in 'solcbr/common/commands/config/about/aboutCommands.py' > marked as resolved. > Searching tree conflict details for > 'solcbr/common/commands/config/about/user' in repository: > svn: E235000: In file 'subversion/libsvn_client/conflicts.c' line 2257: > assertion failed (start_rev > end_rev) > Aborted (core dumped) > > For this path the "user" diroctory was added in both the "mon_7" branch and > in the local branch. > > > Backtrace from coredumpctl > > $ coredumpctl dump -o core.core > PID: 12115 (svn) > UID: 1000 (rolf) > GID: 1000 (rolf) > Signal: 6 (ABRT) > Timestamp: Thu 2018-06-07 10:15:53 EDT (2min 43s ago) > Command Line: svn merge -v ^/trunk ^/branches/feature/sempv2_vpn_mon_7 . > Executable: /usr/bin/svn > Control Group: > /user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service > Unit: user@1000.service > User Unit: gnome-terminal-server.service > Slice: user-1000.slice > Owner UID: 1000 (rolf) > Boot ID: bb60a0b96550448fa5b28a1b529839c2 > Machine ID: e2af878696fe4a589a249c535fc30788 > Hostname: rolf-linux > Storage: > /var/lib/systemd/coredump/core.svn.1000.bb60a0b96550448fa5b28a1b529839c2.12115.152838095300.lz4 > Message: Process 12115 (svn) of user 1000 dumped core. > > Stack trace of thread 12115: > #0 0x7fe79bdaaf2b raise (libc.so.6) > #1 0x7fe79bd95561 abort (libc.so.6) > #2 0x7fe79d9f5212 svn_error_abort_on_malfunction > (libsvn_subr-1.so.0) > #3 0x7fe7a01041cf find_revision_for_suspected_deletion > (libsvn_client-1.so.0) > #4 0x7fe7a01072de > conflict_tree_get_details_incoming_add (libsvn_client-1.so.0) > #5 0x7fe7a01034f9 svn_client_conflict_tree_get_details > (libsvn_client-1.so.0) > #6 0x564e75aaa474 svn_cl__resolve_conflict (svn) > #7 0x564e75abb357 conflict_walker (svn) > #8 0x7fe7a010f312 conflict_status_walker > (libsvn_client-1.so.0) > #9 0x7fe79fe6c8a8 send_status_structure > (libsvn_wc-1.so.0) > #10 0x7fe79fe6ded3 get_dir_status (libsvn_wc-1.so.0) > #11 0x7fe79fe6f291 svn_wc__internal_walk_status > (libsvn_wc-1.so.0) > #12 0x7fe7a010f494 svn_client_conflict_walk > (libsvn_client-1.so.0) > #13 0x564e75abb63c svn_cl__walk_conflicts (svn) > #14 0x564e75ab4a58 svn_cl__merge (svn) > #15 0x564e75ac004e sub_main (svn) > #16 0x564e75aa50e7 main (svn) > #17 0x7fe79bd9718b __libc_start_main (libc.so.6) > #18 0x564e75aa516a _start (svn) > > > I have a 39M core file. Should I attach a compressed version of it? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SVN-4840) Merge assertion failure in svn_sort__array_insert
[
https://issues.apache.org/jira/browse/SVN-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg closed SVN-4840.
> Merge assertion failure in svn_sort__array_insert
> -
>
> Key: SVN-4840
> URL: https://issues.apache.org/jira/browse/SVN-4840
> Project: Subversion
> Issue Type: Bug
>Affects Versions: 1.10.0, 1.13.0, 1.10.6
>Reporter: Julian Foad
>Priority: Major
> Attachments: issue4840-fix-1.patch
>
>
> I am investigating an assertion failure. I received a stack trace without
> parameter values, from which I quote the relevant part:
>
> {code:java}
> #4 svn_sort__array_insert (array=?, new_element=?, insert_index=?)
> at subversion/libsvn_subr/sorts.c:310
> assert(0 <= insert_index && insert_index <= array->nelts);
> #5 svn_rangelist_merge2 (rangelist=?, chg=?,)
> at subversion/libsvn_subr/mergeinfo.c:1231
> svn_sort__array_insert(rangelist, &range_copy, i++);
> #6 svn_mergeinfo_merge2 (mergeinfo=?, changes=?,)
> at subversion/libsvn_subr/mergeinfo.c:1838
> #7 combine_forked_mergeinfo_props (...)
> at subversion/libsvn_wc/props.c:138
> #8 apply_single_mergeinfo_prop_change (...)
> at subversion/libsvn_wc/props.c:1087
> {code}
> This was reported in Subversion 1.10.4. I have reproduced with 1.10.6 and
> trunk@1871000.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-4837) Cannot get info for a file that was inside of file-replaced directory
[ https://issues.apache.org/jira/browse/SVN-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg closed SVN-4837. > Cannot get info for a file that was inside of file-replaced directory > - > > Key: SVN-4837 > URL: https://issues.apache.org/jira/browse/SVN-4837 > Project: Subversion > Issue Type: Bug >Affects Versions: 1.10.0, 1.13.0 >Reporter: Julian Foad >Assignee: Julian Foad >Priority: Major > > dev@ email thread "Cannot get info for a file that was inside of > file-replaced directory", 2019-11-22, > https://lists.apache.org/thread.html/04b1a76c24a8ef6478665fc6c3a541a5e497f03d72158b396f44f18c@%3Cdev.subversion.apache.org%3E -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SVN-4841) Subversion fails to compile with ruby-2.7
[
https://issues.apache.org/jira/browse/SVN-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg closed SVN-4841.
> Subversion fails to compile with ruby-2.7
> -
>
> Key: SVN-4841
> URL: https://issues.apache.org/jira/browse/SVN-4841
> Project: Subversion
> Issue Type: Bug
> Components: bindings_swig_ruby
>Affects Versions: 1.13.0
> Environment: Arch Linux with ruby 2.7
>Reporter: Anatol Pomozov
>Assignee: James McCoy
>Priority: Major
> Fix For: 1.14.0
>
>
> I am trying to compile subversion with ruby-2.7 and there is an issue:
>
> first there is a suspicious compiler warning:
> {noformat}
> gcc: error: unrecognized command line option ‘-prefer-pic’
> [root@wolf subversion-1.13.0]# gcc -march=x86-64 -mtune=generic -O2 -pipe
> -fno-plt -pthread -Wno-int-to-pointer-cast -D_FORTIFY_SOURCE=2 -DLINUX
> -D_REENTRANT -D_GNU_SOURCE -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_CORE_LIB
> -I/build/subversion/src/subversion-1.13.0/subversion
> -I/build/subversion/src/subversion-1.13.0/subversion/include
> -I/build/subversion/src/subversion-1.13.0/subversion/bindings/swig
> -I/build/subversion/src/subversion-1.13.0/subversion/bindings/swig/include
> -I/build/subversion/src/subversion-1.13.0/subversion/bindings/swig/proxy
> -I/build/subversion/src/subversion-1.13.0/subversion/bindings/swig/proxy
> -I/usr/include/apr-1 -I/usr/include/apr-1 -I/usr/include -I.
> -I/usr/include/ruby-2.7.0 -I/usr/include/ruby-2.7.0/ruby
> -I/usr/include/ruby-2.7.0/ruby/backward
> -I/usr/include/ruby-2.7.0/x86_64-linux
> -I/build/subversion/src/subversion-1.13.0/subversion/bindings/swig/ruby/libsvn_swig_ruby
> -c -o subversion/bindings/swig/ruby/svn_client.lo
> subversion/bindings/swig/ruby/svn_client.c
> subversion/bindings/swig/ruby/svn_client.c: In function
> ‘SWIG_Ruby_ConvertPtrAndOwn’:
> subversion/bindings/swig/ruby/svn_client.c:1666:13: warning: implicit
> declaration of function ‘assert’ [-Wimplicit-function-declaration]
> 1666 | assert(own); /* badly formed typemap which will lead to a memory leak
> - it must set and use own to delete *ptr */
> | ^~
> subversion/bindings/swig/ruby/svn_client.c:1394:1: note: ‘assert’ is defined
> in header ‘’; did you forget to ‘#include ’?
> 1393 | #include "assert.h"
> +++ |+#include
> 1394 |{noformat}
>
> Then ruby tests fail:
> {noformat}
> /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require':
> /build/subversion/src/subversion-1.13.0/subversion/bindings/swig/ruby/libsvn_swig_ruby/.libs/libsvn_swig_ruby-1.so.0:
> undefined symbol: assert -
> /build/subversion/src/subversion-1.13.0/subversion/bindings/swig/ruby/.ext/svn/ext/core.so
> (LoadError)
> from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in
> `require'
> from
> /build/subversion/src/subversion-1.13.0/subversion/bindings/swig/ruby/svn/error.rb:21:in
> `'
> from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in
> `require'
> from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in
> `require'
> from
> /build/subversion/src/subversion-1.13.0/subversion/bindings/swig/ruby/svn/core.rb:25:in
> `'
> from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in
> `require'
> from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in
> `require'
> from
> /build/subversion/src/subversion-1.13.0/subversion/bindings/swig/ruby/test/run-test.rb:47:in
> `'
> make: *** [Makefile:962: check-swig-rb] Error 1{noformat}
>
> After some debugging I found that ruby-2.7 introduced a new file under
> '/usr/include/ruby-2.7.0/ruby/assert.h' and subversion build includes path
> '/usr/include/ruby-2.7.0/' before standard includes path. Thus ruby's version
> of "assert.h" gets included and it contains no definition of assert()
> function.
>
> Is it something you can fix?
>
> I feel that /usr/include/ruby-2.7.0/ include path should be enough for
> subversion. No need to include /usr/include/ruby-2.7.0/ruby and
> /usr/include/ruby-2.7.0/backward in build/ac-macros/swig.m4
> {noformat}
> AC_CACHE_CHECK([for Ruby include path], [svn_cv_ruby_includes],[
> if test -d "$rbconfig_rubyhdrdir"; then
> dnl Ruby >=1.9
> svn_cv_ruby_includes="-I. -I$rbconfig_rubyhdrdir
> -I$rbconfig_rubyhdrdir/ruby -I$rbconfig_rubyhdrdir/ruby/backward"
> if test -d "$rbc
[jira] [Closed] (SVN-4862) Merge: the resulting mergeinfo is non-deterministic
[
https://issues.apache.org/jira/browse/SVN-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg closed SVN-4862.
> Merge: the resulting mergeinfo is non-deterministic
> ---
>
> Key: SVN-4862
> URL: https://issues.apache.org/jira/browse/SVN-4862
> Project: Subversion
> Issue Type: Bug
>Affects Versions: 1.14.0, 1.10.6
>Reporter: Julian Foad
>Priority: Major
> Fix For: 1.14.1, 1.10.7
>
>
> In a particular merge scenario (e.g. merge_tests.py 143, see SVN-4859), the
> merge result is non-deterministic: it produces slightly different results on
> different runs, at random.
> The variations in output are (in that test):
> {code:none}
> --- Recording mergeinfo for merge of r3 through r7 into '.../A':
> U .../A
> --- Recording mergeinfo for merge of r3 through r7 into '.../A/D/G':
> G .../A/D/G
> --- Recording mergeinfo for merge of r3 through r7 into '.../A/D/G2':
> G .../A/D/G2
> G .../A/D
> svn pg -R svn:mergeinfo A/
> A - /branch_A:3-7
> A/D- /branch_A/D:5-7 /branch_B/C:1*
> A/D/G - /branch_A/D/G:5-7 /branch_B/C/G:1*
> A/D/G2 - /branch_A/D/G2:5-7 /branch_B/C/G2:1*
> {code}
> vs.
> {code:none}
> --- Recording mergeinfo for merge of r3 through r7 into '.../A':
> U .../A
> --- Recording mergeinfo for merge of r3 through r7 into '.../A/D/G':
> U .../A/D/G
> --- Recording mergeinfo for merge of r3 through r7 into '.../A/D/G2':
> U .../A/D/G2
> G .../A/D
> svn pg -R svn:mergeinfo A/
> A - /branch_A:3-7
> A/D- /branch_A/D:5-7 /branch_B/C:1*
> A/D/G - /branch_A/D/G:5-7 /branch_B/C/G:1*
> A/D/G2 - /branch_A/D/G2:6-7 /branch_B/C/G2:1*
> or
> A - /branch_A:3-7
> A/D- /branch_A/D:5-7 /branch_B/C:1*
> A/D/G - /branch_A/D/G:6-7 /branch_B/C/G:1*
> A/D/G2 - /branch_A/D/G2:6-7 /branch_B/C/G2:1*
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-4775) Use private namespace for experimental APIs
[
https://issues.apache.org/jira/browse/SVN-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg closed SVN-4775.
> Use private namespace for experimental APIs
> ---
>
> Key: SVN-4775
> URL: https://issues.apache.org/jira/browse/SVN-4775
> Project: Subversion
> Issue Type: Bug
>Reporter: Julian Foad
>Assignee: Julian Foad
>Priority: Critical
> Attachments: api-x-layout.patch, api-x-shelving.patch
>
>
> Proposal: -experimental APIs should have an "x-" prefix ("svn_x_")-.
> experimental APIs should have a prefix that puts them in our private
> namespace, so "svn_client__" etc.
> This is being discussed on dev@ in the thread "API review for 1.11; do we
> need to mark new APIs as experimental?" started on 2018-09-12.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SVN-1778) [python] FileDiff broken on Windows
[
https://issues.apache.org/jira/browse/SVN-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg resolved SVN-1778.
--
Fix Version/s: 1.10.x
Resolution: Fixed
The internal diff implementation is included since 1.10. The improved error
message and docstring will be included in 1.15
> [python] FileDiff broken on Windows
> ---
>
> Key: SVN-1778
> URL: https://issues.apache.org/jira/browse/SVN-1778
> Project: Subversion
> Issue Type: Bug
> Components: bindings_swig_python
>Affects Versions: all
> Environment: Windows 2000
>Reporter: Subversion Importer
>Priority: Critical
> Fix For: 1.10.x, 1.15
>
>
> {noformat:nopanel=true}
> In function get_pipe, class FileDiff spawns a "diff" process, but usually no
> "diff.exe" executable is available under Windows, so the FileDiff class might
> be
> completely non-functional on most Win installation. Maybe using Python difflib
> calls could be a better solution.
> {noformat}
> Original issue reported by *iaanus*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-1778) [python] FileDiff broken on Windows
[
https://issues.apache.org/jira/browse/SVN-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772110#comment-17772110
]
Daniel Sahlberg commented on SVN-1778:
--
Discussed on dev@:
[https://lists.apache.org/thread/hfnfq4v6jytod1xr4dsttp00ptfgmfgr]
r1912724 adds a docstring to FileDiff.get_pipe() documenting this behaviour.
r1912743 improves the errstr in the exception to say that the "external diff
command" is not found.
> [python] FileDiff broken on Windows
> ---
>
> Key: SVN-1778
> URL: https://issues.apache.org/jira/browse/SVN-1778
> Project: Subversion
> Issue Type: Bug
> Components: bindings_swig_python
>Affects Versions: all
> Environment: Windows 2000
>Reporter: Subversion Importer
>Priority: Critical
> Fix For: unscheduled
>
>
> {noformat:nopanel=true}
> In function get_pipe, class FileDiff spawns a "diff" process, but usually no
> "diff.exe" executable is available under Windows, so the FileDiff class might
> be
> completely non-functional on most Win installation. Maybe using Python difflib
> calls could be a better solution.
> {noformat}
> Original issue reported by *iaanus*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SVN-1778) [python] FileDiff broken on Windows
[
https://issues.apache.org/jira/browse/SVN-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg updated SVN-1778:
-
Fix Version/s: 1.15
(was: unscheduled)
> [python] FileDiff broken on Windows
> ---
>
> Key: SVN-1778
> URL: https://issues.apache.org/jira/browse/SVN-1778
> Project: Subversion
> Issue Type: Bug
> Components: bindings_swig_python
>Affects Versions: all
> Environment: Windows 2000
>Reporter: Subversion Importer
>Priority: Critical
> Fix For: 1.15
>
>
> {noformat:nopanel=true}
> In function get_pipe, class FileDiff spawns a "diff" process, but usually no
> "diff.exe" executable is available under Windows, so the FileDiff class might
> be
> completely non-functional on most Win installation. Maybe using Python difflib
> calls could be a better solution.
> {noformat}
> Original issue reported by *iaanus*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4918) swig-py: parse_fns3 driver object and parse_baton can make a circular reference which causes Python reference leak
[ https://issues.apache.org/jira/browse/SVN-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770886#comment-17770886 ] Daniel Sahlberg commented on SVN-4918: -- Fixed by [http://svn.apache.org/viewvc?rev=1912500&view=rev|http://svn.apache.org/viewvc?rev=1912515&view=rev] > swig-py: parse_fns3 driver object and parse_baton can make a circular > reference which causes Python reference leak > -- > > Key: SVN-4918 > URL: https://issues.apache.org/jira/browse/SVN-4918 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: trunk, 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Yasuhito Futatsuki >Priority: Major > > parse_fns3 driver object and parse_baton can make a circular references > through the pool cleanup callback registration which is not visible by Python > interpreter. > > If parse_fn3 driver and parse_baton object are allocated from same pool, the > python wrapper object of the pool and its entity pool can't clean up. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SVN-4918) swig-py: parse_fns3 driver object and parse_baton can make a circular reference which causes Python reference leak
[ https://issues.apache.org/jira/browse/SVN-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg reassigned SVN-4918: Assignee: Daniel Sahlberg (was: Yasuhito Futatsuki) > swig-py: parse_fns3 driver object and parse_baton can make a circular > reference which causes Python reference leak > -- > > Key: SVN-4918 > URL: https://issues.apache.org/jira/browse/SVN-4918 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: trunk, 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Daniel Sahlberg >Priority: Major > > parse_fns3 driver object and parse_baton can make a circular references > through the pool cleanup callback registration which is not visible by Python > interpreter. > > If parse_fn3 driver and parse_baton object are allocated from same pool, the > python wrapper object of the pool and its entity pool can't clean up. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SVN-4916) swig-py: Python ref-count leak on delta.editor object and repos.make_parse_fns3 object
[ https://issues.apache.org/jira/browse/SVN-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770884#comment-17770884 ] Daniel Sahlberg edited comment on SVN-4916 at 10/1/23 4:07 PM: --- Fixed by [http://svn.apache.org/viewvc?rev=1912500&view=rev|http://svn.apache.org/viewvc?rev=1912515&view=rev] was (Author: dsahlberg): Fixed by [http://svn.apache.org/viewvc?rev=1912501&view=rev|http://svn.apache.org/viewvc?rev=1912515&view=rev] > swig-py: Python ref-count leak on delta.editor object and > repos.make_parse_fns3 object > -- > > Key: SVN-4916 > URL: https://issues.apache.org/jira/browse/SVN-4916 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: trunk, 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Daniel Sahlberg >Priority: Major > > An edit baton made by delta.make_editor / a parse_fns3 baton made by > repos.make_parse_fns3 hold a reference of editor object / parse_fns3 object > and they never release it. > > This was pointed out in the Trac Open Source Project ticket #13112[1], > #13129[2], and #13356[3]. > > [1] repository sync with large Subversion repository has memory leaks > [https://trac.edgewall.org/ticket/13112] > [2] trac-admin resync leaks memory > [https://trac.edgewall.org/ticket/13129] > [3] Subversion pool is destroyed more than once while testing > trac/versioncontrol/tests/functional.py, comment 6 > [https://trac.edgewall.org/ticket/13356#comment:6] > > I think this affects all versions after those functions were implemented, > but I didn't check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SVN-4916) swig-py: Python ref-count leak on delta.editor object and repos.make_parse_fns3 object
[ https://issues.apache.org/jira/browse/SVN-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770884#comment-17770884 ] Daniel Sahlberg commented on SVN-4916: -- Fixed by [http://svn.apache.org/viewvc?rev=1912501&view=rev|http://svn.apache.org/viewvc?rev=1912515&view=rev] > swig-py: Python ref-count leak on delta.editor object and > repos.make_parse_fns3 object > -- > > Key: SVN-4916 > URL: https://issues.apache.org/jira/browse/SVN-4916 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: trunk, 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Yasuhito Futatsuki >Priority: Major > > An edit baton made by delta.make_editor / a parse_fns3 baton made by > repos.make_parse_fns3 hold a reference of editor object / parse_fns3 object > and they never release it. > > This was pointed out in the Trac Open Source Project ticket #13112[1], > #13129[2], and #13356[3]. > > [1] repository sync with large Subversion repository has memory leaks > [https://trac.edgewall.org/ticket/13112] > [2] trac-admin resync leaks memory > [https://trac.edgewall.org/ticket/13129] > [3] Subversion pool is destroyed more than once while testing > trac/versioncontrol/tests/functional.py, comment 6 > [https://trac.edgewall.org/ticket/13356#comment:6] > > I think this affects all versions after those functions were implemented, > but I didn't check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SVN-4916) swig-py: Python ref-count leak on delta.editor object and repos.make_parse_fns3 object
[ https://issues.apache.org/jira/browse/SVN-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg reassigned SVN-4916: Assignee: Daniel Sahlberg (was: Yasuhito Futatsuki) > swig-py: Python ref-count leak on delta.editor object and > repos.make_parse_fns3 object > -- > > Key: SVN-4916 > URL: https://issues.apache.org/jira/browse/SVN-4916 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: trunk, 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Daniel Sahlberg >Priority: Major > > An edit baton made by delta.make_editor / a parse_fns3 baton made by > repos.make_parse_fns3 hold a reference of editor object / parse_fns3 object > and they never release it. > > This was pointed out in the Trac Open Source Project ticket #13112[1], > #13129[2], and #13356[3]. > > [1] repository sync with large Subversion repository has memory leaks > [https://trac.edgewall.org/ticket/13112] > [2] trac-admin resync leaks memory > [https://trac.edgewall.org/ticket/13129] > [3] Subversion pool is destroyed more than once while testing > trac/versioncontrol/tests/functional.py, comment 6 > [https://trac.edgewall.org/ticket/13356#comment:6] > > I think this affects all versions after those functions were implemented, > but I didn't check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SVN-4917) swig-py: Python ref-cont leak in wrapper of *svn_delta_editor_t() and *svn_repos_parse_fns3_t()
[ https://issues.apache.org/jira/browse/SVN-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sahlberg reassigned SVN-4917: Assignee: Daniel Sahlberg (was: Yasuhito Futatsuki) > swig-py: Python ref-cont leak in wrapper of *svn_delta_editor_t() and > *svn_repos_parse_fns3_t() > > > Key: SVN-4917 > URL: https://issues.apache.org/jira/browse/SVN-4917 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: trunk, 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Daniel Sahlberg >Priority: Major > > Wrapper functions of C APIs which drive *svn_delta_editor_t() and > svn_repos_parse_fns3_t does not release reference of intermediate baton which > are created during processing call back of the API when an error is occured > during proccessing call back of the API. > > I think this affects all versions after those functions were implemented, > but I didn't check. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SVN-4917) swig-py: Python ref-cont leak in wrapper of *svn_delta_editor_t() and *svn_repos_parse_fns3_t()
[ https://issues.apache.org/jira/browse/SVN-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770885#comment-17770885 ] Daniel Sahlberg commented on SVN-4917: -- Fixed by [http://svn.apache.org/viewvc?rev=1912500&view=rev|http://svn.apache.org/viewvc?rev=1912515&view=rev] > swig-py: Python ref-cont leak in wrapper of *svn_delta_editor_t() and > *svn_repos_parse_fns3_t() > > > Key: SVN-4917 > URL: https://issues.apache.org/jira/browse/SVN-4917 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: trunk, 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Daniel Sahlberg >Priority: Major > > Wrapper functions of C APIs which drive *svn_delta_editor_t() and > svn_repos_parse_fns3_t does not release reference of intermediate baton which > are created during processing call back of the API when an error is occured > during proccessing call back of the API. > > I think this affects all versions after those functions were implemented, > but I didn't check. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SVN-1778) [python] FileDiff broken on Windows
[
https://issues.apache.org/jira/browse/SVN-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770870#comment-17770870
]
Daniel Sahlberg commented on SVN-1778:
--
r1824410 added support for running the internal Subversion diff functions
(svn.diff.file_diff_2 and svn.diff.file_output_unified4) as long as the
argument diffoptions is None (the default). Since diffoptions is passed as
arguments to the diff command, it seems reasonable to require the presence of
diff (or diff.exe) if one uses diffoptions.
> [python] FileDiff broken on Windows
> ---
>
> Key: SVN-1778
> URL: https://issues.apache.org/jira/browse/SVN-1778
> Project: Subversion
> Issue Type: Bug
> Components: bindings_swig_python
>Affects Versions: all
> Environment: Windows 2000
>Reporter: Subversion Importer
>Priority: Critical
> Fix For: unscheduled
>
>
> {noformat:nopanel=true}
> In function get_pipe, class FileDiff spawns a "diff" process, but usually no
> "diff.exe" executable is available under Windows, so the FileDiff class might
> be
> completely non-functional on most Win installation. Maybe using Python difflib
> calls could be a better solution.
> {noformat}
> Original issue reported by *iaanus*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4916) swig-py: Python ref-count leak on delta.editor object and repos.make_parse_fns3 object
[ https://issues.apache.org/jira/browse/SVN-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770863#comment-17770863 ] Daniel Sahlberg commented on SVN-4916: -- [https://lists.apache.org/thread/3lyb2v2h4gfk5tlnwht2hlvzrlv8klj0] [http://svn.apache.org/viewvc?rev=1912501&view=rev|http://svn.apache.org/viewvc?rev=1912515&view=rev] > swig-py: Python ref-count leak on delta.editor object and > repos.make_parse_fns3 object > -- > > Key: SVN-4916 > URL: https://issues.apache.org/jira/browse/SVN-4916 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: trunk, 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Yasuhito Futatsuki >Priority: Major > > An edit baton made by delta.make_editor / a parse_fns3 baton made by > repos.make_parse_fns3 hold a reference of editor object / parse_fns3 object > and they never release it. > > This was pointed out in the Trac Open Source Project ticket #13112[1], > #13129[2], and #13356[3]. > > [1] repository sync with large Subversion repository has memory leaks > [https://trac.edgewall.org/ticket/13112] > [2] trac-admin resync leaks memory > [https://trac.edgewall.org/ticket/13129] > [3] Subversion pool is destroyed more than once while testing > trac/versioncontrol/tests/functional.py, comment 6 > [https://trac.edgewall.org/ticket/13356#comment:6] > > I think this affects all versions after those functions were implemented, > but I didn't check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SVN-4917) swig-py: Python ref-cont leak in wrapper of *svn_delta_editor_t() and *svn_repos_parse_fns3_t()
[ https://issues.apache.org/jira/browse/SVN-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770828#comment-17770828 ] Daniel Sahlberg commented on SVN-4917: -- [https://lists.apache.org/thread/3lyb2v2h4gfk5tlnwht2hlvzrlv8klj0] [http://svn.apache.org/viewvc?rev=1912515&view=rev] > swig-py: Python ref-cont leak in wrapper of *svn_delta_editor_t() and > *svn_repos_parse_fns3_t() > > > Key: SVN-4917 > URL: https://issues.apache.org/jira/browse/SVN-4917 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: trunk, 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Yasuhito Futatsuki >Priority: Major > > Wrapper functions of C APIs which drive *svn_delta_editor_t() and > svn_repos_parse_fns3_t does not release reference of intermediate baton which > are created during processing call back of the API when an error is occured > during proccessing call back of the API. > > I think this affects all versions after those functions were implemented, > but I didn't check. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SVN-4918) swig-py: parse_fns3 driver object and parse_baton can make a circular reference which causes Python reference leak
[ https://issues.apache.org/jira/browse/SVN-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770821#comment-17770821 ] Daniel Sahlberg commented on SVN-4918: -- [https://lists.apache.org/thread/3lyb2v2h4gfk5tlnwht2hlvzrlv8klj0] [http://svn.apache.org/viewvc?rev=1912517&view=rev] > swig-py: parse_fns3 driver object and parse_baton can make a circular > reference which causes Python reference leak > -- > > Key: SVN-4918 > URL: https://issues.apache.org/jira/browse/SVN-4918 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: trunk, 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Yasuhito Futatsuki >Priority: Major > > parse_fns3 driver object and parse_baton can make a circular references > through the pool cleanup callback registration which is not visible by Python > interpreter. > > If parse_fn3 driver and parse_baton object are allocated from same pool, the > python wrapper object of the pool and its entity pool can't clean up. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SVN-4916) swig-py: Python ref-count leak on delta.editor object and repos.make_parse_fns3 object
[ https://issues.apache.org/jira/browse/SVN-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yasuhito Futatsuki updated SVN-4916: Description: An edit baton made by delta.make_editor / a parse_fns3 baton made by repos.make_parse_fns3 hold a reference of editor object / parse_fns3 object and they never release it. This was pointed out in the Trac Open Source Project ticket #13112[1], #13129[2], and #13356[3]. [1] repository sync with large Subversion repository has memory leaks [https://trac.edgewall.org/ticket/13112] [2] trac-admin resync leaks memory [https://trac.edgewall.org/ticket/13129] [3] Subversion pool is destroyed more than once while testing trac/versioncontrol/tests/functional.py, comment 6 [https://trac.edgewall.org/ticket/13356#comment:6] I think this affects all versions after those functions were implemented, but I didn't check. was: An edit baton make by delta.make_editor / a parse_fns3 baton made by repos.make_parse_fns3 hold a reference of editor object / parse_fns3 object and they never release it. This was pointed out in the Trac Open Source Project ticket #13112[1], #13129[2], and #13356[3]. [1] repository sync with large Subversion repository has memory leaks [https://trac.edgewall.org/ticket/13112] [2] trac-admin resync leaks memory [https://trac.edgewall.org/ticket/13129] [3] Subversion pool is destroyed more than once while testing trac/versioncontrol/tests/functional.py, comment 6 [https://trac.edgewall.org/ticket/13356#comment:6] I think this affects all versions after those functions were implemented, but I didn't check. > swig-py: Python ref-count leak on delta.editor object and > repos.make_parse_fns3 object > -- > > Key: SVN-4916 > URL: https://issues.apache.org/jira/browse/SVN-4916 > Project: Subversion > Issue Type: Bug > Components: bindings_swig_python >Affects Versions: trunk, 1.14.2 >Reporter: Yasuhito Futatsuki >Assignee: Yasuhito Futatsuki >Priority: Major > > An edit baton made by delta.make_editor / a parse_fns3 baton made by > repos.make_parse_fns3 hold a reference of editor object / parse_fns3 object > and they never release it. > > This was pointed out in the Trac Open Source Project ticket #13112[1], > #13129[2], and #13356[3]. > > [1] repository sync with large Subversion repository has memory leaks > [https://trac.edgewall.org/ticket/13112] > [2] trac-admin resync leaks memory > [https://trac.edgewall.org/ticket/13129] > [3] Subversion pool is destroyed more than once while testing > trac/versioncontrol/tests/functional.py, comment 6 > [https://trac.edgewall.org/ticket/13356#comment:6] > > I think this affects all versions after those functions were implemented, > but I didn't check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SVN-4918) swig-py: parse_fns3 driver object and parse_baton can make a circular reference which causes Python reference leak
Yasuhito Futatsuki created SVN-4918: --- Summary: swig-py: parse_fns3 driver object and parse_baton can make a circular reference which causes Python reference leak Key: SVN-4918 URL: https://issues.apache.org/jira/browse/SVN-4918 Project: Subversion Issue Type: Bug Components: bindings_swig_python Affects Versions: trunk, 1.14.2 Reporter: Yasuhito Futatsuki Assignee: Yasuhito Futatsuki parse_fns3 driver object and parse_baton can make a circular references through the pool cleanup callback registration which is not visible by Python interpreter. If parse_fn3 driver and parse_baton object are allocated from same pool, the python wrapper object of the pool and its entity pool can't clean up. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SVN-4917) swig-py: Python ref-cont leak in wrapper of *svn_delta_editor_t() and *svn_repos_parse_fns3_t()
Yasuhito Futatsuki created SVN-4917: --- Summary: swig-py: Python ref-cont leak in wrapper of *svn_delta_editor_t() and *svn_repos_parse_fns3_t() Key: SVN-4917 URL: https://issues.apache.org/jira/browse/SVN-4917 Project: Subversion Issue Type: Bug Components: bindings_swig_python Affects Versions: trunk, 1.14.2 Reporter: Yasuhito Futatsuki Assignee: Yasuhito Futatsuki Wrapper functions of C APIs which drive *svn_delta_editor_t() and svn_repos_parse_fns3_t does not release reference of intermediate baton which are created during processing call back of the API when an error is occured during proccessing call back of the API. I think this affects all versions after those functions were implemented, but I didn't check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SVN-4916) swig-py: Python ref-count leak on delta.editor object and repos.make_parse_fns3 object
Yasuhito Futatsuki created SVN-4916: --- Summary: swig-py: Python ref-count leak on delta.editor object and repos.make_parse_fns3 object Key: SVN-4916 URL: https://issues.apache.org/jira/browse/SVN-4916 Project: Subversion Issue Type: Bug Components: bindings_swig_python Affects Versions: trunk, 1.14.2 Reporter: Yasuhito Futatsuki Assignee: Yasuhito Futatsuki An edit baton make by delta.make_editor / a parse_fns3 baton made by repos.make_parse_fns3 hold a reference of editor object / parse_fns3 object and they never release it. This was pointed out in the Trac Open Source Project ticket #13112[1], #13129[2], and #13356[3]. [1] repository sync with large Subversion repository has memory leaks [https://trac.edgewall.org/ticket/13112] [2] trac-admin resync leaks memory [https://trac.edgewall.org/ticket/13129] [3] Subversion pool is destroyed more than once while testing trac/versioncontrol/tests/functional.py, comment 6 [https://trac.edgewall.org/ticket/13356#comment:6] I think this affects all versions after those functions were implemented, but I didn't check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SVN-2230) "make clean" doesn't clean SWIG-generated .c files
[
https://issues.apache.org/jira/browse/SVN-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17767374#comment-17767374
]
Yasuhito Futatsuki commented on SVN-2230:
-
I belive that this was already fixed.
In release mode Makefile, SWIG-generated .c files are kept intensionally as a
part of the distributed source tree, so that users can rebuild bindings
without installed SWIG program. In non-release mode Makefile, they are
removed by EXtRACLEAN_SWIG_XX macro command, called by "clean" ->
"clean-bindings" -> "clean-swig" -> "clean-swig-py", "clean-swig-rb",
"clean-pl" targets.
> "make clean" doesn't clean SWIG-generated .c files
> --
>
> Key: SVN-2230
> URL: https://issues.apache.org/jira/browse/SVN-2230
> Project: Subversion
> Issue Type: Bug
> Components: compile
>Affects Versions: ---
>Reporter: Max Oliver Bowsher
>Priority: Minor
> Fix For: unscheduled
>
>
> {noformat:nopanel=true}
> "make clean" doesn't clean SWIG-generated .c files
> ... for Python, and probably for everything but Perl, actually.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-4818) Failed to build with SWIG 4
[
https://issues.apache.org/jira/browse/SVN-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yasuhito Futatsuki closed SVN-4818.
---
Resolution: Fixed
> Failed to build with SWIG 4
> ---
>
> Key: SVN-4818
> URL: https://issues.apache.org/jira/browse/SVN-4818
> Project: Subversion
> Issue Type: Bug
> Components: bindings_swig
>Affects Versions: 1.12.0
> Environment: Arch Linux x86_64, SWIG 4.0.0.
>Reporter: Felix Yan
>Priority: Major
> Fix For: trunk, 1.14.1
>
>
> The Python binding failed to build with an error:
> {{Deprecated command line option: -classic. This option is no longer
> supported.}}
> After fixing this (by removing -classic from build.conf), a lot of new
> errors like below appeared:
> {{subversion/bindings/swig/python/svn_client.c:6201:128: error:
> ‘svn_argnum_swig_obj’ undeclared (first use in this function); did you mean
> ‘svn_argnum_obj1’?}}
> After looking up the changelog of SWIG 4, it appears fastunpack becomes
> default so I added {{-nofastunpack}} to get around this.
> Next error is inside Ruby bindings:
> {{subversion/bindings/swig/ruby/svn_client.c:1605:21: error:
> ‘SWIG_POINTER_NO_NULL’ undeclared (first use in this function); did you mean
> ‘SWIG_POINTER_OWN’?}}
> Looks like the vendored proxy/*.swg files are outdated. I removed some and
> get passed this one.
> Finally it built fine, but I am stuck at the test suite now. The python
> binding failed to import correctly:
> {{File
> "/home/felix/projects/arch/packages/subversion/trunk/src/subversion-1.12.0/subversion/bindings/swig/python/libsvn/core.py",
> line 32, in _swig_setattr_nondynamic}}
> {{method = class_type.__swig_setmethods__.get(name, None)}}
> {{AttributeError: type object 'svn_auth_cred_simple_t' has no attribute
> '__swig_setmethods__'}}
> Please let me know how to proceed, thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4818) Failed to build with SWIG 4
[
https://issues.apache.org/jira/browse/SVN-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17767312#comment-17767312
]
Yasuhito Futatsuki commented on SVN-4818:
-
Because of the reason I described above, we decided that we don't support
building Python 2 bindings with SWIG 4 (won't fix).
For Python 3, the issue was fixed in r1869853 (between 1.13.0 and 1.14.0) for
Unix/Linux and in r177338 (on trunk), r188482 (on 1.14.x branch between 1.14.0
and 1.14.1) for Windows.
> Next error is inside Ruby bindings:
{{> subversion/bindings/swig/ruby/svn_client.c:1605:21: error:
>‘SWIG_POINTER_NO_NULL’ undeclared (first use in this function); did you mean
‘SWIG_POINTER_OWN’?}}
> Looks like the vendored proxy/*.swg files are outdated. I removed some and
> get passed this one.
It was needed to do "make clean-swig" after autogen.sh and configure, before
building swig bindings.
We added an optional step "Clean Old Bindings Intermediate Source Files" as
below, in the install instruction described in subversion/bindings/swig/INSTALL
file.
"Step 2.5 [Optional] Clean Old Bindings Intermediate Source Files
If you are rebuilding bindings with different version of SWIG from
previously used, run 'make clean-swig'. This will clean SWIG version
depended intermediate source files. This step also needs if you are
using the Subversion distribution tarball and using autogen.sh to
rebuild configure script, because you might use different version of
SWIG from one we used to make the tarball."
> Failed to build with SWIG 4
> ---
>
> Key: SVN-4818
> URL: https://issues.apache.org/jira/browse/SVN-4818
> Project: Subversion
> Issue Type: Bug
> Components: bindings_swig
>Affects Versions: 1.12.0
> Environment: Arch Linux x86_64, SWIG 4.0.0.
>Reporter: Felix Yan
>Priority: Major
> Fix For: trunk, 1.14.1
>
>
> The Python binding failed to build with an error:
> {{Deprecated command line option: -classic. This option is no longer
> supported.}}
> After fixing this (by removing -classic from build.conf), a lot of new
> errors like below appeared:
> {{subversion/bindings/swig/python/svn_client.c:6201:128: error:
> ‘svn_argnum_swig_obj’ undeclared (first use in this function); did you mean
> ‘svn_argnum_obj1’?}}
> After looking up the changelog of SWIG 4, it appears fastunpack becomes
> default so I added {{-nofastunpack}} to get around this.
> Next error is inside Ruby bindings:
> {{subversion/bindings/swig/ruby/svn_client.c:1605:21: error:
> ‘SWIG_POINTER_NO_NULL’ undeclared (first use in this function); did you mean
> ‘SWIG_POINTER_OWN’?}}
> Looks like the vendored proxy/*.swg files are outdated. I removed some and
> get passed this one.
> Finally it built fine, but I am stuck at the test suite now. The python
> binding failed to import correctly:
> {{File
> "/home/felix/projects/arch/packages/subversion/trunk/src/subversion-1.12.0/subversion/bindings/swig/python/libsvn/core.py",
> line 32, in _swig_setattr_nondynamic}}
> {{method = class_type.__swig_setmethods__.get(name, None)}}
> {{AttributeError: type object 'svn_auth_cred_simple_t' has no attribute
> '__swig_setmethods__'}}
> Please let me know how to proceed, thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SVN-4818) Failed to build with SWIG 4
[
https://issues.apache.org/jira/browse/SVN-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yasuhito Futatsuki updated SVN-4818:
Fix Version/s: trunk
1.14.1
> Failed to build with SWIG 4
> ---
>
> Key: SVN-4818
> URL: https://issues.apache.org/jira/browse/SVN-4818
> Project: Subversion
> Issue Type: Bug
> Components: bindings_swig
>Affects Versions: 1.12.0
> Environment: Arch Linux x86_64, SWIG 4.0.0.
>Reporter: Felix Yan
>Priority: Major
> Fix For: trunk, 1.14.1
>
>
> The Python binding failed to build with an error:
> {{Deprecated command line option: -classic. This option is no longer
> supported.}}
> After fixing this (by removing -classic from build.conf), a lot of new
> errors like below appeared:
> {{subversion/bindings/swig/python/svn_client.c:6201:128: error:
> ‘svn_argnum_swig_obj’ undeclared (first use in this function); did you mean
> ‘svn_argnum_obj1’?}}
> After looking up the changelog of SWIG 4, it appears fastunpack becomes
> default so I added {{-nofastunpack}} to get around this.
> Next error is inside Ruby bindings:
> {{subversion/bindings/swig/ruby/svn_client.c:1605:21: error:
> ‘SWIG_POINTER_NO_NULL’ undeclared (first use in this function); did you mean
> ‘SWIG_POINTER_OWN’?}}
> Looks like the vendored proxy/*.swg files are outdated. I removed some and
> get passed this one.
> Finally it built fine, but I am stuck at the test suite now. The python
> binding failed to import correctly:
> {{File
> "/home/felix/projects/arch/packages/subversion/trunk/src/subversion-1.12.0/subversion/bindings/swig/python/libsvn/core.py",
> line 32, in _swig_setattr_nondynamic}}
> {{method = class_type.__swig_setmethods__.get(name, None)}}
> {{AttributeError: type object 'svn_auth_cred_simple_t' has no attribute
> '__swig_setmethods__'}}
> Please let me know how to proceed, thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-4811) Test failures with Python 3
[
https://issues.apache.org/jira/browse/SVN-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yasuhito Futatsuki closed SVN-4811.
---
> Test failures with Python 3
> ---
>
> Key: SVN-4811
> URL: https://issues.apache.org/jira/browse/SVN-4811
> Project: Subversion
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.11.0
>Reporter: Marius
>Priority: Minor
> Labels: test
> Fix For: 1.14.0
>
>
> Running the test suite with Python 3 causes failures in {{svnadmin_tests.py
> 69}} and {{tree_conflict_tests.py 26}} (both new in 1.11):
> {noformat}
> W: CWD:
> /tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline
> Traceback (most recent call last):
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/main.py",
> line 1894, in run
> rc = self.pred.run(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/testcase.py",
> line 178, in run
> result = self.func(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svnadmin_tests.py",
> line 3861, in dump_no_canonicalize_svndate
> assert propval + '\n' in dump_lines
> AssertionError
> FAIL: svnadmin_tests.py 69: svnadmin dump shouldn't canonicalize svn:date
> {noformat}
> {noformat}
> W: A1/B/lambda has unexpectected contents
> W: EXPECTED svn-test-work/working_copies/tree_conflict_tests-26/A1/B/lambda
> (match_all=True):
> W: | This is the file 'lambda'.
> W: | This is more content.
> W: ACTUAL svn-test-work/working_copies/tree_conflict_tests-26/A1/B/lambda:
> W: CWD:
> /tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline
> Traceback (most recent call last):
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/main.py",
> line 1894, in run
>
> rc = self.pred.run(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/testcase.py",
> line 178, in run
>
> result = self.func(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/tree_conflict_tests.py",
> line 1547, in local_missing_dir_endless_loop
>
> [ "This is the file 'lambda'.\n", "This is more content.\n"], contents)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/verify.py",
> line 503, in compare_and_display_lines
>
> expected.display_differences(message, label, actual)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/verify.py",
> line 154, in display_differences
> display_lines(message, self.expected, actual, e_label, label)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/verify.py",
> line 478, in display_lines
> logger.warn('| ' + x.rstrip())
> TypeError: can only concatenate str (not "bytes") to str
> FAIL: tree_conflict_tests.py 26: endless loop when resolving local-missing
> dir
> END: tree_conflict_tests.py
> ELAPSED: tree_conflict_tests.py 0:01:17.563191
> {noformat}
> Is it safe to ignore these failures, or should users stick with Python 2 for
> now?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SVN-4811) Test failures with Python 3
[
https://issues.apache.org/jira/browse/SVN-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yasuhito Futatsuki resolved SVN-4811.
-
Resolution: Fixed
> Test failures with Python 3
> ---
>
> Key: SVN-4811
> URL: https://issues.apache.org/jira/browse/SVN-4811
> Project: Subversion
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.11.0
>Reporter: Marius
>Priority: Minor
> Labels: test
> Fix For: 1.14.0
>
>
> Running the test suite with Python 3 causes failures in {{svnadmin_tests.py
> 69}} and {{tree_conflict_tests.py 26}} (both new in 1.11):
> {noformat}
> W: CWD:
> /tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline
> Traceback (most recent call last):
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/main.py",
> line 1894, in run
> rc = self.pred.run(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/testcase.py",
> line 178, in run
> result = self.func(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svnadmin_tests.py",
> line 3861, in dump_no_canonicalize_svndate
> assert propval + '\n' in dump_lines
> AssertionError
> FAIL: svnadmin_tests.py 69: svnadmin dump shouldn't canonicalize svn:date
> {noformat}
> {noformat}
> W: A1/B/lambda has unexpectected contents
> W: EXPECTED svn-test-work/working_copies/tree_conflict_tests-26/A1/B/lambda
> (match_all=True):
> W: | This is the file 'lambda'.
> W: | This is more content.
> W: ACTUAL svn-test-work/working_copies/tree_conflict_tests-26/A1/B/lambda:
> W: CWD:
> /tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline
> Traceback (most recent call last):
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/main.py",
> line 1894, in run
>
> rc = self.pred.run(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/testcase.py",
> line 178, in run
>
> result = self.func(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/tree_conflict_tests.py",
> line 1547, in local_missing_dir_endless_loop
>
> [ "This is the file 'lambda'.\n", "This is more content.\n"], contents)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/verify.py",
> line 503, in compare_and_display_lines
>
> expected.display_differences(message, label, actual)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/verify.py",
> line 154, in display_differences
> display_lines(message, self.expected, actual, e_label, label)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/verify.py",
> line 478, in display_lines
> logger.warn('| ' + x.rstrip())
> TypeError: can only concatenate str (not "bytes") to str
> FAIL: tree_conflict_tests.py 26: endless loop when resolving local-missing
> dir
> END: tree_conflict_tests.py
> ELAPSED: tree_conflict_tests.py 0:01:17.563191
> {noformat}
> Is it safe to ignore these failures, or should users stick with Python 2 for
> now?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4811) Test failures with Python 3
[
https://issues.apache.org/jira/browse/SVN-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17767281#comment-17767281
]
Yasuhito Futatsuki commented on SVN-4811:
-
This was fixed on r1868575.
> Test failures with Python 3
> ---
>
> Key: SVN-4811
> URL: https://issues.apache.org/jira/browse/SVN-4811
> Project: Subversion
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.11.0
>Reporter: Marius
>Priority: Minor
> Labels: test
> Fix For: 1.14.0
>
>
> Running the test suite with Python 3 causes failures in {{svnadmin_tests.py
> 69}} and {{tree_conflict_tests.py 26}} (both new in 1.11):
> {noformat}
> W: CWD:
> /tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline
> Traceback (most recent call last):
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/main.py",
> line 1894, in run
> rc = self.pred.run(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/testcase.py",
> line 178, in run
> result = self.func(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svnadmin_tests.py",
> line 3861, in dump_no_canonicalize_svndate
> assert propval + '\n' in dump_lines
> AssertionError
> FAIL: svnadmin_tests.py 69: svnadmin dump shouldn't canonicalize svn:date
> {noformat}
> {noformat}
> W: A1/B/lambda has unexpectected contents
> W: EXPECTED svn-test-work/working_copies/tree_conflict_tests-26/A1/B/lambda
> (match_all=True):
> W: | This is the file 'lambda'.
> W: | This is more content.
> W: ACTUAL svn-test-work/working_copies/tree_conflict_tests-26/A1/B/lambda:
> W: CWD:
> /tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline
> Traceback (most recent call last):
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/main.py",
> line 1894, in run
>
> rc = self.pred.run(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/testcase.py",
> line 178, in run
>
> result = self.func(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/tree_conflict_tests.py",
> line 1547, in local_missing_dir_endless_loop
>
> [ "This is the file 'lambda'.\n", "This is more content.\n"], contents)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/verify.py",
> line 503, in compare_and_display_lines
>
> expected.display_differences(message, label, actual)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/verify.py",
> line 154, in display_differences
> display_lines(message, self.expected, actual, e_label, label)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/verify.py",
> line 478, in display_lines
> logger.warn('| ' + x.rstrip())
> TypeError: can only concatenate str (not "bytes") to str
> FAIL: tree_conflict_tests.py 26: endless loop when resolving local-missing
> dir
> END: tree_conflict_tests.py
> ELAPSED: tree_conflict_tests.py 0:01:17.563191
> {noformat}
> Is it safe to ignore these failures, or should users stick with Python 2 for
> now?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SVN-4811) Test failures with Python 3
[
https://issues.apache.org/jira/browse/SVN-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yasuhito Futatsuki updated SVN-4811:
Fix Version/s: 1.14.0
> Test failures with Python 3
> ---
>
> Key: SVN-4811
> URL: https://issues.apache.org/jira/browse/SVN-4811
> Project: Subversion
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.11.0
>Reporter: Marius
>Priority: Minor
> Labels: test
> Fix For: 1.14.0
>
>
> Running the test suite with Python 3 causes failures in {{svnadmin_tests.py
> 69}} and {{tree_conflict_tests.py 26}} (both new in 1.11):
> {noformat}
> W: CWD:
> /tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline
> Traceback (most recent call last):
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/main.py",
> line 1894, in run
> rc = self.pred.run(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/testcase.py",
> line 178, in run
> result = self.func(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svnadmin_tests.py",
> line 3861, in dump_no_canonicalize_svndate
> assert propval + '\n' in dump_lines
> AssertionError
> FAIL: svnadmin_tests.py 69: svnadmin dump shouldn't canonicalize svn:date
> {noformat}
> {noformat}
> W: A1/B/lambda has unexpectected contents
> W: EXPECTED svn-test-work/working_copies/tree_conflict_tests-26/A1/B/lambda
> (match_all=True):
> W: | This is the file 'lambda'.
> W: | This is more content.
> W: ACTUAL svn-test-work/working_copies/tree_conflict_tests-26/A1/B/lambda:
> W: CWD:
> /tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline
> Traceback (most recent call last):
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/main.py",
> line 1894, in run
>
> rc = self.pred.run(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/testcase.py",
> line 178, in run
>
> result = self.func(sandbox)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/tree_conflict_tests.py",
> line 1547, in local_missing_dir_endless_loop
>
> [ "This is the file 'lambda'.\n", "This is more content.\n"], contents)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/verify.py",
> line 503, in compare_and_display_lines
>
> expected.display_differences(message, label, actual)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/verify.py",
> line 154, in display_differences
> display_lines(message, self.expected, actual, e_label, label)
> File
> "/tmp/guix-build-subversion-1.11.1.drv-0/subversion-1.11.1/subversion/tests/cmdline/svntest/verify.py",
> line 478, in display_lines
> logger.warn('| ' + x.rstrip())
> TypeError: can only concatenate str (not "bytes") to str
> FAIL: tree_conflict_tests.py 26: endless loop when resolving local-missing
> dir
> END: tree_conflict_tests.py
> ELAPSED: tree_conflict_tests.py 0:01:17.563191
> {noformat}
> Is it safe to ignore these failures, or should users stick with Python 2 for
> now?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SVN-4909) Merged Information is missing xml option
[ https://issues.apache.org/jira/browse/SVN-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Michael Pilato updated SVN-4909: --- Description: svn log --xml -g -v is not providing merge information. We wanted to track history and take all files along with author, revisions and details of changes. Hence we run the xml version of svn log to see the details including merged ones. We understand for every merge normally merged via is populated but in XML Version it is missing was: svn log --xml -g -v is not providing merge infor. We wanted to track history and take all files along with author, revisions and details of changes. Hence we run the xml version of svn log to see the details including merged ones. We understand for every merge normally merged via is populated but in XML Version it is missing > Merged Information is missing xml option > > > Key: SVN-4909 > URL: https://issues.apache.org/jira/browse/SVN-4909 > Project: Subversion > Issue Type: Bug >Affects Versions: 1.13.0 > Environment: svn log --xml -g -v is not providing merge > infor. > > We wanted to track history and take all files along with author, revisions > and details of changes. Hence we run the xml version of svn log to see the > details including merged ones. > > We understand for every merge normally merged via is populated but in XML > Version it is missing >Reporter: prajeesh Kozhisseri >Priority: Blocker > > svn log --xml -g -v is not providing merge information. > We wanted to track history and take all files along with author, revisions > and details of changes. Hence we run the xml version of svn log to see the > details including merged ones. > We understand for every merge normally merged via is populated but in XML > Version it is missing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SVN-4909) Merge information is missing when --xml option used with svn log
[ https://issues.apache.org/jira/browse/SVN-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Michael Pilato updated SVN-4909: --- Summary: Merge information is missing when --xml option used with svn log (was: Merged Information is missing xml option) > Merge information is missing when --xml option used with svn log > > > Key: SVN-4909 > URL: https://issues.apache.org/jira/browse/SVN-4909 > Project: Subversion > Issue Type: Bug >Affects Versions: 1.13.0 > Environment: svn log --xml -g -v is not providing merge > infor. > > We wanted to track history and take all files along with author, revisions > and details of changes. Hence we run the xml version of svn log to see the > details including merged ones. > > We understand for every merge normally merged via is populated but in XML > Version it is missing >Reporter: prajeesh Kozhisseri >Priority: Blocker > > svn log --xml -g -v is not providing merge information. > We wanted to track history and take all files along with author, revisions > and details of changes. Hence we run the xml version of svn log to see the > details including merged ones. > We understand for every merge normally merged via is populated but in XML > Version it is missing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SVN-4145) Master passphrase and encrypted credentials cache
[
https://issues.apache.org/jira/browse/SVN-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Michael Pilato updated SVN-4145:
---
Fix Version/s: unscheduled
(was: 1.10-consider)
> Master passphrase and encrypted credentials cache
> -
>
> Key: SVN-4145
> URL: https://issues.apache.org/jira/browse/SVN-4145
> Project: Subversion
> Issue Type: New Feature
> Components: libsvn_subr
>Affects Versions: 1.7.x
>Reporter: C. Michael Pilato
>Priority: Critical
> Fix For: unscheduled
>
>
> {noformat:nopanel=true}
> Like all popular web browsers, Mozilla Firefox allows you to optionally cache
> passwords used for site logins. Site credentials are cached on disk, and in
> plaintext by default. However, Firefox allows you to optionally configure a
> "Master Password". This password (or passphrase) is used to encrypt the
> on-disk
> cached site credentials, functioning effectively the same way that a keyring
> provider and associated passphrase would work. Firefox will challenge the user
> for the master password the first time it needs to consult its credentials
> cache, and will leave the cache "unlocked" for the duration of the
> application's
> lifetime.
> Subversion should be able to do something similar, allowing users to
> optionally
> employ a master passphrase which is used to encrypt and decrypt other
> sensitive
> information stored in its authentication credential cache(s).
> See http://wiki.apache.org/subversion/MasterPassphrase for design thoughts.
> {noformat}
> http://wiki.apache.org/subversion/MasterPassphrase
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-3945) RPM packaging tools need complete replacement
[
https://issues.apache.org/jira/browse/SVN-3945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg closed SVN-3945.
Resolution: Abandoned
/packages was removed in r1442167 in 2013
> RPM packaging tools need complete replacement
> -
>
> Key: SVN-3945
> URL: https://issues.apache.org/jira/browse/SVN-3945
> Project: Subversion
> Issue Type: Bug
> Components: packaging
>Affects Versions: all
> Environment: Linux
>Reporter: Subversion Importer
>Priority: Major
> Fix For: unscheduled
>
>
> {noformat:nopanel=true}
> The RPM packaging comonents in trunk/packages/rpm are out of date,
> unusable, and likely to destroy a developer's build environment. They
> should either be completely disabled or seriously updated. There are a
> couple of different issues, which I'll describe in order:
> * All the Makefiles replace the users's $HOME/.rpmmacros without
> warning. This is devastating to a user who has GPG signature
> configurations there, or who does their RPM compilation in a non
> $HOME/rpm location, or who follows RHEL standard uppercase naming of
> the SRPMS, SPEC, RPMS, and BUILD subdirectories, because the published
> ".rpmmacros" file follows a non-standard lowercase layout.
> Instead of relying on a hard-coded .rpmmacros, the Makefiles should
> use "rpm --showrc" command to derive the topdir, sourcedir, etc.
> * The .rpmmacros file ignores the "BUILDROOT" setting common to modern
> RPM building environments.
> * The .rpmmacros file should be renamed. It should be "rpmmacros.in",
> so it's presence is apparent to the developer, and to show that it is
> *not* in fact, the actual file installed.
> * The .spec files should be renamed to "subversion.spec.in". These
> are not the .spec files and should not appear as such in Subversion
> source code tarballs, they are source files for building .spec files.
> * Modern subversion cannot be compiled on rhel-3, and that packaging
> should be discarded.
> * Modern subversion cannot be compiled on rhel-4, and that packaging
> should be discarded.
> * Modern subversion can be built on rhel-5, rhel-6, fedora, etc. Those
> packages can be published as *one* set using the RPMforge packages.
> (I'm an old contributor to those.) There are some issues with this,
> particularly its inclusion of the "swig-3.4.0.tar.gz" tarball for RHEL
> 4 compilation which doesn't even work anymore, but it's a better
> starting base for this packaging.
> I'm happy to submit these as distinct issues for the issue tracker,
> but in the short therm, pulling out the unusable rhel-3 and rhel-4
> packaging would be a good start.
> {noformat}
> Original issue reported by *nkadelgarcia*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-2483) svncopy.pl: Delete temp directory
[
https://issues.apache.org/jira/browse/SVN-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg closed SVN-2483.
Resolution: Won't Fix
Script is deprecated since r1659395.
> svncopy.pl: Delete temp directory
> -
>
> Key: SVN-2483
> URL: https://issues.apache.org/jira/browse/SVN-2483
> Project: Subversion
> Issue Type: Bug
> Components: tools
>Affects Versions: ---
>Reporter: Subversion Importer
>Priority: Major
> Labels: patch
> Fix For: 1.10-consider
>
>
> {noformat:nopanel=true}
> Patch by Robert Reeves . This patch fixes
> svncopy.pl so it deletes a temporary directory it created. There were no
> responses to the patch on the dev list.
> I've filed the issue under the "tools" subcomponent, although svncopy.pl is
> located under the contrib directory.
> The original message is archived here (with patch attached as
> binary/octet-stream):
> http://svn.haxx.se/dev/archive-2005-12/0532.shtml
> I attached the patch as text/plain and reposted it here:
> http://svn.haxx.se/dev/archive-2006-01/0387.shtml
> {noformat}
> http://svn.haxx.se/dev/archive-2006-01/0387.shtml
> Original issue reported by *mthelen*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4621) svn_load_dirs.pl fails when updating binary files due to changed behavior of svn propget
[
https://issues.apache.org/jira/browse/SVN-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17760126#comment-17760126
]
Daniel Sahlberg commented on SVN-4621:
--
Committed r1912002, thanks!
> svn_load_dirs.pl fails when updating binary files due to changed behavior of
> svn propget
>
>
> Key: SVN-4621
> URL: https://issues.apache.org/jira/browse/SVN-4621
> Project: Subversion
> Issue Type: Bug
> Components: cmdline client, tools
>Affects Versions: 1.9.3
> Environment: Commandline Client from TortoiseSVN Windows Client
> Distribution
> svn --version --> svn, version 1.9.3 (r1718519) compiled Dec 13 2015,
> 15:47:16 on x86-microsoft-windows
> TortoiseSVN 1.9.3, Build 27038 - 64 Bit , 2015/12/13 11:53:16
>Reporter: Holger Delfs
>Priority: Major
> Attachments: svn_load_dirs.patch
>
>
> When svn_load_dirs.pl encounters an update on a binary file having no
> svn:eol-style property (e.g. an Excel file), it fails with the following
> error output:
> {noformat}
> ...
> Running svn propget svn:eol-style vorlagen/Vorlage_BerichtAKL.xlsm@BASE
> svn: warning: W200017: Property 'svn:eol-style' not found on
> 'vorlagen/Vorlage_BerichtAKL.xlsm@BASE'
> svn: E20: A problem occurred; see other errors for details
> svn_load_dirs.pl: svn propget svn:eol-style
> vorlagen/Vorlage_BerichtAKL.xlsm@BASE failed with this output:
> {noformat}
> The cause of this error seems to be the changed behavior of the svn propget
> command for a non-existent property, as discussed in SVN-4505. While the
> svn_load_dirs.pl script expects an empty output in this case (which was the
> behavior up to Subversion 1.8), the new error message from svn propget
> introduced with Subversion 1.9 causes the whole script to abort.
> svn_load_dirs.pl should be modified to either handle the error message or to
> first check the existence of the svn:eol-style property with svn proplist.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-4621) svn_load_dirs.pl fails when updating binary files due to changed behavior of svn propget
[
https://issues.apache.org/jira/browse/SVN-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg closed SVN-4621.
Fix Version/s: 1.15.0
Resolution: Fixed
> svn_load_dirs.pl fails when updating binary files due to changed behavior of
> svn propget
>
>
> Key: SVN-4621
> URL: https://issues.apache.org/jira/browse/SVN-4621
> Project: Subversion
> Issue Type: Bug
> Components: cmdline client, tools
>Affects Versions: 1.9.3
> Environment: Commandline Client from TortoiseSVN Windows Client
> Distribution
> svn --version --> svn, version 1.9.3 (r1718519) compiled Dec 13 2015,
> 15:47:16 on x86-microsoft-windows
> TortoiseSVN 1.9.3, Build 27038 - 64 Bit , 2015/12/13 11:53:16
>Reporter: Holger Delfs
>Priority: Major
> Fix For: 1.15.0
>
> Attachments: svn_load_dirs.patch
>
>
> When svn_load_dirs.pl encounters an update on a binary file having no
> svn:eol-style property (e.g. an Excel file), it fails with the following
> error output:
> {noformat}
> ...
> Running svn propget svn:eol-style vorlagen/Vorlage_BerichtAKL.xlsm@BASE
> svn: warning: W200017: Property 'svn:eol-style' not found on
> 'vorlagen/Vorlage_BerichtAKL.xlsm@BASE'
> svn: E20: A problem occurred; see other errors for details
> svn_load_dirs.pl: svn propget svn:eol-style
> vorlagen/Vorlage_BerichtAKL.xlsm@BASE failed with this output:
> {noformat}
> The cause of this error seems to be the changed behavior of the svn propget
> command for a non-existent property, as discussed in SVN-4505. While the
> svn_load_dirs.pl script expects an empty output in this case (which was the
> behavior up to Subversion 1.8), the new error message from svn propget
> introduced with Subversion 1.9 causes the whole script to abort.
> svn_load_dirs.pl should be modified to either handle the error message or to
> first check the existence of the svn:eol-style property with svn proplist.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-3630) Rename tracking
[
https://issues.apache.org/jira/browse/SVN-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17741224#comment-17741224
]
Ken commented on SVN-3630:
--
When dealing with source code, files are small enough that the current system
can work.
That is not the case for projects dealing with large, binary files.
"Rename/move" operations are a _major issue_ when large files are involved.
Doing a "{color:#172b4d}rename/move"{color} and "commit" is easy enough for the
user applying it. The change is immediate and consumes a trivial amount of
bandwidth. However, every user that subsequently updates is forced to download
excessive amounts of redundant data.
Renaming a 1GB file means every other user has to download that file, even if
they already have it.
If a folder containing 50 of those files is moved or renamed, every client
needs to download 50GB of data. That also means a lot of unnecessary writes to
the drive, especially when we consider pristines.
It would be a massive improvement for Subversion to handle "rename/move"
operations in a more client-friendly fashion. Even if the solution is efficient
only in clear-cut cases (triggering a conflict in other cases), it would help.
> Rename tracking
> ---
>
> Key: SVN-3630
> URL: https://issues.apache.org/jira/browse/SVN-3630
> Project: Subversion
> Issue Type: Bug
>Affects Versions: trunk
>Reporter: C. Michael Pilato
>Priority: Critical
> Fix For: 1.10-consider
>
>
> The history of Subversion is littered with intense conversations about the
> concept of "renames" or "moves". Modeled today as a copy of an object to a
> new
> location followed by a deletion of the same object, renames in Subversion
> behave
> in ways subtly different from how folks knowledgeable about filesystem designs
> and implementations would expect. Issue #SVN-898 tracks this disparity and
> its
> prescribed remedy.
> But for years I've been unconvinced that "true renames" are required for
> correct
> day-to-day operation of Subversion. To date, I've not seen convincing
> evidence
> that there is an inherent problem with the copy+delete model. Why then, is
> Subversion's handling of rename operations the source of so much complaint and
> frustration? Because it is very, very incomplete.
> The copy+delete concept is applied on the client side: 'svn move' is almost
> exactly just 'svn copy' and then 'svn delete'. So far so good. Except when
> it's not. Because the minute that the move operation completes, Subversion
> has
> forgotten a critical piece of information: that the copy and the delete are
> two
> parts of a higher conceptual operation that's valuable to recognize. Because
> the working copy stores nothing to tie the copy and delete together, you are
> free to act independently on each of those operations, committing only one of
> them instead of both, or reverting one of them, etc. Even when you commit
> both
> sides of a renamed object, there is no information transmitted to the server
> to
> tell it that the copy and delete are conceptually tied together. Therefore
> there's no data stored in the repository to that effect. Therefore, when
> clients are pulling information out of the repository (updates, log history,
> merges, etc.) there is no data transmitted to the clients to that effect. The
> special connectedness of the operations is forgotten immediately, to the
> detriment of Subversion's ability to help its users do what they often need to
> do with renamed objects. The results today include excessive tree conflicts,
> excessive data transferred across the wire, and excessive user confusion and
> frustration.
> This issue exists as an umbrella issue to track remedies to the user-visible
> problems of Subversion's rename-forgetfulness, independent of the more
> theoretical "true rename" issue #SVN-898 suggestions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SVN-4915) Ruby bindings contain type error in NIL_P usage
Florian Weimer created SVN-4915:
---
Summary: Ruby bindings contain type error in NIL_P usage
Key: SVN-4915
URL: https://issues.apache.org/jira/browse/SVN-4915
Project: Subversion
Issue Type: Bug
Components: bindings_swig_ruby
Affects Versions: 1.14.2
Reporter: Florian Weimer
Attachments: subversion-ruby-c99.patch
The Ruby bindings apply the Ruby {{NIL_P}} macro to an {{apr_hash_t *}} value,
which some compilers flag as a type error. We see this while building the
bindings against Ruby 3.2 with a compiler that roughly behaves like
{{-Werror=int-conversion}} (no implicit conversions between integers and
pointers).
The attached patch should fix this issue.
Related to:
* [https://fedoraproject.org/wiki/Changes/PortingToModernC]
* [https://fedoraproject.org/wiki/Toolchain/PortingToModernC]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SVN-4914) svn client crashes with assert instead of reporting an error
Sebb created SVN-4914: - Summary: svn client crashes with assert instead of reporting an error Key: SVN-4914 URL: https://issues.apache.org/jira/browse/SVN-4914 Project: Subversion Issue Type: Bug Components: svn++ Affects Versions: 1.13.0 Environment: svn, version 1.13.0 (r1867053) compiled May 12 2022, 20:47:08 on x86_64-pc-linux-gnu Reporter: Sebb I've seen some crashes in SVN where the target does not have the expected type. For example: $ svn info https://www.apache.org/foundation/records/990-2016.pdf svn: E235000: In file '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c' line 96: assertion failed (svn_uri__is_ancestor(pathrev->repos_root_url, url)) Aborted (core dumped) $ svn pl -v https://dist.apache.org/repos/dist/dev/whimsy/test.txt Properties on 'https://dist.apache.org/repos/dist/dev/whimsy/test.txt': svn:eol-style native $ svn ps svn:mime-type text/plain https://dist.apache.org/repos/dist/dev/whimsy/test.txt svn: E235000: In file '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_subr/dirent_uri.c' line 1634: assertion failed (! svn_path_is_url(relative)) Aborted (core dumped) $ svn --version svn, version 1.13.0 (r1867053) compiled May 12 2022, 20:47:08 on x86_64-pc-linux-gnu Whilst these are invalid usages, I don't believe they should crash with an assertion. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SVN-3714) Tab completion does not expand ~username directory
[
https://issues.apache.org/jira/browse/SVN-3714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg resolved SVN-3714.
--
Resolution: Fixed
> Tab completion does not expand ~username directory
> --
>
> Key: SVN-3714
> URL: https://issues.apache.org/jira/browse/SVN-3714
> Project: Subversion
> Issue Type: Bug
> Components: tools
>Affects Versions: 1.6.x, 1.14.1
> Environment: Linux
>Reporter: Subversion Importer
>Assignee: Daniel Sahlberg
>Priority: Major
> Fix For: 1.15
>
> Attachments: 3714_patch.txt
>
>
> {noformat:nopanel=true}
> When I type:
> svn up ~user[TAB]
> completion does not work, I've to manually type ~user and also a '/' to the
> end
> of the directory to make it work. Then, it starts to complete directory names.
> With completion scripts from other programs like git, mplayer I can use ~user
> shortcut for completion easily without having to write full username and the
> '/'
> to the end.
> By the way I'm using 1.2 tarball of this completion project[1] with bash
> 4.1.7.
> [1] http://bash-completion.alioth.debian.org/
> {noformat}
> Original issue reported by *gokcene*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SVN-4913) Assert on svn move [URL] [URL]/subdir
[
https://issues.apache.org/jira/browse/SVN-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg resolved SVN-4913.
--
Resolution: Fixed
r1909127
> Assert on svn move [URL] [URL]/subdir
> -
>
> Key: SVN-4913
> URL: https://issues.apache.org/jira/browse/SVN-4913
> Project: Subversion
> Issue Type: Task
>Affects Versions: 1.14.0
>Reporter: Pavel Lyalyakin
>Assignee: Daniel Sahlberg
>Priority: Minor
> Attachments: move_to_subdir.patch, testcase.patch
>
>
> As reported on dev@:
> [https://lists.apache.org/thread/s4byt3p2tot453smhhdlh0fhygy2bhb9]
> The SVN client crashes when I run the following command:
> {{$ svn move [https://svn1.mydomain.com/svn/MyRepo]/
> [https://svn1.mydomain.com/svn/MyRepo/trunk] -m "Test Commit"}}
> {{{}svn: E235000: In file '..\..\..\subversion\libsvn_client\copy.c' line
> 1187: assertion failed (! svn_path_is_empty(path)){}}}}}{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4913) Assert on svn move [URL] [URL]/subdir
[
https://issues.apache.org/jira/browse/SVN-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712083#comment-17712083
]
Daniel Sahlberg commented on SVN-4913:
--
Committed (slightly revised) as r1909127.
> Assert on svn move [URL] [URL]/subdir
> -
>
> Key: SVN-4913
> URL: https://issues.apache.org/jira/browse/SVN-4913
> Project: Subversion
> Issue Type: Task
>Affects Versions: 1.14.0
>Reporter: Pavel Lyalyakin
>Assignee: Daniel Sahlberg
>Priority: Minor
> Attachments: move_to_subdir.patch, testcase.patch
>
>
> As reported on dev@:
> [https://lists.apache.org/thread/s4byt3p2tot453smhhdlh0fhygy2bhb9]
> The SVN client crashes when I run the following command:
> {{$ svn move [https://svn1.mydomain.com/svn/MyRepo]/
> [https://svn1.mydomain.com/svn/MyRepo/trunk] -m "Test Commit"}}
> {{{}svn: E235000: In file '..\..\..\subversion\libsvn_client\copy.c' line
> 1187: assertion failed (! svn_path_is_empty(path)){}}}}}{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SVN-4913) Assert on svn move [URL] [URL]/subdir
[
https://issues.apache.org/jira/browse/SVN-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg updated SVN-4913:
-
Reporter: Pavel Lyalyakin (was: Daniel Sahlberg)
> Assert on svn move [URL] [URL]/subdir
> -
>
> Key: SVN-4913
> URL: https://issues.apache.org/jira/browse/SVN-4913
> Project: Subversion
> Issue Type: Task
>Affects Versions: 1.14.0
>Reporter: Pavel Lyalyakin
>Assignee: Daniel Sahlberg
>Priority: Minor
> Attachments: move_to_subdir.patch, testcase.patch
>
>
> As reported on dev@:
> [https://lists.apache.org/thread/s4byt3p2tot453smhhdlh0fhygy2bhb9]
> The SVN client crashes when I run the following command:
> {{$ svn move [https://svn1.mydomain.com/svn/MyRepo]/
> [https://svn1.mydomain.com/svn/MyRepo/trunk] -m "Test Commit"}}
> {{{}svn: E235000: In file '..\..\..\subversion\libsvn_client\copy.c' line
> 1187: assertion failed (! svn_path_is_empty(path)){}}}}}{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4913) Assert on svn move [URL] [URL]/subdir
[
https://issues.apache.org/jira/browse/SVN-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709916#comment-17709916
]
Daniel Sahlberg commented on SVN-4913:
--
Attached testcase covers the new proposed behaviour.
> Assert on svn move [URL] [URL]/subdir
> -
>
> Key: SVN-4913
> URL: https://issues.apache.org/jira/browse/SVN-4913
> Project: Subversion
> Issue Type: Task
>Affects Versions: 1.14.0
>Reporter: Daniel Sahlberg
>Assignee: Daniel Sahlberg
>Priority: Minor
> Attachments: move_to_subdir.patch, testcase.patch
>
>
> As reported on dev@:
> [https://lists.apache.org/thread/s4byt3p2tot453smhhdlh0fhygy2bhb9]
> The SVN client crashes when I run the following command:
> {{$ svn move [https://svn1.mydomain.com/svn/MyRepo]/
> [https://svn1.mydomain.com/svn/MyRepo/trunk] -m "Test Commit"}}
> {{{}svn: E235000: In file '..\..\..\subversion\libsvn_client\copy.c' line
> 1187: assertion failed (! svn_path_is_empty(path)){}}}}}{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SVN-4913) Assert on svn move [URL] [URL]/subdir
[
https://issues.apache.org/jira/browse/SVN-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg updated SVN-4913:
-
Attachment: testcase.patch
> Assert on svn move [URL] [URL]/subdir
> -
>
> Key: SVN-4913
> URL: https://issues.apache.org/jira/browse/SVN-4913
> Project: Subversion
> Issue Type: Task
>Affects Versions: 1.14.0
>Reporter: Daniel Sahlberg
>Assignee: Daniel Sahlberg
>Priority: Minor
> Attachments: move_to_subdir.patch, testcase.patch
>
>
> As reported on dev@:
> [https://lists.apache.org/thread/s4byt3p2tot453smhhdlh0fhygy2bhb9]
> The SVN client crashes when I run the following command:
> {{$ svn move [https://svn1.mydomain.com/svn/MyRepo]/
> [https://svn1.mydomain.com/svn/MyRepo/trunk] -m "Test Commit"}}
> {{{}svn: E235000: In file '..\..\..\subversion\libsvn_client\copy.c' line
> 1187: assertion failed (! svn_path_is_empty(path)){}}}}}{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4913) Assert on svn move [URL] [URL]/subdir
[
https://issues.apache.org/jira/browse/SVN-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709906#comment-17709906
]
Daniel Sahlberg commented on SVN-4913:
--
With the attached patch:
$ svn move $REPOURL $REPOURL/SUBDIR -m 'mv root'
svn: E27: Cannot copy path '$REPOURL' into its own child '$REPOURL/SUBDIR'
$ svn move $REPOURL/A2 $REPOURL/A/SUBDIR -m 'mv dir'
svn: E27: Cannot copy path '$REPOURL/A' into its own child
'$REPOURL/A/SUBDIR'
Ie, both cases return the same error (although the subdir move has a new error
message).
> Assert on svn move [URL] [URL]/subdir
> -
>
> Key: SVN-4913
> URL: https://issues.apache.org/jira/browse/SVN-4913
> Project: Subversion
> Issue Type: Task
>Affects Versions: 1.14.0
>Reporter: Daniel Sahlberg
>Assignee: Daniel Sahlberg
>Priority: Minor
> Attachments: move_to_subdir.patch
>
>
> As reported on dev@:
> [https://lists.apache.org/thread/s4byt3p2tot453smhhdlh0fhygy2bhb9]
> The SVN client crashes when I run the following command:
> {{$ svn move [https://svn1.mydomain.com/svn/MyRepo]/
> [https://svn1.mydomain.com/svn/MyRepo/trunk] -m "Test Commit"}}
> {{{}svn: E235000: In file '..\..\..\subversion\libsvn_client\copy.c' line
> 1187: assertion failed (! svn_path_is_empty(path)){}}}}}{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SVN-4913) Assert on svn move [URL] [URL]/subdir
[
https://issues.apache.org/jira/browse/SVN-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg updated SVN-4913:
-
Attachment: move_to_subdir.patch
> Assert on svn move [URL] [URL]/subdir
> -
>
> Key: SVN-4913
> URL: https://issues.apache.org/jira/browse/SVN-4913
> Project: Subversion
> Issue Type: Task
>Affects Versions: 1.14.0
>Reporter: Daniel Sahlberg
>Assignee: Daniel Sahlberg
>Priority: Minor
> Attachments: move_to_subdir.patch
>
>
> As reported on dev@:
> [https://lists.apache.org/thread/s4byt3p2tot453smhhdlh0fhygy2bhb9]
> The SVN client crashes when I run the following command:
> {{$ svn move [https://svn1.mydomain.com/svn/MyRepo]/
> [https://svn1.mydomain.com/svn/MyRepo/trunk] -m "Test Commit"}}
> {{{}svn: E235000: In file '..\..\..\subversion\libsvn_client\copy.c' line
> 1187: assertion failed (! svn_path_is_empty(path)){}}}}}{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4913) Assert on svn move [URL] [URL]/subdir
[
https://issues.apache.org/jira/browse/SVN-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709905#comment-17709905
]
Daniel Sahlberg commented on SVN-4913:
--
Current behaviour:
$ svn move $REPOURL $REPOURL/SUBDIR -m 'mv root'
svn: E235000: In file '../subversion/libsvn_client/copy.c' line 1187: assertion
failed (! svn_path_is_empty(path))
Aborted
$ svn move $REPOURL/A $REPOURL/A/SUBDIR -m 'mv dir'
svn: E160016: Path 'A' not present
Thus, moving a directory to its child does not work in either case.
> Assert on svn move [URL] [URL]/subdir
> -
>
> Key: SVN-4913
> URL: https://issues.apache.org/jira/browse/SVN-4913
> Project: Subversion
> Issue Type: Task
>Affects Versions: 1.14.0
>Reporter: Daniel Sahlberg
>Assignee: Daniel Sahlberg
>Priority: Minor
>
> As reported on dev@:
> [https://lists.apache.org/thread/s4byt3p2tot453smhhdlh0fhygy2bhb9]
> The SVN client crashes when I run the following command:
> {{$ svn move [https://svn1.mydomain.com/svn/MyRepo]/
> [https://svn1.mydomain.com/svn/MyRepo/trunk] -m "Test Commit"}}
> {{{}svn: E235000: In file '..\..\..\subversion\libsvn_client\copy.c' line
> 1187: assertion failed (! svn_path_is_empty(path)){}}}}}{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SVN-4913) Assert on svn move [URL] [URL]/subdir
[
https://issues.apache.org/jira/browse/SVN-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg updated SVN-4913:
-
Environment: (was: As reported on dev@:
[https://lists.apache.org/thread/s4byt3p2tot453smhhdlh0fhygy2bhb9]
The SVN client crashes when I run the following command:
{{$ svn move [https://svn1.mydomain.com/svn/MyRepo]/
[https://svn1.mydomain.com/svn/MyRepo/trunk] -m "Test Commit"}}
{{{}svn: E235000: In file '..\..\..\subversion\libsvn_client\copy.c' line 1187:
assertion failed (! svn_path_is_empty(path)){}}}{{{}{}}}
)
> Assert on svn move [URL] [URL]/subdir
> -
>
> Key: SVN-4913
> URL: https://issues.apache.org/jira/browse/SVN-4913
> Project: Subversion
> Issue Type: Task
>Affects Versions: 1.14.0
>Reporter: Daniel Sahlberg
>Assignee: Daniel Sahlberg
>Priority: Minor
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SVN-4913) Assert on svn move [URL] [URL]/subdir
[
https://issues.apache.org/jira/browse/SVN-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg updated SVN-4913:
-
Description:
As reported on dev@:
[https://lists.apache.org/thread/s4byt3p2tot453smhhdlh0fhygy2bhb9]
The SVN client crashes when I run the following command:
{{$ svn move [https://svn1.mydomain.com/svn/MyRepo]/
[https://svn1.mydomain.com/svn/MyRepo/trunk] -m "Test Commit"}}
{{{}svn: E235000: In file '..\..\..\subversion\libsvn_client\copy.c' line 1187:
assertion failed (! svn_path_is_empty(path)){}}}}}{}}}
> Assert on svn move [URL] [URL]/subdir
> -
>
> Key: SVN-4913
> URL: https://issues.apache.org/jira/browse/SVN-4913
> Project: Subversion
> Issue Type: Task
>Affects Versions: 1.14.0
>Reporter: Daniel Sahlberg
>Assignee: Daniel Sahlberg
>Priority: Minor
>
> As reported on dev@:
> [https://lists.apache.org/thread/s4byt3p2tot453smhhdlh0fhygy2bhb9]
> The SVN client crashes when I run the following command:
> {{$ svn move [https://svn1.mydomain.com/svn/MyRepo]/
> [https://svn1.mydomain.com/svn/MyRepo/trunk] -m "Test Commit"}}
> {{{}svn: E235000: In file '..\..\..\subversion\libsvn_client\copy.c' line
> 1187: assertion failed (! svn_path_is_empty(path)){}}}}}{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SVN-4913) Assert on svn move [URL] [URL]/subdir
Daniel Sahlberg created SVN-4913:
Summary: Assert on svn move [URL] [URL]/subdir
Key: SVN-4913
URL: https://issues.apache.org/jira/browse/SVN-4913
Project: Subversion
Issue Type: Task
Affects Versions: 1.14.0
Environment: As reported on dev@:
[https://lists.apache.org/thread/s4byt3p2tot453smhhdlh0fhygy2bhb9]
The SVN client crashes when I run the following command:
{{$ svn move [https://svn1.mydomain.com/svn/MyRepo]/
[https://svn1.mydomain.com/svn/MyRepo/trunk] -m "Test Commit"}}
{{{}svn: E235000: In file '..\..\..\subversion\libsvn_client\copy.c' line 1187:
assertion failed (! svn_path_is_empty(path)){}}}{{{}{}}}
Reporter: Daniel Sahlberg
Assignee: Daniel Sahlberg
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SVN-4911) SQLite error on HTTP to HTTPS redirect with file externals
[
https://issues.apache.org/jira/browse/SVN-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg resolved SVN-4911.
--
Resolution: Fixed
r1908926, nominated for backport to 1.14.
> SQLite error on HTTP to HTTPS redirect with file externals
> --
>
> Key: SVN-4911
> URL: https://issues.apache.org/jira/browse/SVN-4911
> Project: Subversion
> Issue Type: Bug
>Affects Versions: 1.14.2
>Reporter: Nathan Hartman
>Assignee: Daniel Sahlberg
>Priority: Major
> Fix For: 1.15, 1.14.3
>
>
> Users who previously served repositories via HTTP, wish to migrate to HTTPS,
> configured redirection, and whose repositories use file-externals, are
> encountering a failure during "svn checkout" or "svn upgrade" when the
> file-external is encountered.
> The command line client prints text similar to:
> {{Redirecting to URL 'https://repo/.../test.txt':}}
> {{Fetching external item into 'wc\test.txt':}}
> {{svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed:
> EXTERNALS.def_repos_relpath}}
> {{.}}
> {{.}}
> {{.}}
> {{Checked out revision N.}}
> {{svn: E205011: Failure occurred processing one or more externals
> definitions}}
> References:
> 1. Mail by Pál Kovács (with reproduction steps) to users@s.a.o with title
> "redirection error with file externals - possible bug" dated Saturday, March
> 11, 2023, archived:
> https://lists.apache.org/thread/go4r3lflzy7yvq7bt4rnofyc46n59whh
> 2. Mail by Baldauf Christoph to users@s.a.o with title "Checkout problem via
> http with file external pointing at redirected URL" dated Tuesday, February
> 7, 2023, archived:
> https://lists.apache.org/thread/x0v1tj68d2mz4vdoxj0bts8h5x892q9n
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SVN-4911) SQLite error on HTTP to HTTPS redirect with file externals
[
https://issues.apache.org/jira/browse/SVN-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg reassigned SVN-4911:
Assignee: Daniel Sahlberg
> SQLite error on HTTP to HTTPS redirect with file externals
> --
>
> Key: SVN-4911
> URL: https://issues.apache.org/jira/browse/SVN-4911
> Project: Subversion
> Issue Type: Bug
>Affects Versions: 1.14.2
>Reporter: Nathan Hartman
>Assignee: Daniel Sahlberg
>Priority: Major
> Fix For: 1.15, 1.14.3
>
>
> Users who previously served repositories via HTTP, wish to migrate to HTTPS,
> configured redirection, and whose repositories use file-externals, are
> encountering a failure during "svn checkout" or "svn upgrade" when the
> file-external is encountered.
> The command line client prints text similar to:
> {{Redirecting to URL 'https://repo/.../test.txt':}}
> {{Fetching external item into 'wc\test.txt':}}
> {{svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed:
> EXTERNALS.def_repos_relpath}}
> {{.}}
> {{.}}
> {{.}}
> {{Checked out revision N.}}
> {{svn: E205011: Failure occurred processing one or more externals
> definitions}}
> References:
> 1. Mail by Pál Kovács (with reproduction steps) to users@s.a.o with title
> "redirection error with file externals - possible bug" dated Saturday, March
> 11, 2023, archived:
> https://lists.apache.org/thread/go4r3lflzy7yvq7bt4rnofyc46n59whh
> 2. Mail by Baldauf Christoph to users@s.a.o with title "Checkout problem via
> http with file external pointing at redirected URL" dated Tuesday, February
> 7, 2023, archived:
> https://lists.apache.org/thread/x0v1tj68d2mz4vdoxj0bts8h5x892q9n
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SVN-4911) SQLite error on HTTP to HTTPS redirect with file externals
[
https://issues.apache.org/jira/browse/SVN-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sahlberg updated SVN-4911:
-
Fix Version/s: 1.14.3
1.15
> SQLite error on HTTP to HTTPS redirect with file externals
> --
>
> Key: SVN-4911
> URL: https://issues.apache.org/jira/browse/SVN-4911
> Project: Subversion
> Issue Type: Bug
>Affects Versions: 1.14.2
>Reporter: Nathan Hartman
>Priority: Major
> Fix For: 1.15, 1.14.3
>
>
> Users who previously served repositories via HTTP, wish to migrate to HTTPS,
> configured redirection, and whose repositories use file-externals, are
> encountering a failure during "svn checkout" or "svn upgrade" when the
> file-external is encountered.
> The command line client prints text similar to:
> {{Redirecting to URL 'https://repo/.../test.txt':}}
> {{Fetching external item into 'wc\test.txt':}}
> {{svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed:
> EXTERNALS.def_repos_relpath}}
> {{.}}
> {{.}}
> {{.}}
> {{Checked out revision N.}}
> {{svn: E205011: Failure occurred processing one or more externals
> definitions}}
> References:
> 1. Mail by Pál Kovács (with reproduction steps) to users@s.a.o with title
> "redirection error with file externals - possible bug" dated Saturday, March
> 11, 2023, archived:
> https://lists.apache.org/thread/go4r3lflzy7yvq7bt4rnofyc46n59whh
> 2. Mail by Baldauf Christoph to users@s.a.o with title "Checkout problem via
> http with file external pointing at redirected URL" dated Tuesday, February
> 7, 2023, archived:
> https://lists.apache.org/thread/x0v1tj68d2mz4vdoxj0bts8h5x892q9n
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4911) SQLite error on HTTP to HTTPS redirect with file externals
[
https://issues.apache.org/jira/browse/SVN-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707709#comment-17707709
]
Daniel Sahlberg commented on SVN-4911:
--
Related to [#SVN-4428]
The fix in r1525902 was only applied to ext_kind == svn_node_dir. A similar fix
should be applied to ext_kind == svn_node_file.
Committed as r1908926.
(The fix passes make check and make davautocheck)
> SQLite error on HTTP to HTTPS redirect with file externals
> --
>
> Key: SVN-4911
> URL: https://issues.apache.org/jira/browse/SVN-4911
> Project: Subversion
> Issue Type: Bug
>Affects Versions: 1.14.2
>Reporter: Nathan Hartman
>Priority: Major
>
> Users who previously served repositories via HTTP, wish to migrate to HTTPS,
> configured redirection, and whose repositories use file-externals, are
> encountering a failure during "svn checkout" or "svn upgrade" when the
> file-external is encountered.
> The command line client prints text similar to:
> {{Redirecting to URL 'https://repo/.../test.txt':}}
> {{Fetching external item into 'wc\test.txt':}}
> {{svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed:
> EXTERNALS.def_repos_relpath}}
> {{.}}
> {{.}}
> {{.}}
> {{Checked out revision N.}}
> {{svn: E205011: Failure occurred processing one or more externals
> definitions}}
> References:
> 1. Mail by Pál Kovács (with reproduction steps) to users@s.a.o with title
> "redirection error with file externals - possible bug" dated Saturday, March
> 11, 2023, archived:
> https://lists.apache.org/thread/go4r3lflzy7yvq7bt4rnofyc46n59whh
> 2. Mail by Baldauf Christoph to users@s.a.o with title "Checkout problem via
> http with file external pointing at redirected URL" dated Tuesday, February
> 7, 2023, archived:
> https://lists.apache.org/thread/x0v1tj68d2mz4vdoxj0bts8h5x892q9n
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SVN-4912) [Linkis] Unable To commit in svn due to large file size
[ https://issues.apache.org/jira/browse/SVN-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chen Xia closed SVN-4912. - Resolution: Invalid issue post error > [Linkis] Unable To commit in svn due to large file size > --- > > Key: SVN-4912 > URL: https://issues.apache.org/jira/browse/SVN-4912 > Project: Subversion > Issue Type: Task >Reporter: Chen Xia >Priority: Major > > I am trying to commit release Apache linkis 1.3.2 artifacts[(510MB+) to > https://dist.apache.org/repos/dist/dev/linkis/1.3.2-rcxx, but got a "Entity > too large" error. > Can you help to increase it to something like 1GB. > Thanks. > commit files list as: > 516M apache-linkis-1.3.2-bin.tar.gz > 833B apache-linkis-1.3.2-bin.tar.gz.asc > 161B apache-linkis-1.3.2-bin.tar.gz.sha512 > 3.4M apache-linkis-1.3.2-src.tar.gz > 833B apache-linkis-1.3.2-src.tar.gz.asc > 161B apache-linkis-1.3.2-src.tar.gz.sha512 > 18M apache-linkis-1.3.2-web-bin.tar.gz > 833B apache-linkis-1.3.2-web-bin.tar.gz.asc > 165B apache-linkis-1.3.2-web-bin.tar.gz.sha512 > Because binary compiled package apache-linkis-1.3.2-bin.tar.gz(516M) is too > large. > It contains all the third-party dependencies, it main modules are as follows > ├── linkis-commons (139M) > │ └── public-module > ├── linkis-computation-governance (27M) > │ ├── linkis-cg-engineconnmanager > │ ├── linkis-cg-entrance > │ ├── linkis-cg-linkismanager > │ └── linkis-client > ├── linkis-engineconn-plugins (164M) > │ ├── elasticsearch > │ ├── flink > │ ├── hive > │ ├── io_file > │ ├── jdbc > │ ├── openlookeng > │ ├── pipeline > │ ├── presto > │ ├── python > │ ├── seatunnel > │ ├── shell > │ ├── spark > │ ├── sqoop > │ └── trino > ├── linkis-public-enhancements (133M) > │ └── linkis-ps-publicservice > └── linkis-spring-cloud-services (113M) > ├── linkis-mg-eureka > └── linkis-mg-gateway -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SVN-4912) [Linkis] Unable To commit in svn due to large file size
[ https://issues.apache.org/jira/browse/SVN-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706084#comment-17706084 ] Nathan Hartman commented on SVN-4912: - This is the issue tracker for Subversion development (i.e., bugs and feature requests). Your issue is related to INFRA's configured limit on commit sizes. Please post your issue to INFRA's issue tracker instead. > [Linkis] Unable To commit in svn due to large file size > --- > > Key: SVN-4912 > URL: https://issues.apache.org/jira/browse/SVN-4912 > Project: Subversion > Issue Type: Task >Reporter: Chen Xia >Priority: Major > > I am trying to commit release Apache linkis 1.3.2 artifacts[(510MB+) to > https://dist.apache.org/repos/dist/dev/linkis/1.3.2-rcxx, but got a "Entity > too large" error. > Can you help to increase it to something like 1GB. > Thanks. > commit files list as: > 516M apache-linkis-1.3.2-bin.tar.gz > 833B apache-linkis-1.3.2-bin.tar.gz.asc > 161B apache-linkis-1.3.2-bin.tar.gz.sha512 > 3.4M apache-linkis-1.3.2-src.tar.gz > 833B apache-linkis-1.3.2-src.tar.gz.asc > 161B apache-linkis-1.3.2-src.tar.gz.sha512 > 18M apache-linkis-1.3.2-web-bin.tar.gz > 833B apache-linkis-1.3.2-web-bin.tar.gz.asc > 165B apache-linkis-1.3.2-web-bin.tar.gz.sha512 > Because binary compiled package apache-linkis-1.3.2-bin.tar.gz(516M) is too > large. > It contains all the third-party dependencies, it main modules are as follows > ├── linkis-commons (139M) > │ └── public-module > ├── linkis-computation-governance (27M) > │ ├── linkis-cg-engineconnmanager > │ ├── linkis-cg-entrance > │ ├── linkis-cg-linkismanager > │ └── linkis-client > ├── linkis-engineconn-plugins (164M) > │ ├── elasticsearch > │ ├── flink > │ ├── hive > │ ├── io_file > │ ├── jdbc > │ ├── openlookeng > │ ├── pipeline > │ ├── presto > │ ├── python > │ ├── seatunnel > │ ├── shell > │ ├── spark > │ ├── sqoop > │ └── trino > ├── linkis-public-enhancements (133M) > │ └── linkis-ps-publicservice > └── linkis-spring-cloud-services (113M) > ├── linkis-mg-eureka > └── linkis-mg-gateway -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SVN-4912) [Linkis] Unable To commit in svn due to large file size
Chen Xia created SVN-4912: - Summary: [Linkis] Unable To commit in svn due to large file size Key: SVN-4912 URL: https://issues.apache.org/jira/browse/SVN-4912 Project: Subversion Issue Type: Task Reporter: Chen Xia I am trying to commit release Apache linkis 1.3.2 artifacts[(510MB+) to https://dist.apache.org/repos/dist/dev/linkis/1.3.2-rcxx, but got a "Entity too large" error. Can you help to increase it to something like 1GB. Thanks. commit files list as: 516M apache-linkis-1.3.2-bin.tar.gz 833B apache-linkis-1.3.2-bin.tar.gz.asc 161B apache-linkis-1.3.2-bin.tar.gz.sha512 3.4M apache-linkis-1.3.2-src.tar.gz 833B apache-linkis-1.3.2-src.tar.gz.asc 161B apache-linkis-1.3.2-src.tar.gz.sha512 18M apache-linkis-1.3.2-web-bin.tar.gz 833B apache-linkis-1.3.2-web-bin.tar.gz.asc 165B apache-linkis-1.3.2-web-bin.tar.gz.sha512 Because binary compiled package apache-linkis-1.3.2-bin.tar.gz(516M) is too large. It contains all the third-party dependencies, it main modules are as follows ├── linkis-commons (139M) │ └── public-module ├── linkis-computation-governance (27M) │ ├── linkis-cg-engineconnmanager │ ├── linkis-cg-entrance │ ├── linkis-cg-linkismanager │ └── linkis-client ├── linkis-engineconn-plugins (164M) │ ├── elasticsearch │ ├── flink │ ├── hive │ ├── io_file │ ├── jdbc │ ├── openlookeng │ ├── pipeline │ ├── presto │ ├── python │ ├── seatunnel │ ├── shell │ ├── spark │ ├── sqoop │ └── trino ├── linkis-public-enhancements (133M) │ └── linkis-ps-publicservice └── linkis-spring-cloud-services (113M) ├── linkis-mg-eureka └── linkis-mg-gateway -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SVN-4911) SQLite error on HTTP to HTTPS redirect with file externals
Nathan Hartman created SVN-4911:
---
Summary: SQLite error on HTTP to HTTPS redirect with file externals
Key: SVN-4911
URL: https://issues.apache.org/jira/browse/SVN-4911
Project: Subversion
Issue Type: Bug
Affects Versions: 1.14.2
Reporter: Nathan Hartman
Users who previously served repositories via HTTP, wish to migrate to HTTPS,
configured redirection, and whose repositories use file-externals, are
encountering a failure during "svn checkout" or "svn upgrade" when the
file-external is encountered.
The command line client prints text similar to:
{{Redirecting to URL 'https://repo/.../test.txt':}}
{{Fetching external item into 'wc\test.txt':}}
{{svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed:
EXTERNALS.def_repos_relpath}}
{{.}}
{{.}}
{{.}}
{{Checked out revision N.}}
{{svn: E205011: Failure occurred processing one or more externals definitions}}
References:
1. Mail by Pál Kovács (with reproduction steps) to users@s.a.o with title
"redirection error with file externals - possible bug" dated Saturday, March
11, 2023, archived:
https://lists.apache.org/thread/go4r3lflzy7yvq7bt4rnofyc46n59whh
2. Mail by Baldauf Christoph to users@s.a.o with title "Checkout problem via
http with file external pointing at redirected URL" dated Tuesday, February 7,
2023, archived: https://lists.apache.org/thread/x0v1tj68d2mz4vdoxj0bts8h5x892q9n
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4910) Tree conflict resolution removes unversioned files from the working copy
[
https://issues.apache.org/jira/browse/SVN-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636726#comment-17636726
]
Stefan Sperling commented on SVN-4910:
--
It seems there is a broken API promise in svn_wc_delete4(). Well, at least the
docs are very unclear here:
{code:c}
* If @a keep_local is FALSE, this function immediately deletes all files,
* modified and unmodified, versioned and if @a delete_unversioned is TRUE,
* unversioned from the working copy.
{code}
The advertised delete_unversioned parameter does not exist; a parameter which
does exist is called "deleted_unversioned_target", and the conflict resolver
sets this parameter to FALSE when calling svn_wc_delete4(), hoping that
unversioned files will not be deleted.
However, svn_wc_delete4() ends up removing the entire directory hierarchy, rm
-rf style, via svn_io_remove_dir2(), with no regard to the contents. In the
actual implementation, the API parameter only applies to the root directory of
the to-be-deleted subtree.
Looking at the log message and commit of https://svn.apache.org/r879865, it
seems this docstring has always been wrong.
Possible approaches to a fix are:
1) Fix svn_wc_delete4() to leave unversioned files/directories behind on disk
as promised. This is probably the cleanest fix, but it would require several
internal API changes, as there are about 4 layers of code between the actual
call which removes the directory and the conflict resolver code. The work queue
operation which deletes directories would have to skip deleting unversioned
nodes from disk, and this behaviour would need to be controlled by a new API
flag parameter.
2) Have the conflict resolver back up unversioned files/directories before
removing the directory from disk, and then copy them back. This is a fragile
hack (if something goes wrong in the middle, files will still be lost), but it
is easy to implement.
3) Have the conflict resolver attempt to move unversioned files/directory into
the rename target directory. This is very difficult, as it is unclear what
should happen if new tree-conflicts occur while moving unversioned
files/directories into the rename target directory (names could now clash,
there could be versioned directories with a name that an unversioned file wants
to use, etc.). Leaving the unversioned items behind at their original location
is probably better.
> Tree conflict resolution removes unversioned files from the working copy
>
>
> Key: SVN-4910
> URL: https://issues.apache.org/jira/browse/SVN-4910
> Project: Subversion
> Issue Type: Bug
>Affects Versions: 1.14.2
> Environment: Windows:
> svn, version 1.14.2 (r1899510)
> compiled Aug 12 2022, 12:55:13 on x86_64-microsoft-windows6.2.9200
>
> macOS:
> svn, version 1.14.2 (r1899510)
> compiled Apr 13 2022, 14:56:48 on arm-apple-darwin21.3.0
>
> Linux:
> Ubuntu 22.04 running on WSL.
>Reporter: Pavel Lyalyakin
>Priority: Major
>
> It appears that running `svn update` can silently remove unversioned files in
> the working copy when automatically resolving a tree conflict. The file
> "unversionedfile.txt" will be removed after following the reproduction script
> given below.
> Note that when I run `svn update` with the `--accept postpone` option, the
> unversioned file remains in the working copy.
> Reported in the users@ mailing list:
> [https://lists.apache.org/thread/qmg6xqs5xpjr6kyhblwxvnhykobxwm8x]
> [https://lists.apache.org/thread/phpotj6pvvcmlt1vx9y7lbn6vof0d6y2]
>
> Info from the user's report in the mailing list:
> {quote}* User 1 renames a svn folder and commits this
> * User 2 has unversioned files and uncommited files in the renamed folder
> * User 2 performs an update
> * Subversion encounter a tree conflict
> * All files are still on the disk during this step * Subversion solves three
> conflict. * unversioned files are removed from users 2 disk. The unversioned
> files are retained in the old folder with the old name when the same sequence
> is executed with no uncommited files on users 2 computer.
> This all has been performed using : Svn, version 1.14.2 (r1899510) compiled
> Sep 24 2022, 10:21:16 on x86-microsoft-windows using Microsoft Windows
> [Version 10.0.19045.2130]. {quote}
> And confirmed in the dev@ mailing list:
> [https://lists.apache.org/thread/5gm8wcm0fs714lft0sd5pmczr9okjl02]
> Reproduction script for Windows, macOS and Linux:
>
> Windows:
> {code:java}
> mkdir C:\marcel-bug-report
> svnadmin create C:\marcel-bug-report\MyRepo
> svn mkdir file:///C:/marcel-bug-report/MyRepo/M
[jira] [Created] (SVN-4910) Tree conflict resolution removes unversioned files from the working copy
Pavel Lyalyakin created SVN-4910:
Summary: Tree conflict resolution removes unversioned files from
the working copy
Key: SVN-4910
URL: https://issues.apache.org/jira/browse/SVN-4910
Project: Subversion
Issue Type: Bug
Affects Versions: 1.14.2
Environment: Windows:
svn, version 1.14.2 (r1899510)
compiled Aug 12 2022, 12:55:13 on x86_64-microsoft-windows6.2.9200
macOS:
svn, version 1.14.2 (r1899510)
compiled Apr 13 2022, 14:56:48 on arm-apple-darwin21.3.0
Linux:
Ubuntu 22.04 running on WSL.
Reporter: Pavel Lyalyakin
It appears that running `svn update` can silently remove unversioned files in
the working copy when automatically resolving a tree conflict. The file
"unversionedfile.txt" will be removed after following the reproduction script
given below.
Note that when I run `svn update` with the `--accept postpone` option, the
unversioned file remains in the working copy.
Reported in the users@ mailing list:
[https://lists.apache.org/thread/qmg6xqs5xpjr6kyhblwxvnhykobxwm8x]
[https://lists.apache.org/thread/phpotj6pvvcmlt1vx9y7lbn6vof0d6y2]
Info from the user's report in the mailing list:
{quote}* User 1 renames a svn folder and commits this
* User 2 has unversioned files and uncommited files in the renamed folder
* User 2 performs an update
* Subversion encounter a tree conflict
* All files are still on the disk during this step * Subversion solves three
conflict. * unversioned files are removed from users 2 disk. The unversioned
files are retained in the old folder with the old name when the same sequence
is executed with no uncommited files on users 2 computer.
This all has been performed using : Svn, version 1.14.2 (r1899510) compiled Sep
24 2022, 10:21:16 on x86-microsoft-windows using Microsoft Windows [Version
10.0.19045.2130]. {quote}
And confirmed in the dev@ mailing list:
[https://lists.apache.org/thread/5gm8wcm0fs714lft0sd5pmczr9okjl02]
Reproduction script for Windows, macOS and Linux:
Windows:
{code:java}
mkdir C:\marcel-bug-report
svnadmin create C:\marcel-bug-report\MyRepo
svn mkdir file:///C:/marcel-bug-report/MyRepo/MyDir -m "Adding a new directory"
svn checkout file:///C:/marcel-bug-report/MyRepo/
C:\marcel-bug-report\working-copy-one
echo foo > C:\marcel-bug-report\working-copy-one\MyDir\myfile.txt
svn add C:\marcel-bug-report\working-copy-one\MyDir\myfile.txt
svn commit C:\marcel-bug-report\working-copy-one\ -m "Adding a new file"
echo bar > C:\marcel-bug-report\working-copy-one\MyDir\myfile.txt
echo baz > C:\marcel-bug-report\working-copy-one\MyDir\unversionedfile.txt
svn move file:///C:/marcel-bug-report/MyRepo/MyDir
file:///C:/marcel-bug-report/MyRepo/RenamedDir -m "Renaming a directory"
svn update C:\marcel-bug-report\working-copy-one{code}
macOS and Linux:
{code:java}
mkdir $HOME/marcel-bug-report
svnadmin create $HOME/marcel-bug-report/MyRepo
svn mkdir file:///$HOME/marcel-bug-report/MyRepo/MyDir -m "Adding a new
directory"
svn checkout file:///$HOME/marcel-bug-report/MyRepo/
$HOME/marcel-bug-report/working-copy-one
echo foo > $HOME/marcel-bug-report/working-copy-one/MyDir/myfile.txt
svn add $HOME/marcel-bug-report/working-copy-one/MyDir/myfile.txt
svn commit $HOME/marcel-bug-report/working-copy-one/ -m "Adding a new file"
echo bar > $HOME/marcel-bug-report/working-copy-one/MyDir/myfile.txt
echo baz > $HOME/marcel-bug-report/working-copy-one/MyDir/unversionedfile.txt
svn move file:///$HOME/marcel-bug-report/MyRepo/MyDir
file:///$HOME/marcel-bug-report/MyRepo/RenamedDir -m "Renaming a directory"
svn update $HOME/marcel-bug-report/working-copy-one/{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4622) revert as root always notifies for files
[ https://issues.apache.org/jira/browse/SVN-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618000#comment-17618000 ] Chris Pickett commented on SVN-4622: This commonly occurs under Cygwin if the owner of a file somehow becomes Administrators instead of the regular Cygwin user. "chown file" fixes it. > revert as root always notifies for files > > > Key: SVN-4622 > URL: https://issues.apache.org/jira/browse/SVN-4622 > Project: Subversion > Issue Type: Bug > Components: libsvn_subr >Affects Versions: all >Reporter: Philip Martin >Priority: Minor > > $ svnadmin create repo > $ svn import -mm repo/format file://`pwd`/repo/f > $ umask 0022 > $ svn co file://`pwd`/repo wc > $ sudo svn revert wc/f > Reverted 'wc/f' > The function svn_io__is_finfo_read_only() will check the world permissions > when invoked with uid=root. A typical umask removes world write so this means > that root sees every file as read-only. This causes the revert code to invoke > svn_io_set_file_read_write() and notify. However svn_io_set_file_read_write() > sets the owner permissions, an operation that succeeds when run as root, and > obeys the umask so the world permissions remain read-only. > Reported by: > https://mail-archives.apache.org/mod_mbox/subversion-users/201602.mbox/%3C56C0738E.9010508%40i.ua%3E > http://svn.haxx.se/users/archive-2016-02/0061.shtml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SVN-4908) svn_wc__status2_from_3 does not copy locked info
[
https://issues.apache.org/jira/browse/SVN-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607763#comment-17607763
]
Nathan Hartman commented on SVN-4908:
-
Related mailing list discussions:
"svn_wc__status2_from_3 does not copy locked info" started August 29, 2022:
https://lists.apache.org/thread/yb3jzl7h07xvxh0p73qwl5f55dc49kdh
"Re: svn commit: r1903814 -
/subversion/branches/issue-4908/subversion/libsvn_wc/deprecated.c" started
September 9, 2022:
https://lists.apache.org/thread/m0yg277jmm4srvzvrhgw4hs9x3rfdr0w
> svn_wc__status2_from_3 does not copy locked info
>
>
> Key: SVN-4908
> URL: https://issues.apache.org/jira/browse/SVN-4908
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_wc
>Affects Versions: 1.14.0
> Environment: svn 1.14.1 all OS.
>
>Reporter: Barry Scott
>Priority: Major
>
> {color:#ff}I had a pysvn user report that they cannot detect that a wc is
> locked.{color}
> {color:#ff}What I found is that I get that info and indeed locked ==
> 0.{color}
> {color:#ff}This is because there is no code in svn_wc__status2_from_3
> to{color}
> {color:#ff}copy locked value from old_status->locked into
> *status->locked.{color}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4908) svn_wc__status2_from_3 does not copy locked info
[
https://issues.apache.org/jira/browse/SVN-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607760#comment-17607760
]
Nathan Hartman commented on SVN-4908:
-
Fix committed in
[r1904193|https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/deprecated.c?revision=1904193&view=markup#l2818].
Nominated for backport to 1.14.x in 1904194.
> svn_wc__status2_from_3 does not copy locked info
>
>
> Key: SVN-4908
> URL: https://issues.apache.org/jira/browse/SVN-4908
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_wc
>Affects Versions: 1.14.0
> Environment: svn 1.14.1 all OS.
>
>Reporter: Barry Scott
>Priority: Major
>
> {color:#ff}I had a pysvn user report that they cannot detect that a wc is
> locked.{color}
> {color:#ff}What I found is that I get that info and indeed locked ==
> 0.{color}
> {color:#ff}This is because there is no code in svn_wc__status2_from_3
> to{color}
> {color:#ff}copy locked value from old_status->locked into
> *status->locked.{color}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4909) Merged Information is missing xml option
[ https://issues.apache.org/jira/browse/SVN-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600287#comment-17600287 ] prajeesh Kozhisseri commented on SVN-4909: -- Nathan- Pls confirm on the below a) Do confirm if this is a open issue b) Pls confirm alternate workaround is there any scripts to read and get merge information, filename and revision id c) Pls confirm if any merges will it by default is populated in merged via column or is there any other alternates ways > Merged Information is missing xml option > > > Key: SVN-4909 > URL: https://issues.apache.org/jira/browse/SVN-4909 > Project: Subversion > Issue Type: Bug >Affects Versions: 1.13.0 > Environment: svn log --xml -g -v is not providing merge > infor. > > We wanted to track history and take all files along with author, revisions > and details of changes. Hence we run the xml version of svn log to see the > details including merged ones. > > We understand for every merge normally merged via is populated but in XML > Version it is missing >Reporter: prajeesh Kozhisseri >Priority: Blocker > > svn log --xml -g -v is not providing merge infor. > > We wanted to track history and take all files along with author, revisions > and details of changes. Hence we run the xml version of svn log to see the > details including merged ones. > > We understand for every merge normally merged via is populated but in XML > Version it is missing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SVN-4909) Merged Information is missing xml option
[
https://issues.apache.org/jira/browse/SVN-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599502#comment-17599502
]
Nathan Hartman edited comment on SVN-4909 at 9/2/22 1:51 PM:
-
Hello,
In the future, please discuss (potential) issues on the mailing list before
filing an issue in the issue tracker.
This issue seems related to SVN-4711.
I can confirm that currently we are not printing the merge stack when
outputting the log in XML format. See subversion/svn/log-cmd.c: In
svn_cl_{_}log_entry_receiver(), which prints the non-XML log, we iterate and
print the merge_stack, but we are not doing that in
svn_cl{_}_log_entry_receiver_xml().
Seeing this new issue (SVN-4909), I think the bug in SVN-4711 may have happened
because code to print the merge stack was intended, but ended up missing for
some reason.
In any event, any changes to the output, even to add the missing merge stack
information, will require a discussion at the developer mailing list (dev at
subversion dot apache dot org). Could you please start a mail thread there?
Please note that's a publicly archived mailing list. See:
[https://subversion.apache.org/mailing-lists.html.] If you would like, feel
free to include a patch that produces a proposed corrected output.
Thank you
was (Author: hartmannathan):
Hello,
In the future, please discuss (potential) issues on the mailing list before
filing an issue in the issue tracker.
This issue seems related to SVN-4711.
I can confirm that currently we are not printing the merge stack when
outputting the log in XML format. See subversion/svn/log-cmd.c: In
svn_cl__log_entry_receiver(), which prints the non-XML log, we iterate and
print the merge_stack, but we are not doing that in
svn_cl__log_entry_receiver_xml().
Seeing this new issue (SVN-4909), I think the bug in SVN-4711 may have happened
because code to print the merge stack was intended, but ended up missing for
some reason.
In any event, any changes to the output, even to add the missing merge stack
information, will require a discussion at the developer mailing list (dev at
subversion dot apache dot org). Could you please start a mail thread there? If
you would like, feel free to include a patch that produces a proposed corrected
output.
Thank you
> Merged Information is missing xml option
>
>
> Key: SVN-4909
> URL: https://issues.apache.org/jira/browse/SVN-4909
> Project: Subversion
> Issue Type: Bug
>Affects Versions: 1.13.0
> Environment: svn log --xml -g -v is not providing merge
> infor.
>
> We wanted to track history and take all files along with author, revisions
> and details of changes. Hence we run the xml version of svn log to see the
> details including merged ones.
>
> We understand for every merge normally merged via is populated but in XML
> Version it is missing
>Reporter: prajeesh Kozhisseri
>Priority: Blocker
>
> svn log --xml -g -v is not providing merge infor.
>
> We wanted to track history and take all files along with author, revisions
> and details of changes. Hence we run the xml version of svn log to see the
> details including merged ones.
>
> We understand for every merge normally merged via is populated but in XML
> Version it is missing
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4909) Merged Information is missing xml option
[ https://issues.apache.org/jira/browse/SVN-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599502#comment-17599502 ] Nathan Hartman commented on SVN-4909: - Hello, In the future, please discuss (potential) issues on the mailing list before filing an issue in the issue tracker. This issue seems related to SVN-4711. I can confirm that currently we are not printing the merge stack when outputting the log in XML format. See subversion/svn/log-cmd.c: In svn_cl__log_entry_receiver(), which prints the non-XML log, we iterate and print the merge_stack, but we are not doing that in svn_cl__log_entry_receiver_xml(). Seeing this new issue (SVN-4909), I think the bug in SVN-4711 may have happened because code to print the merge stack was intended, but ended up missing for some reason. In any event, any changes to the output, even to add the missing merge stack information, will require a discussion at the developer mailing list (dev at subversion dot apache dot org). Could you please start a mail thread there? If you would like, feel free to include a patch that produces a proposed corrected output. Thank you > Merged Information is missing xml option > > > Key: SVN-4909 > URL: https://issues.apache.org/jira/browse/SVN-4909 > Project: Subversion > Issue Type: Bug >Affects Versions: 1.13.0 > Environment: svn log --xml -g -v is not providing merge > infor. > > We wanted to track history and take all files along with author, revisions > and details of changes. Hence we run the xml version of svn log to see the > details including merged ones. > > We understand for every merge normally merged via is populated but in XML > Version it is missing >Reporter: prajeesh Kozhisseri >Priority: Blocker > > svn log --xml -g -v is not providing merge infor. > > We wanted to track history and take all files along with author, revisions > and details of changes. Hence we run the xml version of svn log to see the > details including merged ones. > > We understand for every merge normally merged via is populated but in XML > Version it is missing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SVN-4907) svn_fs_node_id causes memory leak...
[
https://issues.apache.org/jira/browse/SVN-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599488#comment-17599488
]
Nathan Hartman commented on SVN-4907:
-
Link to the above-mentioned mail thread:
https://lists.apache.org/thread/7f95t7snlsvff5oygvfyq7qwo8s3fw49
> svn_fs_node_id causes memory leak...
>
>
> Key: SVN-4907
> URL: https://issues.apache.org/jira/browse/SVN-4907
> Project: Subversion
> Issue Type: Bug
> Components: svnlook
>Affects Versions: 1.10.x
>Reporter: Nathan.qian
>Priority: Critical
> Attachments: svntest.c
>
>
> We used svnlook to transform a dynamic library for some of our interface
> operations. We found that memory leaks would occur when svn_fs_node_id (with
> apr_pool_t and svn_pool_destroy(pool)) was called frequently;
> The code looks shown below， we call svn_fs_node_id with apr_pool_t , and
> after the call , we use svn_pool_destroy(pool) clear memory. But there is a
> bug : if we use *{color:#ff}a nonexistent path call
> subcommand_show_revison, the memory will leak{color}* ; but if
> {color:#ff}*a existing path, the memory is ok, no memory leak*{color} .
>
> int init_svncmcenter(apr_pool_t *pool,char *out_str,const char
> *repos_path,const char *path,const char **path_relative,const char
> *rev,struct svnlook_opt_state *opt_state,svn_fs_root_t **root,const
> svn_fs_id_t **id,svnlook_ctxt_t * *c,int with_lastexist )
> {
> ..
> ..
> if ((svn_fs_node_id(id, *root, *path_relative, pool)) != SVN_NO_ERROR ||
> !(*id))
>
> {
> {color:#FF}*//memory leak happens here*{color}
> printf("path (%s) error. Warning: svn_fs_node_id may cause memory
> leaks.\n", path); sprintf(out_str,"212 path error"); return 212;
> }
> return 200;
> }
> int subcommand_show_revison(const char *repos_path,const char *path,const
> char *rev,char *out_str,int b_filesize,int with_changed_date,int with_author)
> {
> apr_pool_t *pool =
> apr_allocator_owner_get(svn_pool_create_allocator(FALSE));
> ..
> ..
> if (init_svncmcenter(pool,out_str, repos_path,
> path,&path_relative,rev,&opt_state,&root,&id,&c,1) != 200)
> {
> {color:#ff} *svn_pool_destroy(pool);*{color}
> return -1;
> }
> ..
> ..
> svn_pool_destroy(pool);
> return 0;
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4907) svn_fs_node_id causes memory leak...
[
https://issues.apache.org/jira/browse/SVN-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599398#comment-17599398
]
Daniel Shahaf commented on SVN-4907:
dev@ thread (subject "svn_fs_node_id causes memory leak", link not immdeiately
available, sorry) concluded the "memory leak" was caused by an uncleared
svn_error_t in user code.
> svn_fs_node_id causes memory leak...
>
>
> Key: SVN-4907
> URL: https://issues.apache.org/jira/browse/SVN-4907
> Project: Subversion
> Issue Type: Bug
> Components: svnlook
>Affects Versions: 1.10.x
>Reporter: Nathan.qian
>Priority: Critical
> Attachments: svntest.c
>
>
> We used svnlook to transform a dynamic library for some of our interface
> operations. We found that memory leaks would occur when svn_fs_node_id (with
> apr_pool_t and svn_pool_destroy(pool)) was called frequently;
> The code looks shown below， we call svn_fs_node_id with apr_pool_t , and
> after the call , we use svn_pool_destroy(pool) clear memory. But there is a
> bug : if we use *{color:#ff}a nonexistent path call
> subcommand_show_revison, the memory will leak{color}* ; but if
> {color:#ff}*a existing path, the memory is ok, no memory leak*{color} .
>
> int init_svncmcenter(apr_pool_t *pool,char *out_str,const char
> *repos_path,const char *path,const char **path_relative,const char
> *rev,struct svnlook_opt_state *opt_state,svn_fs_root_t **root,const
> svn_fs_id_t **id,svnlook_ctxt_t * *c,int with_lastexist )
> {
> ..
> ..
> if ((svn_fs_node_id(id, *root, *path_relative, pool)) != SVN_NO_ERROR ||
> !(*id))
>
> {
> {color:#FF}*//memory leak happens here*{color}
> printf("path (%s) error. Warning: svn_fs_node_id may cause memory
> leaks.\n", path); sprintf(out_str,"212 path error"); return 212;
> }
> return 200;
> }
> int subcommand_show_revison(const char *repos_path,const char *path,const
> char *rev,char *out_str,int b_filesize,int with_changed_date,int with_author)
> {
> apr_pool_t *pool =
> apr_allocator_owner_get(svn_pool_create_allocator(FALSE));
> ..
> ..
> if (init_svncmcenter(pool,out_str, repos_path,
> path,&path_relative,rev,&opt_state,&root,&id,&c,1) != 200)
> {
> {color:#ff} *svn_pool_destroy(pool);*{color}
> return -1;
> }
> ..
> ..
> svn_pool_destroy(pool);
> return 0;
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SVN-4909) Merged Information is missing xml option
[ https://issues.apache.org/jira/browse/SVN-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599373#comment-17599373 ] prajeesh Kozhisseri commented on SVN-4909: -- can someone look into this issue > Merged Information is missing xml option > > > Key: SVN-4909 > URL: https://issues.apache.org/jira/browse/SVN-4909 > Project: Subversion > Issue Type: Bug >Affects Versions: 1.13.0 > Environment: svn log --xml -g -v is not providing merge > infor. > > We wanted to track history and take all files along with author, revisions > and details of changes. Hence we run the xml version of svn log to see the > details including merged ones. > > We understand for every merge normally merged via is populated but in XML > Version it is missing >Reporter: prajeesh Kozhisseri >Priority: Blocker > > svn log --xml -g -v is not providing merge infor. > > We wanted to track history and take all files along with author, revisions > and details of changes. Hence we run the xml version of svn log to see the > details including merged ones. > > We understand for every merge normally merged via is populated but in XML > Version it is missing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SVN-4909) Merged Information is missing xml option
prajeesh Kozhisseri created SVN-4909: Summary: Merged Information is missing xml option Key: SVN-4909 URL: https://issues.apache.org/jira/browse/SVN-4909 Project: Subversion Issue Type: Bug Affects Versions: 1.13.0 Environment: svn log --xml -g -v is not providing merge infor. We wanted to track history and take all files along with author, revisions and details of changes. Hence we run the xml version of svn log to see the details including merged ones. We understand for every merge normally merged via is populated but in XML Version it is missing Reporter: prajeesh Kozhisseri svn log --xml -g -v is not providing merge infor. We wanted to track history and take all files along with author, revisions and details of changes. Hence we run the xml version of svn log to see the details including merged ones. We understand for every merge normally merged via is populated but in XML Version it is missing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SVN-4907) svn_fs_node_id causes memory leak...
[
https://issues.apache.org/jira/browse/SVN-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan.qian closed SVN-4907.
Resolution: Not A Problem
> svn_fs_node_id causes memory leak...
>
>
> Key: SVN-4907
> URL: https://issues.apache.org/jira/browse/SVN-4907
> Project: Subversion
> Issue Type: Bug
> Components: svnlook
>Affects Versions: 1.10.x
>Reporter: Nathan.qian
>Priority: Critical
> Attachments: svntest.c
>
>
> We used svnlook to transform a dynamic library for some of our interface
> operations. We found that memory leaks would occur when svn_fs_node_id (with
> apr_pool_t and svn_pool_destroy(pool)) was called frequently;
> The code looks shown below， we call svn_fs_node_id with apr_pool_t , and
> after the call , we use svn_pool_destroy(pool) clear memory. But there is a
> bug : if we use *{color:#ff}a nonexistent path call
> subcommand_show_revison, the memory will leak{color}* ; but if
> {color:#ff}*a existing path, the memory is ok, no memory leak*{color} .
>
> int init_svncmcenter(apr_pool_t *pool,char *out_str,const char
> *repos_path,const char *path,const char **path_relative,const char
> *rev,struct svnlook_opt_state *opt_state,svn_fs_root_t **root,const
> svn_fs_id_t **id,svnlook_ctxt_t * *c,int with_lastexist )
> {
> ..
> ..
> if ((svn_fs_node_id(id, *root, *path_relative, pool)) != SVN_NO_ERROR ||
> !(*id))
>
> {
> {color:#FF}*//memory leak happens here*{color}
> printf("path (%s) error. Warning: svn_fs_node_id may cause memory
> leaks.\n", path); sprintf(out_str,"212 path error"); return 212;
> }
> return 200;
> }
> int subcommand_show_revison(const char *repos_path,const char *path,const
> char *rev,char *out_str,int b_filesize,int with_changed_date,int with_author)
> {
> apr_pool_t *pool =
> apr_allocator_owner_get(svn_pool_create_allocator(FALSE));
> ..
> ..
> if (init_svncmcenter(pool,out_str, repos_path,
> path,&path_relative,rev,&opt_state,&root,&id,&c,1) != 200)
> {
> {color:#ff} *svn_pool_destroy(pool);*{color}
> return -1;
> }
> ..
> ..
> svn_pool_destroy(pool);
> return 0;
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SVN-4908) svn_wc__status2_from_3 does not copy locked info
Barry Scott created SVN-4908:
Summary: svn_wc__status2_from_3 does not copy locked info
Key: SVN-4908
URL: https://issues.apache.org/jira/browse/SVN-4908
Project: Subversion
Issue Type: Bug
Components: libsvn_wc
Affects Versions: 1.14.0
Environment: svn 1.14.1 all OS.
Reporter: Barry Scott
{color:#ff}I had a pysvn user report that they cannot detect that a wc is
locked.{color}
{color:#ff}What I found is that I get that info and indeed locked ==
0.{color}
{color:#ff}This is because there is no code in svn_wc__status2_from_3
to{color}
{color:#ff}copy locked value from old_status->locked into
*status->locked.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
