You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "钱海远 (Nathan)" <qi...@hikvision.com> on 2020/03/21 06:08:55 UTC
Svnadmin dump with include will lost the svn:log in sometime
Dear sir,
I hope everything is fine.
I found the there is a BUG in subversion 1.10.6.
Svnadmin dump with include will lost the svn:log in sometime.
I was fix this issue several months ago , I forgot how to the issue happened again. But I have a patch to fix this issue, the code was lost the processing for SVN_PROP_REVISION_LOG.
If there is no svn:log in the dump file , the load will be fail.
Best Regards!
Haiyuan Qian
R & D Management Group
Hangzhou Hikvision Digital Technology Co.,Ltd
No.555 Qianmo Road, Binjiang District, Hangzhou 310052, China
M (86)18969199712
本邮件及其附件含有海康威视公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HIKVISION, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
________________________________
CONFIDENTIALITY NOTICE: This electronic message is intended to be viewed only by the individual or entity to whom it is addressed. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, or if you have received this communication in error, please notify us immediately by return e-mail and delete the original message and any copies of it from your computer system. For further information about Hikvision company. please see our website at www.hikvision.com<http://www.hikvision.com>
答复: Svnadmin dump with include will lost the svn:log in sometime
Posted by "钱海远 (Nathan)" <qi...@hikvision.com>.
Thankyou. Waiting for your good news.
Best Regards!
Haiyuan Qian
R & D Management Group
Hangzhou Hikvision Digital Technology Co.,Ltd
No.555 Qianmo Road, Binjiang District, Hangzhou 310052, China
M (86)18969199712
本邮件及其附件含有海康威视公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HIKVISION, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
-----邮件原件-----
发件人: Daniel Shahaf <d....@daniel.shahaf.name>
发送时间: 2020年3月23日 14:25
收件人: 钱海远(Nathan) <qi...@hikvision.com>
抄送: users@subversion.apache.org
主题: Re: Svnadmin dump with include will lost the svn:log in sometime
钱海远(Nathan) wrote on Mon, 23 Mar 2020 05:56 +0000:
> The version is 1.10.6 , I was try to reproduce this issue.
>
> You can make a commit like this :
> Revision 1
> A /test
> A /Test/a.c
> A /another
> A /another/b.c
>
> Revision 2
> M /test/a.c
> M /another/b.c
>
> Then run command : svnadmin dump svnroot include "/test"
>
> Then it will happen.
Thanks, I can reproduce this with current trunk:
[[[
% svnadmin create r
% svnmucc -U file://$PWD/r mkdir foo mkdir bar put =(:) foo/iota put =(:) bar/kappa -mm % svnadmin dump r --include=/foo | grep -B1 -A2 svn:log
* Dumped revision 0.
* Dumped revision 1.
% svnadmin dump r | grep -B1 -A2 svn:log
* Dumped revision 0.
K 7
svn:log
V 1
m
* Dumped revision 1.
%
]]]
I agree it makes sense to keep the log message, at least as an option.
I'll reopen SVN-4850 in a minute.
As to the cause, I stand corrected: it's indeed due to authz, exactly as you said:
[[[
(lldb) n
Process 24108 stopped
* thread #1, name = 'svnadmin', stop reason = step over
frame #0: 0x00007ffff7f9ba21 libsvn_repos-1.so.0`svn_repos_fs_revision_proplist(table_p=0x00007fffffffdd80, repos=0x00007ffff7deb4c0, rev=1, authz_read_func=(libsvn_repos-1.so.0`dump_filter_authz_func at dump.c:2010), authz_read_baton=0x00007fffffffdf50, pool=0x00007ffff66a7028) at fs-wrap.c:514
511 authz_read_func, authz_read_baton,
512 pool));
513
-> 514 if (readability == svn_repos_revision_access_none)
515 {
516 /* Return an empty hash. */
517 *table_p = apr_hash_make(pool);
(lldb) p readability
(svn_repos_revision_access_level_t) $0 = svn_repos_revision_access_partial ]]]
authz was set up internally by svn_repos_dump_fs4():
[[[
2083 /* We use read authz callback to implement dump filtering. If there is no
2084 * read access for some node, it will be excluded from dump as well as
2085 * references to it (e.g. copy source). */
2086 if (filter_func)
2087 {
2088 authz_func = dump_filter_authz_func;
2089 authz_baton.filter_func = filter_func;
2090 authz_baton.filter_baton = filter_baton;
2091 }
2092 else
2093 {
2094 authz_func = NULL;
2095 }
]]]
Nevertheless, we can't just make svn_repos_fs_revision_proplist() include svn:log; that would make svnserve and mod_dav_svn expose information that currently they do not.
I'm not sure what the easiest way to fix this is…
Cheers,
Daniel
________________________________
CONFIDENTIALITY NOTICE: This electronic message is intended to be viewed only by the individual or entity to whom it is addressed. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, or if you have received this communication in error, please notify us immediately by return e-mail and delete the original message and any copies of it from your computer system. For further information about Hikvision company. please see our website at www.hikvision.com<http://www.hikvision.com>
Re: Svnadmin dump with include will lost the svn:log in sometime
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
钱海远(Nathan) wrote on Mon, 23 Mar 2020 05:56 +0000:
> The version is 1.10.6 , I was try to reproduce this issue.
>
> You can make a commit like this :
> Revision 1
> A /test
> A /Test/a.c
> A /another
> A /another/b.c
>
> Revision 2
> M /test/a.c
> M /another/b.c
>
> Then run command : svnadmin dump svnroot include "/test"
>
> Then it will happen.
Thanks, I can reproduce this with current trunk:
[[[
% svnadmin create r
% svnmucc -U file://$PWD/r mkdir foo mkdir bar put =(:) foo/iota put =(:) bar/kappa -mm
% svnadmin dump r --include=/foo | grep -B1 -A2 svn:log
* Dumped revision 0.
* Dumped revision 1.
% svnadmin dump r | grep -B1 -A2 svn:log
* Dumped revision 0.
K 7
svn:log
V 1
m
* Dumped revision 1.
%
]]]
I agree it makes sense to keep the log message, at least as an option.
I'll reopen SVN-4850 in a minute.
As to the cause, I stand corrected: it's indeed due to authz, exactly as
you said:
[[[
(lldb) n
Process 24108 stopped
* thread #1, name = 'svnadmin', stop reason = step over
frame #0: 0x00007ffff7f9ba21 libsvn_repos-1.so.0`svn_repos_fs_revision_proplist(table_p=0x00007fffffffdd80, repos=0x00007ffff7deb4c0, rev=1, authz_read_func=(libsvn_repos-1.so.0`dump_filter_authz_func at dump.c:2010), authz_read_baton=0x00007fffffffdf50, pool=0x00007ffff66a7028) at fs-wrap.c:514
511 authz_read_func, authz_read_baton,
512 pool));
513
-> 514 if (readability == svn_repos_revision_access_none)
515 {
516 /* Return an empty hash. */
517 *table_p = apr_hash_make(pool);
(lldb) p readability
(svn_repos_revision_access_level_t) $0 = svn_repos_revision_access_partial
]]]
authz was set up internally by svn_repos_dump_fs4():
[[[
2083 /* We use read authz callback to implement dump filtering. If there is no
2084 * read access for some node, it will be excluded from dump as well as
2085 * references to it (e.g. copy source). */
2086 if (filter_func)
2087 {
2088 authz_func = dump_filter_authz_func;
2089 authz_baton.filter_func = filter_func;
2090 authz_baton.filter_baton = filter_baton;
2091 }
2092 else
2093 {
2094 authz_func = NULL;
2095 }
]]]
Nevertheless, we can't just make svn_repos_fs_revision_proplist()
include svn:log; that would make svnserve and mod_dav_svn expose
information that currently they do not.
I'm not sure what the easiest way to fix this is…
Cheers,
Daniel
答复: Svnadmin dump with include will lost the svn:log in sometime
Posted by "钱海远 (Nathan)" <qi...@hikvision.com>.
The version is 1.10.6 , I was try to reproduce this issue.
You can make a commit like this :
Revision 1
A /test
A /Test/a.c
A /another
A /another/b.c
Revision 2
M /test/a.c
M /another/b.c
Then run command : svnadmin dump svnroot include "/test"
Then it will happen.
Best Regards!
Haiyuan Qian
R & D Management Group
Hangzhou Hikvision Digital Technology Co.,Ltd
No.555 Qianmo Road, Binjiang District, Hangzhou 310052, China
M (86)18969199712
本邮件及其附件含有海康威视公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HIKVISION, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
-----邮件原件-----
发件人: Daniel Shahaf <d....@daniel.shahaf.name>
发送时间: 2020年3月23日 13:46
收件人: 钱海远(Nathan) <qi...@hikvision.com>
抄送: users@subversion.apache.org
主题: Re: Svnadmin dump with include will lost the svn:log in sometime
钱海远(Nathan) wrote on Mon, 23 Mar 2020 05:30 +0000:
> The expected behaviour is: 'svnadmin dump' should include all properties.
>
> It happened in command : svnadmin dump --include .
>
> I organized the calling relationship of the function:
I can't reproduce that:
[[[
% lldb -- svnadmin dump r --include=/foo ⋮
(lldb) n
Process 10902 stopped
* thread #1, name = 'svnadmin', stop reason = step over
frame #0: 0x00007ffff7d9ba71 libsvn_repos-1.so.0`svn_repos_fs_revision_proplist(table_p=0x00007fffffffddf8, repos=0x00007ffff765b4c0, rev=0, authz_read_func=(libsvn_repos-1.so.0`dump_filter_authz_func at dump.c:1997), authz_read_baton=0x00007fffffffdf70, pool=0x00007ffff54b6028) at fs-wrap.c:514
511 authz_read_func, authz_read_baton,
512 pool));
513
-> 514 if (readability == svn_repos_revision_access_none)
515 {
516 /* Return an empty hash. */
517 *table_p = apr_hash_make(pool);
(lldb) p readability
(svn_repos_revision_access_level_t) $1 = svn_repos_revision_access_full ]]]
The value svn_repos_revision_access_full is correct, and indicates that the line you patched won't be executed.
FWIW, the backtrace at that point:
[[[
(lldb) bt
* thread #1, name = 'svnadmin', stop reason = step over
* frame #0: 0x00007ffff7d9ba71 libsvn_repos-1.so.0`svn_repos_fs_revision_proplist(table_p=0x00007fffffffddf8, repos=0x00007ffff765b4c0, rev=0, authz_read_func=(libsvn_repos-1.so.0`dump_filter_authz_func at dump.c:1997), authz_read_baton=0x00007fffffffdf70, pool=0x00007ffff54b6028) at fs-wrap.c:514
frame #1: 0x00007ffff7d93633 libsvn_repos-1.so.0`write_revision_record(stream=0x00007ffff54afbe0, repos=0x00007ffff765b4c0, rev=0, include_revprops=1, authz_func=(libsvn_repos-1.so.0`dump_filter_authz_func at dump.c:1997), authz_baton=0x00007fffffffdf70, pool=0x00007ffff54b6028) at dump.c:1967
frame #2: 0x00007ffff7d92fd2 libsvn_repos-1.so.0`svn_repos_dump_fs4(repos=0x00007ffff765b4c0, stream=0x00007ffff54afbe0, start_rev=0, end_rev=0, incremental=0, use_deltas=0, include_revprops=1, include_changes=1, notify_func=(svnadmin`repos_notify_handler at svnadmin.c:1055), notify_baton=0x00007ffff54afc48, filter_func=(svnadmin`dump_filter_func at svnadmin.c:1402), filter_baton=0x00007fffffffe128, cancel_func=(libsvn_subr-1.so.0`check_cancel at cmdline.c:1659), cancel_baton=0x0000000000000000, pool=0x00007ffff765b028) at dump.c:2116
frame #3: 0x0000000000406892 svnadmin`subcommand_dump(os=0x00007ffff765b188, baton=0x00007fffffffe3d8, pool=0x00007ffff765b028) at svnadmin.c:1468
frame #4: 0x00000000004052d2 svnadmin`sub_main(exit_code=0x00007fffffffe524, argc=4, argv=0x00007fffffffe628, pool=0x00007ffff765b028) at svnadmin.c:3314
frame #5: 0x0000000000403d02 svnadmin`main(argc=4, argv=0x00007fffffffe628) at svnadmin.c:3347
frame #6: 0x00007ffff743209b libc.so.6`__libc_start_main(main=(svnadmin`main at svnadmin.c:3333), argc=4, argv=0x00007fffffffe628, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffe618) at libc-start.c:308
frame #7: 0x0000000000403bba svnadmin`_start + 42
(lldb)
]]]
That's with 1.13. I don't have 1.10 handy; however, I expect the same is true in 1.10.
> I was very sure this will make a malformed dump when it work with include.
I expect the dump will load successfully, but TIAS.
Daniel
>
> Best Regards!
> Haiyuan Qian
> R & D Management Group
> Hangzhou Hikvision Digital Technology Co.,Ltd
> No.555 Qianmo Road, Binjiang District, Hangzhou 310052, China M
> (86)18969199712
>
> 本邮件及其附件含有海康威视公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露
> 、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from HIKVISION, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
>
>
> -----邮件原件-----
> 发件人: Daniel Shahaf <d....@daniel.shahaf.name>
> 发送时间: 2020年3月22日 1:04
> 收件人: 钱海远(Nathan) <qi...@hikvision.com>
> 抄送: users@subversion.apache.org
> 主题: Re: Svnadmin dump with include will lost the svn:log in sometime
>
> 钱海远(Nathan) wrote on Sat, 21 Mar 2020 06:08 +0000:
> > I found the there is a BUG in subversion 1.10.6.
> >
> > Svnadmin dump with include will lost the svn:log in sometime.
> >
> > I was fix this issue several months ago , I forgot how to the issue happened again. But I have a patch to fix this issue, the code was lost the processing for SVN_PROP_REVISION_LOG.
> >
> > If there is no svn:log in the dump file , the load will be fail.
>
> Let's take these issues one at a time. The expected behaviour is:
>
> 1. 'svnadmin dump' should include all properties.
>
> 2. 'svnadmin load' should succeed even when svn:log is missing.
>
> Now, to your patch. First of all, the patch shouldn't affect
> svnadmin's behaviour in any way, because svnadmin doesn't enter the
> codepath your
> changed: that codepath is only used when authz is in effect, and svnadmin never does authz. (That's how #1 is implemented.) Did you perchance run 'svnrdump dump' instead? That'd explain why your patch had an effect.
>
> Next, omitting svn:log in the svn_repos_revision_partial_access case is not a bug; it's deliberately this way.
>
> If you can reproduce a case in which either #1 or #2 don't hold, that would be a bug. However, given that your patch had an effect, you are probably using some tool other than svnadmin. So, please quote the command lines you entered and the error messages they generated.
>
> ________________________________
> CONFIDENTIALITY NOTICE: This electronic message is intended to be
> viewed only by the individual or entity to whom it is addressed. It
> may contain information that is privileged, confidential and exempt
> from disclosure under applicable law. Any dissemination, distribution
> or copying of this communication is strictly prohibited without our
> prior permission. If the reader of this message is not the intended
> recipient, or the employee or agent responsible for delivering the
> message to the intended recipient, or if you have received this
> communication in error, please notify us immediately by return e-mail
> and delete the original message and any copies of it from your
> computer system. For further information about Hikvision company.
> please see our website at www.hikvision.com<http://www.hikvision.com>
>
________________________________
CONFIDENTIALITY NOTICE: This electronic message is intended to be viewed only by the individual or entity to whom it is addressed. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, or if you have received this communication in error, please notify us immediately by return e-mail and delete the original message and any copies of it from your computer system. For further information about Hikvision company. please see our website at www.hikvision.com<http://www.hikvision.com>
Re: Svnadmin dump with include will lost the svn:log in sometime
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Mon, 23 Mar 2020 05:45 +0000:
> 钱海远(Nathan) wrote on Mon, 23 Mar 2020 05:30 +0000:
> > The expected behaviour is: 'svnadmin dump' should include all properties.
> >
> > It happened in command : svnadmin dump --include .
> >
> > I organized the calling relationship of the function:
>
> I can't reproduce that:
>
> [[[
> % lldb -- svnadmin dump r --include=/foo
> ⋮
> (lldb) n
> Process 10902 stopped
> * thread #1, name = 'svnadmin', stop reason = step over
> frame #0: 0x00007ffff7d9ba71 libsvn_repos-1.so.0`svn_repos_fs_revision_proplist(table_p=0x00007fffffffddf8, repos=0x00007ffff765b4c0, rev=0, authz_read_func=(libsvn_repos-1.so.0`dump_filter_authz_func at dump.c:1997), authz_read_baton=0x00007fffffffdf70, pool=0x00007ffff54b6028) at fs-wrap.c:514
> 511 authz_read_func, authz_read_baton,
> 512 pool));
> 513
> -> 514 if (readability == svn_repos_revision_access_none)
> 515 {
> 516 /* Return an empty hash. */
> 517 *table_p = apr_hash_make(pool);
> (lldb) p readability
> (svn_repos_revision_access_level_t) $1 = svn_repos_revision_access_full
> ]]]
>
> The value svn_repos_revision_access_full is correct, and indicates that
> the line you patched won't be executed.
>
It also indicates that all properties on the revision will be included
in the dumpfile.
However, note that nothing guarantees that svn:log exists for every
revision in the repository. You can check with «svnlook propget --revprop
-r N $REPOS_PATH svn:log».
Note that «svnlook log» does NOT error on revisions that don't have
svn:log set. (This seems to be a bug.)
Re: Svnadmin dump with include will lost the svn:log in sometime
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
钱海远(Nathan) wrote on Mon, 23 Mar 2020 05:30 +0000:
> The expected behaviour is: 'svnadmin dump' should include all properties.
>
> It happened in command : svnadmin dump --include .
>
> I organized the calling relationship of the function:
I can't reproduce that:
[[[
% lldb -- svnadmin dump r --include=/foo
⋮
(lldb) n
Process 10902 stopped
* thread #1, name = 'svnadmin', stop reason = step over
frame #0: 0x00007ffff7d9ba71 libsvn_repos-1.so.0`svn_repos_fs_revision_proplist(table_p=0x00007fffffffddf8, repos=0x00007ffff765b4c0, rev=0, authz_read_func=(libsvn_repos-1.so.0`dump_filter_authz_func at dump.c:1997), authz_read_baton=0x00007fffffffdf70, pool=0x00007ffff54b6028) at fs-wrap.c:514
511 authz_read_func, authz_read_baton,
512 pool));
513
-> 514 if (readability == svn_repos_revision_access_none)
515 {
516 /* Return an empty hash. */
517 *table_p = apr_hash_make(pool);
(lldb) p readability
(svn_repos_revision_access_level_t) $1 = svn_repos_revision_access_full
]]]
The value svn_repos_revision_access_full is correct, and indicates that
the line you patched won't be executed.
FWIW, the backtrace at that point:
[[[
(lldb) bt
* thread #1, name = 'svnadmin', stop reason = step over
* frame #0: 0x00007ffff7d9ba71 libsvn_repos-1.so.0`svn_repos_fs_revision_proplist(table_p=0x00007fffffffddf8, repos=0x00007ffff765b4c0, rev=0, authz_read_func=(libsvn_repos-1.so.0`dump_filter_authz_func at dump.c:1997), authz_read_baton=0x00007fffffffdf70, pool=0x00007ffff54b6028) at fs-wrap.c:514
frame #1: 0x00007ffff7d93633 libsvn_repos-1.so.0`write_revision_record(stream=0x00007ffff54afbe0, repos=0x00007ffff765b4c0, rev=0, include_revprops=1, authz_func=(libsvn_repos-1.so.0`dump_filter_authz_func at dump.c:1997), authz_baton=0x00007fffffffdf70, pool=0x00007ffff54b6028) at dump.c:1967
frame #2: 0x00007ffff7d92fd2 libsvn_repos-1.so.0`svn_repos_dump_fs4(repos=0x00007ffff765b4c0, stream=0x00007ffff54afbe0, start_rev=0, end_rev=0, incremental=0, use_deltas=0, include_revprops=1, include_changes=1, notify_func=(svnadmin`repos_notify_handler at svnadmin.c:1055), notify_baton=0x00007ffff54afc48, filter_func=(svnadmin`dump_filter_func at svnadmin.c:1402), filter_baton=0x00007fffffffe128, cancel_func=(libsvn_subr-1.so.0`check_cancel at cmdline.c:1659), cancel_baton=0x0000000000000000, pool=0x00007ffff765b028) at dump.c:2116
frame #3: 0x0000000000406892 svnadmin`subcommand_dump(os=0x00007ffff765b188, baton=0x00007fffffffe3d8, pool=0x00007ffff765b028) at svnadmin.c:1468
frame #4: 0x00000000004052d2 svnadmin`sub_main(exit_code=0x00007fffffffe524, argc=4, argv=0x00007fffffffe628, pool=0x00007ffff765b028) at svnadmin.c:3314
frame #5: 0x0000000000403d02 svnadmin`main(argc=4, argv=0x00007fffffffe628) at svnadmin.c:3347
frame #6: 0x00007ffff743209b libc.so.6`__libc_start_main(main=(svnadmin`main at svnadmin.c:3333), argc=4, argv=0x00007fffffffe628, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffe618) at libc-start.c:308
frame #7: 0x0000000000403bba svnadmin`_start + 42
(lldb)
]]]
That's with 1.13. I don't have 1.10 handy; however, I expect the
same is true in 1.10.
> I was very sure this will make a malformed dump when it work with include.
I expect the dump will load successfully, but TIAS.
Daniel
>
> Best Regards!
> Haiyuan Qian
> R & D Management Group
> Hangzhou Hikvision Digital Technology Co.,Ltd
> No.555 Qianmo Road, Binjiang District, Hangzhou 310052, China
> M (86)18969199712
>
> 本邮件及其附件含有海康威视公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from HIKVISION, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
>
>
> -----邮件原件-----
> 发件人: Daniel Shahaf <d....@daniel.shahaf.name>
> 发送时间: 2020年3月22日 1:04
> 收件人: 钱海远(Nathan) <qi...@hikvision.com>
> 抄送: users@subversion.apache.org
> 主题: Re: Svnadmin dump with include will lost the svn:log in sometime
>
> 钱海远(Nathan) wrote on Sat, 21 Mar 2020 06:08 +0000:
> > I found the there is a BUG in subversion 1.10.6.
> >
> > Svnadmin dump with include will lost the svn:log in sometime.
> >
> > I was fix this issue several months ago , I forgot how to the issue happened again. But I have a patch to fix this issue, the code was lost the processing for SVN_PROP_REVISION_LOG.
> >
> > If there is no svn:log in the dump file , the load will be fail.
>
> Let's take these issues one at a time. The expected behaviour is:
>
> 1. 'svnadmin dump' should include all properties.
>
> 2. 'svnadmin load' should succeed even when svn:log is missing.
>
> Now, to your patch. First of all, the patch shouldn't affect svnadmin's behaviour in any way, because svnadmin doesn't enter the codepath your
> changed: that codepath is only used when authz is in effect, and svnadmin never does authz. (That's how #1 is implemented.) Did you perchance run 'svnrdump dump' instead? That'd explain why your patch had an effect.
>
> Next, omitting svn:log in the svn_repos_revision_partial_access case is not a bug; it's deliberately this way.
>
> If you can reproduce a case in which either #1 or #2 don't hold, that would be a bug. However, given that your patch had an effect, you are probably using some tool other than svnadmin. So, please quote the command lines you entered and the error messages they generated.
>
> ________________________________
> CONFIDENTIALITY NOTICE: This electronic message is intended to be viewed only by the individual or entity to whom it is addressed. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, or if you have received this communication in error, please notify us immediately by return e-mail and delete the original message and any copies of it from your computer system. For further information about Hikvision company. please see our website at www.hikvision.com<http://www.hikvision.com>
>
答复: Svnadmin dump with include will lost the svn:log in sometime
Posted by "钱海远 (Nathan)" <qi...@hikvision.com>.
Hi, Daniel ,
The expected behaviour is: 'svnadmin dump' should include all properties.
It happened in command : svnadmin dump --include . I was very sure this will make a malformed dump when it work with include.
I organized the calling relationship of the function:
1. svnadmin.c
static svn_error_t *
subcommand_dump(apr_getopt_t *os, void *baton, apr_pool_t *pool)
{
...
SVN_ERR(svn_repos_dump_fs4(repos, out_stream, lower, upper,
opt_state->incremental, opt_state->use_deltas,
TRUE, TRUE,
!opt_state->quiet ? repos_notify_handler : NULL,
feedback_stream,
filter_baton.prefixes ? dump_filter_func : NULL,
&filter_baton,
check_cancel, NULL, pool));
...
}
2. dump.c
line 2003 svn_repos_dump_fs4
line 2109 write_revision_record
line 1945 svn_repos_fs_revision_proplist
{
...
if (include_revprops)
{
SVN_ERR(svn_repos_fs_revision_proplist(&props, repos, rev,
authz_func, authz_baton, pool));
...
}
3. fs-wrap.c
svn_error_t *
svn_repos_fs_revision_proplist(apr_hash_t **table_p,
svn_repos_t *repos,
svn_revnum_t rev,
svn_repos_authz_func_t authz_read_func,
void *authz_read_baton,
apr_pool_t *pool)
{
....in this case.
}
Best Regards!
Haiyuan Qian
R & D Management Group
Hangzhou Hikvision Digital Technology Co.,Ltd
No.555 Qianmo Road, Binjiang District, Hangzhou 310052, China
M (86)18969199712
本邮件及其附件含有海康威视公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HIKVISION, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
-----邮件原件-----
发件人: Daniel Shahaf <d....@daniel.shahaf.name>
发送时间: 2020年3月22日 1:04
收件人: 钱海远(Nathan) <qi...@hikvision.com>
抄送: users@subversion.apache.org
主题: Re: Svnadmin dump with include will lost the svn:log in sometime
钱海远(Nathan) wrote on Sat, 21 Mar 2020 06:08 +0000:
> I found the there is a BUG in subversion 1.10.6.
>
> Svnadmin dump with include will lost the svn:log in sometime.
>
> I was fix this issue several months ago , I forgot how to the issue happened again. But I have a patch to fix this issue, the code was lost the processing for SVN_PROP_REVISION_LOG.
>
> If there is no svn:log in the dump file , the load will be fail.
Let's take these issues one at a time. The expected behaviour is:
1. 'svnadmin dump' should include all properties.
2. 'svnadmin load' should succeed even when svn:log is missing.
Now, to your patch. First of all, the patch shouldn't affect svnadmin's behaviour in any way, because svnadmin doesn't enter the codepath your
changed: that codepath is only used when authz is in effect, and svnadmin never does authz. (That's how #1 is implemented.) Did you perchance run 'svnrdump dump' instead? That'd explain why your patch had an effect.
Next, omitting svn:log in the svn_repos_revision_partial_access case is not a bug; it's deliberately this way.
If you can reproduce a case in which either #1 or #2 don't hold, that would be a bug. However, given that your patch had an effect, you are probably using some tool other than svnadmin. So, please quote the command lines you entered and the error messages they generated.
________________________________
CONFIDENTIALITY NOTICE: This electronic message is intended to be viewed only by the individual or entity to whom it is addressed. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, or if you have received this communication in error, please notify us immediately by return e-mail and delete the original message and any copies of it from your computer system. For further information about Hikvision company. please see our website at www.hikvision.com<http://www.hikvision.com>
Re: Svnadmin dump with include will lost the svn:log in sometime
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
钱海远(Nathan) wrote on Sat, 21 Mar 2020 06:08 +0000:
> I found the there is a BUG in subversion 1.10.6.
>
> Svnadmin dump with include will lost the svn:log in sometime.
>
> I was fix this issue several months ago , I forgot how to the issue happened again. But I have a patch to fix this issue, the code was lost the processing for SVN_PROP_REVISION_LOG.
>
> If there is no svn:log in the dump file , the load will be fail.
Let's take these issues one at a time. The expected behaviour is:
1. 'svnadmin dump' should include all properties.
2. 'svnadmin load' should succeed even when svn:log is missing.
Now, to your patch. First of all, the patch shouldn't affect svnadmin's
behaviour in any way, because svnadmin doesn't enter the codepath your
changed: that codepath is only used when authz is in effect, and
svnadmin never does authz. (That's how #1 is implemented.) Did you
perchance run 'svnrdump dump' instead? That'd explain why your patch
had an effect.
Next, omitting svn:log in the svn_repos_revision_partial_access case is
not a bug; it's deliberately this way.
If you can reproduce a case in which either #1 or #2 don't hold, that
would be a bug. However, given that your patch had an effect, you are
probably using some tool other than svnadmin. So, please quote the
command lines you entered and the error messages they generated.