Re: svn commit: r1871827 - /subversion/trunk/subversion/bindings/swig/python/tests/client.py

[Yasuhito FUTATSUKI]

On 2019/12/21 5:04, Daniel Shahaf wrote:
> Yasuhito FUTATSUKI wrote on Fri, 20 Dec 2019 13:31 +00:00:
>> I found that nb->shelved_func() in this line is 
>> svn_swig_py_client_status_func() on swig Python bindings, and it is
>> incorrectly implemented that it isn't return value (i.e. void type).
>> This should be svn_client_status_func_t, which returns svn_error_t *.
> 
> Should some of these fixes be backported to 1.13.x?

No, both of the bugs were in the codes added on swig-py3 branch, thus
they don't affect 1.13.x.

Cheers,
-- 
Yasuhito FUTATSUKI  / 

"svn list -v" column alignment issue

[Vincent Lefevre]

Hi,

There's something wrong with "svn list -v" column alignment when
there are author names with more than 8 characters. For instance,
with the gcc repository:

[...]
 279442 jozeflDec 16 12:02 libgcc/
 278886 jvdelisle  Dec 01 23:29 libgfortran/
[...]

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svn commit: r1871827 - /subversion/trunk/subversion/bindings/swig/python/tests/client.py

[Daniel Shahaf]

Yasuhito FUTATSUKI wrote on Fri, 20 Dec 2019 13:31 +00:00:
> I found that nb->shelved_func() in this line is 
> svn_swig_py_client_status_func() on swig Python bindings, and it is
> incorrectly implemented that it isn't return value (i.e. void type).
> This should be svn_client_status_func_t, which returns svn_error_t *.

Should some of these fixes be backported to 1.13.x?

Cheers,

Daniel

Re: Handling of unexpectedly changed kind, accepting local changes in versioning changes by external forces

[Stefan Sperling]

On Fri, Dec 20, 2019 at 07:19:27PM +0100, Dr. Thomas Orgis wrote:
> Please let's avoid the discussion whether one should version config
> files of the actual servers or the pupped/ansible/… scripts that
> generate them and just consider that
> 
> 1. a directory tree on a live system is versioned in a Subversion
>repository,
> 2. various automated processes (package manager) modify that directory
>tree, and
> 3. Subversion is tripped up by nodes changing their kind from/to
>symbolic link, plain file, directory.
> 
> I do have a script that looks at `svn st` and adds/removes files
> to turn ! into D, ? into A, basically. A mythical `svn synctree`
> command might do that, too, in a safer way.

There is a work-in-progress branch for such a feature:
https://svn.apache.org/viewvc/subversion/branches/addremove/
Would you be interested in working on this?

At present it doesn't implement much more than a wrapper around
'svn status' could do, mapping '!' to 'D' and '?' to 'A' status.

I intended to work on an ad-hoc rename detection feature for this
branch, like Git would do it. But I ran out of time.
Regardless, if this feature branch also solved the symlink issue you
describe below, the branch might already be worth merging to trunk.

> If a file in the working copy is replaced by a symlink, as
> reorganizations on Linux distribution upgrades make it happen, svn
> refuses the commit:
> 
> svn: E145001: Commit failed (details follow):
> svn: E145001: Node '...' has unexpectedly changed kind
> 
> Now, this can be worked around by moving the changed file/link aside,
> telling svn to forget about it, then move back and re-add. Commit. Like
> this example (out of one of the attached scripts that demonstrate the
> issue and resolution in some variations of changes in kind:
> 
> # Known state to svn:
> echo a > a
> echo b > b
> svn add a b
> svn commit -m 'created two test files'
> 
> # The set up:
> echo "The world happens and switches a for a symlink to b."
> rm a
> ln -s b a

Technically, SVN expects tree modifications to be made with
Subversion commands like 'svn add', 'svn rm' etc. Modifying
the working copy's tree structure with external commands is
actually somewhat "out of spec".

> This message of unexpected kind can be frustrating for the user that
> for sure can see that the erstwhile file is a symlink now and is
> wishing for a concise command that tells svn to just accept that fact.

I agree that it would be nice to make this case easier to deal with.

> (not too much thought on line breaks in file names). Of course it would
> be nice if there was the option to version ownership and permission
> info, too (not sure if extended attributes should be relevant for
> configuration). I faintly remember a project that built on svn to
> version whole filesystems including special/device files, but cannot
> find it right now.

Are you aware of 'asvn'?
https://svn.apache.org/viewvc/subversion/trunk/contrib/client-side/asvn?revision=1295006=markup

Handling of unexpectedly changed kind, accepting local changes in versioning changes by external forces

[Dr. Thomas Orgis]

Hi,

it was suggested to me to discuss Subversion behaviour that is causing
me some nuisance while versioning configuration files, namely the /etc
dir of Linux servers. It may be smarter to just check in the files I
edit (I do that on some), but there is some convenience in telling svn
to just accept whatever an (automated) update did to a directory as
new state. Some semantic info gets lost (files being copied/moved around)
without the content fixation that git uses to derive such things, but I
prefer Subversion for such a task, as it more closely follows the idea
of a directory tree, including treating empty directories as valid
objects.

Please let's avoid the discussion whether one should version config
files of the actual servers or the pupped/ansible/… scripts that
generate them and just consider that

1. a directory tree on a live system is versioned in a Subversion
   repository,
2. various automated processes (package manager) modify that directory
   tree, and
3. Subversion is tripped up by nodes changing their kind from/to
   symbolic link, plain file, directory.

I do have a script that looks at `svn st` and adds/removes files
to turn ! into D, ? into A, basically. A mythical `svn synctree`
command might do that, too, in a safer way.

If a file in the working copy is replaced by a symlink, as
reorganizations on Linux distribution upgrades make it happen, svn
refuses the commit:

svn: E145001: Commit failed (details follow):
svn: E145001: Node '...' has unexpectedly changed kind

Now, this can be worked around by moving the changed file/link aside,
telling svn to forget about it, then move back and re-add. Commit. Like
this example (out of one of the attached scripts that demonstrate the
issue and resolution in some variations of changes in kind:

# Known state to svn:
echo a > a
echo b > b
svn add a b
svn commit -m 'created two test files'

# The set up:
echo "The world happens and switches a for a symlink to b."
rm a
ln -s b a

# The workaround:
echo "Workaround: move around, remove, add."
tmp=$(mktemp a.)
mv a "$tmp"
svn rm a
mv "$tmp" a
svn add a
svn commit -m "Now a is a symlink to b in the repo."


Any thoughts on how svn could be made fitter/adaptible to a scenariro
where $anything can happen to the working copy and one just wants it to
make sense out of the current state?

This message of unexpected kind can be frustrating for the user that
for sure can see that the erstwhile file is a symlink now and is
wishing for a concise command that tells svn to just accept that fact.

At the very least, it would be nice to be able to resolve the
situation without having to delete/move the actual file (here or in
another working copy as a crutch). Just tell subversion to update it's
metadata with respect to this file. If it is a change in kind, I guess
it would be fine if the internal workings would be equivalent to `svn rm`
and `svn add`.

Comments? Suggeststions? Solutions?


Alrighty then,

Thomas


PS: Of course, as a backup/restore solution, svn on /etc is not
perfect, with it not bothering with file ownership and detailed
permissions. That can be handled by versioning the output of

find "$@" -print0 \
| sort -z | xargs -0 stat -c '%a %u:%g %U:%G %n'

(not too much thought on line breaks in file names). Of course it would
be nice if there was the option to version ownership and permission
info, too (not sure if extended attributes should be relevant for
configuration). I faintly remember a project that built on svn to
version whole filesystems including special/device files, but cannot
find it right now. I still do think that exploiting the file system
metaphor of svn provides the niche for it to continue to exist besides
the all-mighty git.

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg


dirfile.sh
Description: application/shellscript


dirfileback.sh
Description: application/shellscript


dirlink.sh
Description: application/shellscript


dirlinkback.sh
Description: application/shellscript


dirlinkback2.sh
Description: application/shellscript


filelink.sh
Description: application/shellscript

Re: svn commit: r1871827 - /subversion/trunk/subversion/bindings/swig/python/tests/client.py

[Stefan Sperling]

On Fri, Dec 20, 2019 at 11:30:05PM +0900, Yasuhito FUTATSUKI wrote:
> On 2019/12/20 22:31, Yasuhito FUTATSUKI wrote:
>  
> > I found that nb->shelved_func() in this line is 
> > svn_swig_py_client_status_func() on swig Python bindings, and it is
> > incorrectly implemented that it isn't return value (i.e. void type).
> > This should be svn_client_status_func_t, which returns svn_error_t *.
> > 
> > I'll fix it.
> 
> Done in r1871861, and waiting for result of Builder svn-bb-openbsd
> Build #465. We can see the result about 15 hours later.

I expect it will succeed. I have done a quick check on OpenBSD/amd64
and all swig-py tests pass now.

Thank you!

Re: svn commit: r1871827 - /subversion/trunk/subversion/bindings/swig/python/tests/client.py

[Yasuhito FUTATSUKI]

On 2019/12/20 22:31, Yasuhito FUTATSUKI wrote:
 
> I found that nb->shelved_func() in this line is 
> svn_swig_py_client_status_func() on swig Python bindings, and it is
> incorrectly implemented that it isn't return value (i.e. void type).
> This should be svn_client_status_func_t, which returns svn_error_t *.
> 
> I'll fix it.

Done in r1871861, and waiting for result of Builder svn-bb-openbsd
Build #465. We can see the result about 15 hours later.

Cheers,
-- 
Yasuhito FUTATSUKI  / 

Re: svn commit: r1871827 - /subversion/trunk/subversion/bindings/swig/python/tests/client.py

[Yasuhito FUTATSUKI]

On 2019/12/20 21:11, Stefan Sperling wrote:
> On Fri, Dec 20, 2019 at 08:47:38PM +0900, Yasuhito FUTATSUKI wrote:
>> And then, another problem has been occurred ... in 
>> SubversionClientTestCase.test_shelf(). I'll take a look.
>>
>> https://ci.apache.org/builders/svn-bb-openbsd/builds/464/steps/Test%20bindings/logs/testlog-swig-py
> 
> This the corresponding backtrace:

Thank you for your quick responce.

> GNU gdb (GDB) 7.12.1
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "sparc64-unknown-openbsd6.6".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from prefix/python/bin/python3.7...done.
> [New process 320142]
> Core was generated by `python3.7'.
> ---Type  to continue, or q  to quit---
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x008b06198990 in svn_error_clear (err=0x3) at 
> subversion/libsvn_subr/error.c:492
> 492   while (err->child)
> (gdb) bt
> #0  0x008b06198990 in svn_error_clear (err=0x3) at 
> subversion/libsvn_subr/error.c:492
> #1  0x008ae29164e4 in shelf_save_notifier (baton=0xfffcb1f0, 
> notify=0x8ad236ef00, pool=0x8ac9069d00)
> at subversion/libsvn_client/shelf.c:1075

I found that nb->shelved_func() in this line is 
svn_swig_py_client_status_func() on swig Python bindings, and it is
incorrectly implemented that it isn't return value (i.e. void type).
This should be svn_client_status_func_t, which returns svn_error_t *.

I'll fix it.

Cheers,
-- 
Yasuhito FUTATSUKI  / 

Re: svn commit: r1871827 - /subversion/trunk/subversion/bindings/swig/python/tests/client.py

[Stefan Sperling]

On Fri, Dec 20, 2019 at 08:47:38PM +0900, Yasuhito FUTATSUKI wrote:
> And then, another problem has been occurred ... in 
> SubversionClientTestCase.test_shelf(). I'll take a look.
> 
> https://ci.apache.org/builders/svn-bb-openbsd/builds/464/steps/Test%20bindings/logs/testlog-swig-py

This the corresponding backtrace:

GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc64-unknown-openbsd6.6".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from prefix/python/bin/python3.7...done.
[New process 320142]
Core was generated by `python3.7'.
---Type  to continue, or q  to quit---
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x008b06198990 in svn_error_clear (err=0x3) at 
subversion/libsvn_subr/error.c:492
492   while (err->child)
(gdb) bt
#0  0x008b06198990 in svn_error_clear (err=0x3) at 
subversion/libsvn_subr/error.c:492
#1  0x008ae29164e4 in shelf_save_notifier (baton=0xfffcb1f0, 
notify=0x8ad236ef00, pool=0x8ac9069d00)
at subversion/libsvn_client/shelf.c:1075
#2  0x008ae286356c in do_item_commit (dir_baton=0xfffcab78, 
editor=0x8a9f912300, edit_baton=0x8a6349ca00,
parent_baton=0x8a86541820, callback_baton=0xfffcae48, 
path=0x8a17084aa0 "trunk/new-shelf-test.txt", pool=0x8ac9069d00)
at subversion/libsvn_client/commit_util.c:1676
#3  0x008a3d95d098 in svn_delta_path_driver_step (state=0x8a98f7a600, 
relpath=0x8a17084aa0 "trunk/new-shelf-test.txt",
scratch_pool=0x8ad236e600) at subversion/libsvn_delta/path_driver.c:325
#4  0x008a3d95c95c in svn_delta_path_driver3 (editor=0x8a9f912300, 
edit_baton=0x8a6349ca00, relpaths=0x8b04399400, sort_paths=1,
callback_func=0x8ae2862e74 , 
callback_baton=0xfffcae48, pool=0x8af673d000)
at subversion/libsvn_delta/path_driver.c:190
#5  0x008ae28640f8 in svn_client__do_commit (base_url=0x8a94f5d0c0 
"file:///tmp/tmpeirdbbhh-client", commit_items=0x8a94f5c4a0,
editor=0x8a9f912300, edit_baton=0x8a6349ca00, notify_path_prefix=0x0, 
sha1_checksums=0x0, ctx=0x8a5a639318,
result_pool=0x8af673d000, scratch_pool=0x8af673d000) at 
subversion/libsvn_client/commit_util.c:1903
#6  0x008ae285d76c in svn_client__wc_replay (src_wc_abspath=0x8b04398a40 
"/tmp/tmpxlkngb34-shelf", targets=0x8b04398e80,
depth=svn_depth_unknown, changelists=0x0, editor=0x8a9f912300, 
edit_baton=0x8a6349ca00,
notify_func=0x8ae2916460 , 
notify_baton=0xfffcb1f0, ctx=0x8a5a639318, pool=0x8af673d000)
at subversion/libsvn_client/commit.c:617
#7  0x008ae291676c in svn_client__shelf_save_new_version3 
(new_version_p=0xfffcb3f8, shelf=0x8a4329e440,
paths=0x8b04398e80, depth=svn_depth_unknown, changelists=0x0, 
shelved_func=0x8ae8a93760 ,
shelved_baton=0x8a3a4a4220, not_shelved_func=0x8ae8a93760 
,
not_shelved_baton=0x8a7acfb5d0 <_Py_NoneStruct>, scratch_pool=0x8af673d000) 
at subversion/libsvn_client/shelf.c:1114
#8  0x008a6f0955bc in _wrap_svn_client__shelf_save_new_version3 
(self=0x8a907a6c20, args=0x8a3b718e20)
at subversion/bindings/swig/python/svn_client.c:33350
#9  0x008a7a747e30 in cfunction_call_varargs (kwargs=, 
args=, func=)
at /var/buildslave/svn-bb-openbsd/src/Python-3.7.5/Objects/call.c:772
#10 PyCFunction_Call (func=0x8ac66e5b20, args=0x8a3b718e20, kwargs=0x0)
at /var/buildslave/svn-bb-openbsd/src/Python-3.7.5/Objects/call.c:788
#11 0x008a7a81f898 in do_call_core (kwdict=, 
callargs=, func=)
at /var/buildslave/svn-bb-openbsd/src/Python-3.7.5/Python/ceval.c:4641
#12 _PyEval_EvalFrameDefault (f=0x8a908d7e20, throwflag=)
at /var/buildslave/svn-bb-openbsd/src/Python-3.7.5/Python/ceval.c:3191
#13 0x008a7a814ab4 in PyEval_EvalFrameEx (f=0x8a908d7e20, throwflag=0)
---Type  to continue, or q  to quit---
at /var/buildslave/svn-bb-openbsd/src/Python-3.7.5/Python/ceval.c:547
#14 0x008a7a81670c in _PyEval_EvalCodeWithName (_co=0x8a99406100, 
globals=0x8a8bdabda0, locals=0x0, args=0x8ac9d22e30,
argcount=7, kwnames=0x0, kwargs=0x8ac9d22e30, kwcount=0, kwstep=0, 
defs=0x0, defcount=0, kwdefs=0x0, closure=0x0,
name=0x8a3a907e80, qualname=0x8a3a907e80) at 
/var/buildslave/svn-bb-openbsd/src/Python-3.7.5/Python/ceval.c:3930
#15 0x008a7a7478d8 in _PyFunction_FastCallKeywords (func=, 
stack=0x8a7a7478d0 <_PyFunction_FastCallKeywords+208>,
nargs=0, kwnames=0x0) at 

Re: svn commit: r1871827 - /subversion/trunk/subversion/bindings/swig/python/tests/client.py

[Yasuhito FUTATSUKI]

On 2019/12/20 19:22, Yasuhito FUTATSUKI wrote:
> On 2019/12/20 18:40, Stefan Sperling wrote:
>> On Thu, Dec 19, 2019 at 08:51:31PM -, futat...@apache.org wrote:
>>> Author: futatuki
>>> Date: Thu Dec 19 20:51:31 2019
>>> New Revision: 1871827
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1871827=rev
>>> Log:
>>> Fix pool life time bug on test_log5_revprops test case in swig-py.
>>
>> Nice thank you!
>>
>> How did you manage to reproduce this problem?
>> I didn't even post a trace from my core file yet :-)
> 
> I counted dots before 'Bus error' in testlog-swig-py, determined
> where it happend, then read the code :)
> 
> So I didn't test the committed code on the environment where the 
> problem occured. I'm watching the result of svn-bb-openbsd Build #464.

And then, another problem has been occurred ... in 
SubversionClientTestCase.test_shelf(). I'll take a look.

https://ci.apache.org/builders/svn-bb-openbsd/builds/464/steps/Test%20bindings/logs/testlog-swig-py

Cheers,
-- 
Yasuhito FUTATSUKI 

Re: svn commit: r1871827 - /subversion/trunk/subversion/bindings/swig/python/tests/client.py

[Yasuhito FUTATSUKI]

On 2019/12/20 18:40, Stefan Sperling wrote:
> On Thu, Dec 19, 2019 at 08:51:31PM -, futat...@apache.org wrote:
>> Author: futatuki
>> Date: Thu Dec 19 20:51:31 2019
>> New Revision: 1871827
>>
>> URL: http://svn.apache.org/viewvc?rev=1871827=rev
>> Log:
>> Fix pool life time bug on test_log5_revprops test case in swig-py.
> 
> Nice thank you!
> 
> How did you manage to reproduce this problem?
> I didn't even post a trace from my core file yet :-)

I counted dots before 'Bus error' in testlog-swig-py, determined
where it happend, then read the code :)

So I didn't test the committed code on the environment where the 
problem occured. I'm watching the result of svn-bb-openbsd Build #464.

Cheers,
-- 
Yasuhito FUTATSUKI  / 

Re: svn commit: r1871827 - /subversion/trunk/subversion/bindings/swig/python/tests/client.py

[Stefan Sperling]

On Thu, Dec 19, 2019 at 08:51:31PM -, futat...@apache.org wrote:
> Author: futatuki
> Date: Thu Dec 19 20:51:31 2019
> New Revision: 1871827
> 
> URL: http://svn.apache.org/viewvc?rev=1871827=rev
> Log:
> Fix pool life time bug on test_log5_revprops test case in swig-py.

Nice thank you!

How did you manage to reproduce this problem?
I didn't even post a trace from my core file yet :-)