答复: Subversion 2.0

[Nathan]

Dear Develop Team,

We have created a system for pre-commit review in  our company (Force Review, 
or pre-commit hooks will reject commit), as shown below.

But SVN does not support staging code area. Can it be developed in 2.0?

If we can have a staging area, we can build pre-commit action simple , such as 
pre-commit builds, check the quality of the code before it is committed. Now we 
are also implementing it in a similar way like FR , code consistency is 
difficult to judge, and user’s operation are complex.


[cid:image001.png@01D54632.FAD83480]


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!

发件人: Nathan Hartman 
发送时间: 2019年7月3日 0:41
收件人: Markus Schaber 
抄送: Thomas Singer ; Subversion Developers 

主题: Re: Subversion 2.0

On Fri, Jun 28, 2019 at 12:51 PM Markus Schaber 
mailto:m.scha...@codesys.com>> wrote:
It's a very powerful feature, on par or even superior to other (D)VCSes - as 
long as we manage to keep the interface clear enough that users can handle 
everything.

I'm always astonished how complicated GIT can be for seemingly "simple" tasks, 
and even the available GUIs are not always helpful. HG is doing a much better 
job here, as far as I can see...

It stand and falls with the user interface.

And we should take it seriously from the beginning. When the new features are 
implemented with unusable/complex UI first, users will want to try it, fail, 
and turn away. We won't be able to catch them later when the UI is better...

I agree. A bad user interface will result in complaints that repeat
around the Internet in perpetuity, even after the problems are fixed.
I think we know this from experience! Also, once the interface gets
"grandfathered in," it can't / won't change because of compatibility.

I'm studying this issue and I'll be back with some concrete
suggestions; in the meantime I'd love to hear your thoughts as well!
Especially use cases. :-)



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 can not dump the subdir into add when it's parent path was a branch

[Nathan]

Yes, I think so. It's just for include. It's not a very good patch, I think , 
sorry for this .

And it has a known issue , it will include the parent node path , this is a 
problem. I made another program to delete parent node.


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 
发送时间: 2020年3月22日 1:35
收件人: 钱海远(Nathan) 
抄送: us...@subversion.apache.org; dev@subversion.apache.org
主题: Re: Svnadmin dump with include can not dump the subdir into add when it's 
parent path was a branch

[moving to dev@; please remove users@ from replies]

钱海远(Nathan) wrote on Sat, 21 Mar 2020 06:12 +:
> I found the there is a BUG in subversion 1.10.6.
>
> Svnadmin dump with include can not dump the subdir into add when it's parent 
> path was a branch:
> 1. 1、/A was copy from/XX , revision was 50, it the first revision of /A; 2. 
> 2、There is a subdir named /A/subdir, and several files and dir under 
> /A/subdir; 3. 3、Try to run “svnadmin dump /data/repos_root  --include 
> /A/subdir >a” . The expected dump file will include /A/subdir(revision 50) 
> into add. But in fact there was nothing.
> 4. 4、I was try to fix this bug in the svnadmin.c  , a function named 
> ary_prefix_match. If the change list is the parent dir for include path, it 
> return true. Then the dump file will include /A/subdir and it's subdir or 
> subfile into add , but regrettably, the dump file will also include /A into 
> add.

钱海远(Nathan) wrote on Sat, 21 Mar 2020 06:12 +:
> --- C:/Users/QIANHA~1/AppData/Local/Temp/svnadmin.c-rev30397.svn001.tmp.c 
>  25 11:51:32 2020
> +++ C:/Users/QIANHA~1/AppData/Local/Temp/svnadmin.c-rev30398.svn000.tmp.c 
>  21 12:58:58 2020
> @@ -1297,3 +1297,3 @@ ary_prefix_match(const apr_array_header_t *pfxlist
> -  if (path_len < pfx_len)
> -continue;
> -  if (strncmp(path, pfx, pfx_len) == 0
> +  /*if (path_len < pfx_len)
> +continue;*/
> +  if ((strncmp(path, pfx, pfx_len) == 0
> @@ -1300,0 +1301,3 @@ ary_prefix_match(const apr_array_header_t
> *pfxlist
> +|| (strncmp(pfx,path, path_len) == 0
> +  && (path_len == 1 || path[path_len] == '\0' || path[path_len] == 
> '/'))
> +)

Thanks for the patch.  I don't see any obvious problems with this approach.  
However, the patch as it stands causes a regression:

[[[
W: /home/daniel/src/svn/t1/./subversion/libsvn_repos/load.c:667,
W: /home/daniel/src/svn/t1/./subversion/libsvn_repos/load-fs-vtable.c:718,
W: /home/daniel/src/svn/t1/./subversion/libsvn_repos/load-fs-vtable.c:591,
W: /home/daniel/src/svn/t1/./subversion/libsvn_fs/fs-loader.c:1482,
W: /home/daniel/src/svn/t1/./subversion/libsvn_fs_fs/tree.c:2524,
W: /home/daniel/src/svn/t1/./subversion/libsvn_fs_fs/tree.c:1145: 
(apr_err=SVN_ERR_FS_NOT_FOUND)
W: svnadmin: E160013: File not found: transaction '0-0', path '/A/B/F'
W: CWD: /tmp/svn/subversion/tests/cmdline
W: EXCEPTION: Failure: Command failed: "/tmp/svn/subversion/svnadmin/svnadmin 
load --quiet svn-test-work/repositories/svnadmin_tests-60-1"; exit code 1 
Traceback (most recent call last):
  File "/home/daniel/src/svn/t1/subversion/tests/cmdline/svntest/main.py", line 
1931, in run
rc = self.pred.run(sandbox)
  File "/home/daniel/src/svn/t1/subversion/tests/cmdline/svntest/testcase.py", 
line 178, in run
result = self.func(sandbox)
  File "/home/daniel/src/svn/t1/subversion/tests/cmdline/svnadmin_tests.py", 
line 3510, in dump_exclude
load_and_verify_dumpstream(sbox2, None, [], None, False, dump)
  File "/home/daniel/src/svn/t1/subversion/tests/cmdline/svnadmin_tests.py", 
line 304, in load_and_verify_dumpstream
'load', '--quiet', sbox.repo_dir, *varargs)
  File "/home/daniel/src/svn/t1/subversion/tests/cmdline/svntest/main.py", line 
666, in run_command_stdin
'"; exit code ' + str(exit_code))
svntest.Failure: Command failed: "/tmp/svn/subversion/svnadmin/svnadmin load 
--quiet svn-test-work/repositories/svnadmin_tests-60-1"; exit code 1

A patch of svnlook subcommand search

[Nathan]

Dear Sir,



I made a subcommand search for Subversion.



In recent years, we have produced an subversion online web system (like 
Gitlab). At the earliest time, we use " svn ls -R | grep " 
command to package a search webservice. But it's too slow and lost a lot of 
CPUs, and also svn command need user login in to check authority , Cann’t be 
made into an interface function by webservice.



This Patch can search node with authority, also you can define how many node to 
found and how many node to match. Also can without authority.



I want to contribute this code to the community, I don’t know if it is needed?



Best Regards!

Nathan 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>



svnlook search
Description: svnlook search

[Repair] Replay: A patch of svnlook subcommand search

[Nathan]

Sorry, lost the function strstri.


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!

发件人: 钱海远(Nathan)
发送时间: 2020年4月8日 14:33
收件人: 'dev@subversion.apache.org' 
主题: A patch of svnlook subcommand search


Dear Sir,



I made a subcommand search for Subversion.



In recent years, we have produced an subversion online web system (like 
Gitlab). At the earliest time, we use " svn ls -R | grep " 
command to package a search webservice. But it's too slow and lost a lot of 
CPUs, and also svn command need user login in to check authority , Cann’t be 
made into an interface function by webservice.



This Patch can search node with authority, also you can define how many node to 
found and how many node to match. Also can without authority.



I want to contribute this code to the community, I don’t know if it is needed?



Best Regards!

Nathan 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>



svnlook search
Description: svnlook search

Svnmucc sensitive to order of mkdir

[Nathan]

Dear all,

I was discuss with Daniel Shahaf about the 
Issue: https://issues.apache.org/jira/browse/SVN-4854

SVN 1.10.6 change the svnmucc , it’s sensitive with mkdir operations, if a want 
to mkdir /foot/bar when /foot is not exists , svnmucc only can work with 
svnmucc mkdir ‘/foor’ mkdir ‘/foot/bar’ . Cannot work with svnmucc mkdir 
‘/foot/bar’ mkdir ‘/foot’. But it’s both success with 1.8.15 version.

Daniel Shahaf told me the new subversion is much more sensitive to order of 
operation.

So, can we set the option --parent with svnmucc mkdir?


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

svn_fs_node_id causes memory leak...

[Nathan]

Dear Sir,

I found that svn_fs_node_id causes memory leak. I had report the issue in jira: 
https://issues.apache.org/jira/browse/SVN-4907?jql=project%20%3D%20SVN

Daniel Shahaf need some more info :

Q: Can you attach a code sample that we can compile and run ourselves and 
reproduces the problem?
A: The demo code : 
https://issues.apache.org/jira/secure/attachment/13048592/svntest.c

Q: Does this reproduce in 1.14.x?
A: Yes , I checked it will happened in 1.14.x.

Q: What's the output of `svnadmin info` on the repository in question?
A: Repository info (a new empty repository ):

Path: /data1/svnroot/09test
UUID: 8509fe00-280b-11ed-ad61-4168499269e9
Revisions: 0
Repository Format: 5
Compatible With Version: 1.10.0
Repository Capability: mergeinfo
Filesystem Type: fsfs
Filesystem Format: 8
FSFS Sharded: yes
FSFS Shard Size: 1000
FSFS Shards Packed: 0/0
FSFS Logical Addressing: yes
Configuration File: /data1/svnroot/09test/db/fsfs.conf

Q: What's the the memory on average per call after N calls? After 2N calls? 
(choose N)
A: the memory info:
1000 times call with existing path: 5020k
2000 times call with existing path: 5020k
1000 times call with non-existent path: 9664k
2000 times call with non-existent path: 13880k

Q: Are REV and ROOT the same every time?
A: Yes , Rev and ROOT are same.

Q: What's the caching configuration?
A: Default configuration.


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

答复: svn_fs_node_id causes memory leak...

[Nathan]

Yes, when I was free svn_error_t's pool , no memory leak.

Why svn_error_t create a new memory pool , not use pool ?

  svn_error_t *err = svn_fs_node_id(id, *root, *path_relative, pool);
  if(err != SVN_NO_ERROR || !id )
  {
if(err != SVN_NO_ERROR)
  svn_pool_destroy(err->pool);


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!

-邮件原件-
发件人: Yasuhito FUTATSUKI 
发送时间: 2022年8月31日 0:52
收件人: 钱海远(Nathan) ; Subversion Developers 

主题: Re: svn_fs_node_id causes memory leak...

Hello,

On 2022/08/30 11:33, 钱海远(Nathan) wrote:
> Dear Sir,
>
> I found that svn_fs_node_id causes memory leak. I had report the issue
> in jira:
> https://issues.apache.org/jira/browse/SVN-4907?jql=project%20%3D%20SVN
>
> Daniel Shahaf need some more info :
>
> Q: Can you attach a code sample that we can compile and run ourselves and 
> reproduces the problem?
> A: The demo code :
> https://issues.apache.org/jira/secure/attachment/13048592/svntest.c

[[[
...
  if ((svn_fs_node_id(id, *root, *path_relative, pool)) != SVN_NO_ERROR || 
!(*id))
{
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;
...
]]]

If a return value of svn_fs_node_id() is not SVN_NO_ERROR, it is an svn_error_t 
object which was allocated from global pool, and it should be cleared by 
svn_error_clear(). Otherwise it causes memory leak.

I think the problem is not svn_fs_node_id() (in this case it is actually 
svn_fs_fs__id_node_id()) itself but how use it.

Cheers,
--
Yasuhito FUTATSUKI 



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>

svn_uri_is_canonical(url, pool) 1.7.3

[Nathan Stiles]

I received the following from my tortoise svn 64bit whilt trying to
checkout from my local visual svn server 2.5.2.
In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.3\ext\subversion\subversion\libsvn_client\checkout.c'
 line 94: assertion failed (svn_uri_is_canonical(url, pool))

So this is win7 64 bit professional

the original uri i tried to use was "localhost:8443/svn/RepoName"
and thats what threw the error

So then I try "https://computername:8443/svn/RepoName"; and I don't receive
the error.

Best of luck on this I'm not subscribed to this list so if this is useful
and someone needs additional information please email me directly.

Also thank you for SVN everyone who has contributed I really find it's a
beautiful system.

Re: [RFC] Shelving and Checkpointing

[Nathan Hartman]

On Jul 10, 2017, at 8:59 AM, Julian Foad  wrote:
> 
> Dear Subversion Developers,
> 
> I am delighted to announce that I am working with Assembla to develop
> shelving and checkpointing functionality in Subversion. These have
> been on the wish list for many years, and are becoming ever more in
> demand since the popularity of git is making more users appreciate the
> benefits of local operations.

Hi all,

I just wanted to chime in and say that I'm very happy to hear that these local 
features are planned for Subversion. After ten years of using Subversion, I can 
say that it has been a joy to use from day one, owing in large part to its 
simplicity and reliability.

It occurred to me recently that in the distant past Subversion's purpose was to 
be a better CVS, that that goal has been achieved long ago, and that perhaps 
it's time for a Subversion 2.0, which could take it to the next level. I don't 
know much about future plans, such as what FSX is intended to achieve, but it 
occurred to me that perhaps Subversion could gain the ability to do local 
commits, which could be an optional step before doing the real commit back to 
the repository. As I thought about that, I realized that it might not have to 
require too much new machinery to achieve that.

I had this idea: When you checkout a working copy, Subversion creates the 
hidden .svn directory which contains the pristine copies among other things. 
What if, instead of just a pristine copy, it actually created a private local 
repository. Revision 1 of this repository would be the pristine copy. The user 
need not know that anything has changed and can continue working as before, 
committing back to the server. But, if you type some other command instead of 
commit, or maybe prepend the word "local" or something, the commit would go 
into the local repository rather than the remote one. Now this makes it 
possible to do locally anything you could do remotely such as creating multiple 
local feature branches. It also means that when you do an update, there could 
be an implied local commit first, which allows you to undo an update which 
perhaps messed something up. Shelving, stashing, etc., all become local 
operations against this local souped up pristine copy replacement.

Since you're only checking out one revision just as before, as opposed to 
cloning a whole repository, this idea comes with some big advantages that you 
don't get with git or hg, such as that you need not clone an entire gigantic 
repository. This is one of the big reasons that those systems are not a good 
choice for housing lots of big files that change infrequently, as every user 
would have to clone potentially gigabytes of data they're not interested in. In 
other words a svn checkout still does what it always did before, except that 
you have the option to work locally if you want to.

I didn't mention any of this before because:

(1) there are obviously a lot of holes in this idea, such as, what happens to 
this private local repo when you do a svn switch? Or the pesky issue of how to 
add such a major new feature without inheriting a ton of obscure commands a la 
git?

And (2) although I am a developer and very fond of Subversion, I cannot take 
this upon myself because of other obligations now and in the foreseeable 
future. So I felt it would be rude to dump a crazy idea like this on everyone 
else. Julian's post prompted me to break my silence, not knowing if what I've 
suggested is remotely realistic.

I realize that this suggests a major backwards-incompatible change to the 
working copy format and indeed the entire client side. But this was a request 
for comment. :-) Hopefully someone finds my input valuable.

Kind regards,
Nathan 

> References:
>   [1] Shelving-Checkpointing Dev doc. (J Foad)
> https://docs.google.com/document/d/1PVgw0BdPF7v67oxIK7B_Yjmr3p28ojabP5N1PfZTsHk/edit#

Re: [RFC] Shelving and Checkpointing

[Nathan Hartman]

On Tue, Jul 11, 2017 at 4:53 AM, Julian Foad  wrote:

> Nathan Hartman wrote:
>
>> [...] What if, instead of just a pristine copy, it actually created a
>> private local repository. Revision 1 of this repository would be the
>> pristine copy. [...]
>>
>
> That is exactly what I was thinking about when I wrote "Option 3...
> Checkpoints are commits in a local repository embedded in the WC" towards
> the end of that document. My feeling is that both the amount of effort
> required just to get that far, and the explosion of further possibilities
> it would open up, make it too heavy-weight for my current project, but I
> would definitely like to explore that possibility further.


The explosion of possibilities, to borrow your words, is IMO a disadvantage
of Option 3. I'm saying this despite having suggested this same idea.

I'd like to emphasize that I don't advocate turning Subversion into a DVCS.
Proponents of DVCSs seem to think that Subversion's centralized nature is a
disadvantage. I think the exact opposite. With centralized, you get Single
Source of Truth, a system that is easy to learn, easy to teach, programmers
and non programmers can use it successfully. I like that history is
immutable, never rewritten, because I think the primary responsibility is
to never lose information. You only have two places to know about: the
repository and your working copy.

What I do like is the idea of remaining centralized while having some local
capabilities. The stashing / checkpointing wishlist items are valid. I
mentioned the ability to roll back a svn update if something unexpected
happens (by doing an implied local commit of your current state as the
first step of svn update). Local feature branches could be useful for
one-off experiments, short-lived work done by one person, etc. In any case,
these features should all be optional. They'd be there if you want them,
but you never have to know about them if you're not interested.

In any event, I wouldn't go full blown DVCS where the concept of repository
vs. working copy goes away. I wouldn't turn a checkout into a full clone,
or a working copy into a repository.

Other than the addition of new features in the client, all else would
remain the same.

Why put a hidden repository in the working copy, then? The reason is that
while the client could use a different "lighter weight" method to manage
various versions of its working copy, that would reinvent the wheel. You'd
end up with a second incompatible version control system within Subversion.
If I understand correctly, the client already has server code in it,
because when you use the file:// URL scheme, the client is the server. So
why reinvent a new version control system within Subversion when it already
has everything it needs?

But here's the key: The difference between a normal repository and the
hidden one in the working copy is that the latter is a hidden
implementation detail, not something the user can access or control. For
example you can't checkout a working copy of it. Everything that concerns
that hidden repo, its creation, the directory and file layout within it...
all of that is controlled by Subversion itself. It's more of an internal
client-side filing system than an actual repository, although it uses a
repository as the underlying implementation. The user gets some new local
features, but not the dreaded "explosion of possibilities."

Kind regards,
Nathan

Re: [RFC] Shelving and Checkpointing

[Nathan Hartman]

On Fri, Jul 14, 2017 at 7:56 AM, Julian Foad  wrote:
> Diffing checkpoints is quite hard (well, needs a patch-arithmetic library) in 
> this design. Even just determining whether two patches are "identical". That 
> might be a good reason for me to try the alternative design "store 
> checkpoints in a local repository" ("option 3") next.

My thinking is that options 1 or 2 will eventually grow into a redundant 
implementation of a VCS within svn to handle various revisions of the working 
copy. That will most likely be faster to get off the ground, but results in 
redundant code, or refactoring existing code to do the patch arithmetic, etc. 
Option 3 requires reinventing the client outright but gives more flexibility in 
the long run.

I was thinking that svn switch needs to be handled, or chaos would ensue if 
someone does some work, makes some shelves and checkpoints, and then does svn 
switch to a different path. A solution could be to remember the checkout path 
and revision with each shelve/checkpoint. If the user performs svn switch and 
later wants to reinstate a shelved working copy, the client will notice that it 
can't be unshelved until the workspace is switched back to the correct path and 
error out with a descriptive message. The user will then svn switch to the 
correct branch and reissue the unshelve command. The normal rules apply, which 
mean that if there are uncommitted changes in the working copy, the user will 
have to either commit them or shelve them before performing the svn switch. A 
--force option could allow the user to unshelve the work into the wrong path, 
possibly with conflicts (but maybe this is intentional).

>> 
>>> References:
>>>[1] Shelving-Checkpointing Dev doc. (J Foad)
>>> https://docs.google.com/document/d/1PVgw0BdPF7v67oxIK7B_Yjmr3p28ojabP5N1PfZTsHk/edit#
>>>  

Re: Checkpointing mock-up option 3 (backed by a local repo)

[Nathan Hartman]

On Wed, Jul 26, 2017 at 11:13 AM, Julian Foad  wrote:

> I committed an initial prototype for checkpointing backed by a local
> repo embedded in the WC (the "option 3" design), on the
> "shelve-checkpoint3" branch.
>
> http://svn.apache.org/r1803046 and follow-ups.
>

Woohoo! Very exciting!

I didn't quite understand the difference between uninit and finish, but
that's okay. I'll re-read more carefully soon. More important to try it.
I'll be back with thoughts...

Re: Checkpointing mock-up option 3 (backed by a local repo)

[Nathan Hartman]

On Thu, Jul 27, 2017 at 7:56 AM, Julian Foad  wrote:

> What can we learn from this mock-up? Here are some of my thoughts

(snip)

> If I checkpoint my changes, do I then want to see 'status' and 'diff'
>
against the original base or against the checkpoint? Both are useful.
>
(snip)

> Probably 'checkpoint init' should not be needed, and instead running
> 'checkpoint save' should initialize the checkpointing repo if not
> already done.
>
> Probably 'checkpoint finish|uninit' should not be needed, and instead
> should happen automatically when the user either commits or reverts the
> entire set of changes.
>

Some thoughts (probably too many)...

I agree that 'init' and 'finish' should happen automatically. Creation and
destruction of a hidden repository (or any data structure) is an
implementation detail that could change in the future and should not be
leaked. As you've already said, the 'init' should occur the first time a
checkpoint operation is done. As for when the 'finish' should occur, that
is a question I've been grappling with... I would say, probably not until
the results have been squashed and committed.

As far as what to name the commands, if the "checkpoint" command is changed
to "local" and the "save" subcommand is changed to "commit" then you get:

1. svn local commit
2. svn local revert
3. svn local rollback
4. svn local list|log
5. svn local squash
6. svn commit   <--- to the central repository

I think users will immediately start getting ideas about what this means.
Is that a good thing? It depends on what the goals are for checkpoints, how
checkpoints are intended to fit into the larger workflow, and strategy for
the future in general.

If checkpoints are intended to be merely a convenience with a limited
purpose, then I would call the command "checkpoint" and "checkpoint save"
to avoid confusion and make documentation, teaching, and learning easier.

If checkpoints are intended to have a much wider application, eventually
providing an answer to git's/DVCSs' ability to work offline and/or to do
personal work on projects to which one lacks commit privileges, then I
would use the shorter "local" (unless someone can think of a better,
shorter, and more descriptive name) and try to keep the sub-sub-commands as
close in semantics and function as possible to Subversion's original
command set. Even though the word "local" is technically a command, we
pretend it's more of a mode specifier that redirects what would normally be
server side operations to the local machine instead. Working on the local
machine essentially means working on a private branch. With that in mind,
to answer questions such as: whether a status or diff should be against the
original base or against the checkpoint, such questions should always be
answered consistently with how server side operations are carried out
today. Of course, if this feature is supposed to have such broad scope,
there is the (not insignificant) issue that users will have immediate
sky-high expectations that will take significant additional time and effort
to fulfill, so clearly this is not by any means an immediate goal; it's a
*possible* future direction, and if that kind of future appeals to enough
people, then the present work should try to be compatible with that future
by maintaining (to the extent possible) such a parallel between this new
"local branching" and the original server-side branching.

Some more thoughts...

(1) It will eventually be necessary to create a new "URL specifier" or some
sort of syntax to direct an operation into the checkpoint repo. This will
make it possible to diff between any permutation of working copy, central
repository, and local checkpoints, which will be crucial once users begin
to use checkpoints as local branches. I can see a use case where a 3-way
diff between all three is useful.

(2) Once checkpoints are working reliably, I suggest that "svn update"
should perform an automatic implicit "checkpoint save" (or whatever the
command is called) before attempting to fetch from the repository and merge
with the working copy. This will add a big safety net to what can be a
dreaded process. If an update turns ugly, you will be able to do that 3-way
diff I was just talking about.

(3) Eventually, squashing should be optional; that said, it's not feasible
to checkout a WC from a trunk that has lots of activity on it, work locally
for weeks, and then expect to replay the local commits onto the trunk
successfully. So I suggest this alternative: You can checkout a working
copy and make as many checkpoints as you want. When ready to commit, one of
the following happens:

(a) you squash, update, and commit (which will turn into an infinite
loop if item #1 above is implemented and update creates a checkpoint...
hmmm... not good)

(b) you can replay the commits to the server only if no other commits
have been made in the meantime (to trunk or whichever directory originates
the checkout)

(c) you do not wish to s

Re: Checkpointing mock-up option 3 (backed by a local repo)

[Nathan Hartman]

On Fri, Jul 28, 2017 at 8:19 AM, Julian Foad  wrote:

> Nathan Hartman wrote:
> All considered, it feels to me like we have neither the collective will
> nor the resources to take this in the direction of full local branching.
> I can't commit myself to that. The present work should strive to keep
> that option open, largely because a successful open-source software
> system is one that others can adapt to their needs later on.
>
> Rather, for me, this line of thought helps to clarify the differences
> between what we are and are not creating.
>

Agreed. Just to emphasize, I don't suggest going the route of full
local branching today. That involves challenges that require some
serious thought, not only implementation but also user perspective:
making it easy to learn and easy to use, like the rest of Subversion.


> > (2) [...] "svn update" should perform an automatic implicit
> > "checkpoint save" [...] If an update turns ugly, you will be able to do
> > that 3-way diff I was just talking about.
>
> Or you could revert the update. Yes, I would love to have this feature too.
>
> Performing an 'update' with a checkpoint series is a bigger ask than it
> might at first seem. In effect, it requires rebasing the series of
> checkpoints on the new base, which gets ugly because of the need to
> handle conflicts (which is ugly enough already in the existing
> single-depth WC).
>

Why does update with a checkpoint require rebasing? There must be a
large gap in my understanding here. Forgive me if I misunderstood, but
I thought a checkpoint is a snapshot of what the working copy looked
like at the time it was taken, to provide a sort of high-level
undo/redo capability. Suppose I did a checkout at 8:00 AM and then did
some work, taking snapshots of what my working copy looked like at
9:00 AM, 11:00 AM, and 2:00 PM. At 2:30 PM I invoke svn update. I
would expect to end up with four snapshots: 9:00 AM, 11:00 AM, 2:00
PM, 2:30 PM; and I would expect the working copy, after the update, to
be the same as though I checked out at 8:00 AM, worked until 2:30 PM,
and did the update, exactly as it occurs today. In other words, I
would expect my snapshots to remain untouched and I would expect the
update to be the "next step" in the working copy contents' linear
evolution. I could potentially continue working and taking snapshots,
and make subsequent updates as well. The implementation would probably
have to record the BASE at the time of each checkpoint, so that if you
rollback to it, passing through an "update" point, it could restore
that as the working copy's BASE along with restoring the working
copy's contents to those of the snapshot.


> Initially, I suggest 'update' and 'switch' will be incompatible with
> checkpoints. The user must first squash the checkpoints.
>

Agreed. This is reasonable for a first implementation.

As an enhancement, on running 'update', Subversion could 'squash' the
> checkpoints and shelve the resulting patch (but without reverting the
> WC). That would be enough to allow better manual 'undo' if the update
> went badly and if the user can remember the previous base state
> (revision/revisions). If the shelving function would also save a
> description of the base state, so much the better.
>

I don't like the idea of mixing checkpoints and updates with shelving.
It seems too kludgy to me because shelving is a way to temporarily
interrupt work and come back to it later, whereas updating is a linear
step forward, not an interruption. I propose this alternative: "svn
checkpoint squash" will in effect discard all checkpoints and take a
new checkpoint of the working copy. Following my earlier example of
four checkpoints, if I squash at 4:00 PM, I'll end up with just one
checkpoint with the 4:00 PM timestamp, identical to my working copy.
If "update" performs this squash operation (or simply takes a
checkpoint if none exists), then I believe it's a more logical
solution.


> > [...] I suggest ability to specify a log message [...]
>
> A log message option is intentionally omitted for now. My thinking is
> that specifying a log message reinforces the idea that each checkpoint
> commit will eventually become a central-repo commit, and with that in
> mind, the user's expectations would be a little different.


Fair enough. I'm in 100% agreement that this implementation should
focus on simplicity and reliability.

Re: [RFC] Using LZ4 compression by default

[Nathan Hartman]

On Aug 2, 2017, at 2:59 PM, Evgeny Kotkov  wrote:
> With the recently added support for LZ4 compression (r1801940 et al),
> we now have an option of using it by default for the on-disk data and
> over the wire.
> [...]
> The amount of the required additional space is proportional
> to the difference between the compression ratio of LZ4 and zlib-5,
> which can be roughly estimated as around 30-35% for compressible
> binary and text files, although that may vary depending on the
> actual data.
> 
> To illustrate how these changes will affect the speed of some of the
> operations, the 'svn import' of a 2 GB file over HTTP on LAN in my
> environment takes 18 seconds instead of 63 seconds.

Regarding on disk storage, for small repos a 30% size increase is probably not 
material, but it may be significant for large repos. Is it feasible to get the 
best of both worlds by using LZ4 for fast commits and then recompress using 
zlib in svnadmin pack?

Re: Checkpointing mock-up option 3 (backed by a local repo)

[Nathan Hartman]

On Tue, Aug 1, 2017 at 9:19 AM, Julian Foad  wrote:
> Keep in mind that a revision -- or any versioned state -- can be
> thought of in two ways: as a complete snapshot of the tree, or as
> representing a change relative to the previous snapshot.
>
> First let us be sure we understand that updating *is* rebasing. To
> explain this, think about a plain WC with no checkpointing. The WC
> has a base tree and a working tree. The work you do in a working copy
> is to create a change based on the base. An 'update' is a request to
> update the base and also to adjust the working version so that it
> represents the 'same' change that it previously did, except the
> change is now against the new base. Hence update is 'rebasing' your
> local change. The adjustment of the old change (against the old base)
> to a new change (against the new base) is accomplished by a merge.
>
> Illustration: a plain old WC based on r20 is like a one-commit local
> branch based on r20.
>
> [ repo -(r10)--(r20)--(r30)--(r40)---
> [||
> [||
> [ WC   (BASE)-(WORK)
>
> [(X) represents a tree snapshot. WORK means the working/on-disk state
> in the WC, including what libsvn_wc calls 'actual'.]
>
> Updating to r30 involves merging (r20:30) with (rBASE:WORK) to create
> (WORK'), and setting the new base to r30.
>
> [ repo -(r10)--(r20)--(r30)--(r40)---
> [   ||
> [   ||
> [ WC  (BASE')-(WORK')

I appreciate that you've taken the time and effort to explain this,
complete with graphs. I suppose I should have known that an update
rebases the working copy onto the new revision, but for whatever reason
I was under the impression that it was the other way around, that the
incoming changes get applied on top of the working copy.

The only drawback of the rebase is that update is a one-way operation,
with no 'undo' mechanism. It's the only place in Subversion where you
could potentially lose a very particular configuration of your files,
which may have taken some tricky manipulations to arrive at, and the
nature of update (being the action that immediately precedes a commit)
is such that your intention was probably to save those bits, not change
them. Currently in such a situation, the user should mitigate that by a
svn copy to a new branch, or adopt a policy of branching for everything
and avoid this issue altogether. Personally I've been known to copy the
contents of my working copy to a temp directory before performing an
update, just in case. :-) But the premise of version control is that
you should never fear losing anything. That makes update the perfect
use case and showcase for a checkpoint feature, even if the user never
takes advantage of checkpoints otherwise.

Referring to this last graph:

> (b) Keep the existing checkpoints based on the older base, and bring
> in the new base to be used only for new checkpoints. For this
> illustration, assume we had no outstanding working changes before
> running the update. We merge the incoming changes with the *complete*
> checkpoint series and record the result as (Pn').
>
> [ repo -(r10)--(r20)--(r30)--(r40)---
> [|| ||
> [|| ||
> [|  (P0)  (P0')
> [|\   \
> [ WC | \   \
> [|  \   \
> [| (P1)-...-(Pn)--(Pn'=BASE)
> [ \
> [  \_(WORK')
>
> The WC now contains two "base" snapshots (P0 and P0') copied from the
> repository, and (n) checkpoint snapshots, and a merged checkpoint.

If checkpoints are implemented using a hidden repo, is it feasible to
place two directories, BASE and WORK, at its root, and save the BASE
with each checkpoint? If so, Subversion's atomic repo-wide commits
would automatically solve the issue of keeping each checkpoint
synchronized with its base, since both would be saved together. The
repo's temporal compression would mean that very little additional data
would be saved, in comparison to the size of BASE.

If this is feasible, then I would treat checkpoints as a sort of time
line, rather than a private branch. That is, each action against the
checkpoints, whether to create a new checkpoint, perform an update, or
rollback to an earlier checkpoint, would create a new checkpoint with
the contents of the current BASE and WORK. So, rolling *back* (to an
earlier, in time, checkpoint) could actually roll your BASE *forward*.
The beauty is that since both BASE and WORK are saved in the hidden
repo, no server connection is needed to roll back or forward through
the point of a BASE change.

Here's an illustration of what might happen over the course of a
workday:

Time  | Action   | Hid

Re: Giving 1.10 alpha more exposure to gather feedback

[Nathan Hartman]

> On Aug 15, 2017, at 5:57 AM, Johan Corveleyn  wrote:
> 
> Can we try to give 1.10 alpha3 a bit more exposure, in order to gather
> more feedback? I'm thinking of:
> 

I assume alpha status means not for production use.
The question then is how to test effectively, in a manner that
is representative of real use
without excessive risk to data.

It may be helpful to include suggestions in the
aforementioned exposure.

Re: Giving 1.10 alpha more exposure to gather feedback

[Nathan Hartman]

On Aug 18, 2017, at 11:47 AM, Johan Corveleyn  wrote:
> 
> I agree a more integrated collaboration environment would a big plus.
> But ... how do we get there? Without losing our independence as an ASF
> project ...
> 
> Can we get there with ASF infrastructure? I doubt it. I've been
> looking around a bit. We have:
> - JIRA
> - ViewVC
> - Website (with FAQ)
> - MoinMoin wiki (pretty old-school layout)
> - Mailinglists (and archives)
> - Some projects use Nabble for a forum fronting their mailinglists
> (but they are sometimes plagued with spam)
> - Some projects use ReviewBoard: https://reviews.apache.org/r/
> - IRC (some projects also have channels on HipChat I think)

Is Redmine (redmine.org) a possibility? I've never used it but it looks 
interesting. I plan  to investigate it further for my own use. It has svn 
integration, though I know very little if anything about it at this time. Their 
own site probably looks like the stock install, though this page:

http://www.redmine.org/projects/redmine/wiki/WeAreUsingRedmine

lists projects that use Redmine. My favorite is this one, it's beautiful:

http://www.nightshadesoftware.org/projects/nightshade

I am not affiliated with any of the above. Just thought it's worth mentioning.

Re: Building Subversion.

[Nathan Hartman]

On Sep 14, 2017, at 7:36 AM, Paul Hammant  wrote:
> Generally, the Subversion project should depend less on the Redbean book. 
> http://svnbook.red-bean.com/en/1.8/index.html is about 1.8 and it's marked as 
> DRAFT. There's no 1.9 or 1.10. While it is great that Msssrs. 
> Collins-Sussman, Fitzpatrick and Pilato persuaded O'Reilly to allow a full 
> public HTML version of the same, the Subversion project itself needs some 
> independence.

Moving the Subversion project away from the Redbean book may only serve to 
discourage participation. Since the Redbean book is the only game in town and 
is a good resource, I think it needs more contributions, not competition, to 
help get it up to date. It's on my long to-do list to send in some patches and 
I'm hoping others will jump in too, particularly to write a chapter on some 
advanced real world usage scenarios, like workflow strategies to scale up a 
development team successfully and how to deal with complex merges. The rest of 
the book is great but this higher level knowledge isn't written down ANYWHERE, 
not in this book and not in any other book. It's top secret stuff locked away 
in a few people's heads and it needs to be written. 

Re: [RFC] Upgrade to C'90 as our minimum C language

[Nathan Hartman]

> On Sep 22, 2017, at 7:04 AM, Julian Foad  wrote:
> 
> I know there is a problem with Microsoft not supporting C'99. C'90
> should be fine though, and some of C'99 if we want to.
> 

Looks like this isn't going to happen but 
FWIW and just for others' reference, we 
compile an internal C99 library and its test 
suite on MSVC2008 among other platforms 
and compilers. The purpose is to run the test 
suite as many different ways as possible. It 
compiles, runs, and all tests pass 100%. The 
trick is to configure all the project's C files to 
compile as C++ despite their .c extension. 
This is because the C++ standard supported 
by MSVC contains the features (or at least 
the ones that affect us) that had been 
"backported" from C++ to C to form C99. 
There is also a project-wide global header 
that tests for various compilers and fixes 
things so they work. For example we had to 
define a macro that becomes "inline" under 
some compilers and __inline under MSVC, 
and I believe typedef the fixed-size int types 
(uint32_t and friends), among other things. 
But the point is that with some headache it 
can be made to work.

Re: Server-side SavePoints [was: Subversion Design Contribution Question]

[Nathan Hartman]

On Nov 2, 2017, at 9:49 PM, Daniel J. Lacks, PhD  wrote:
> 
> Hi Julian,
> 
> I appreciate your insight into thinking about the problem and your knowledge 
> of SVN is evident.  You are correct about my intentions, while it is possible 
> for the user to reuse commands (or scripts) to do such an operation (local or 
> remote), I was hoping that reuse made the SVN software development of a 
> capability easier to implement as an SVN command.  I am not against 
> client-side shelving or checkpoints, but I think that a server-side 
> capability is also useful.  I am in favor of both client-side AND server-side 
> stashing concepts, not necessarily only doing one or the other.  

Hi all,

I've been busy and haven't chimed in for some time about SavePoints (which were 
still called check points when I last participated in the discussion). First 
I'd like to say that I like the name SavePoints and agree with the rationale 
stated at the wiki, particularly that with this name, the command can be 
shortened to sp and that it will likely make more sense to non-native speakers 
of English than check points.

More to the point of this thread, I think the idea of client- and server-side 
SavePoints does make sense for the reasons stated previously. I like very much 
the idea that server side SavePoints could provide some of the underlying 
machinery for code review. I'd like to add the following to the list of 
potential use cases: Given the core svn library / third party value-added 
nature of Subversion, I can imagine a feature in, say, TortoiseSVN, where 
SavePoints are taken locally immediately, and when a line of communication to 
the server exists (which could be at the same time or at some later time) the 
SavePoints would be automatically transferred (copied / synched) to the server. 
That is, SavePoints are local and provide the ability to "work offline" for 
extended periods, but transparently become "online" at the next opportunity 
when communication permits. One could say that local SavePoints are 
transparently backed up to the server.

I think this would give users some very good benefits. For one, it would reduce 
or eliminate the need to remember to transfer SavePoints to the server 
manually. It would provide a safety net in case of loss of a WC, as occurs when 
a virtual machine goes haywire and the user deletes it with all its content and 
replaces it with a fresh VM and new checkout. (This has happened to me enough 
times!) It also answers a concern I have with anything that is local as opposed 
to server-side: my working copies are all in a RAM-disk! It speeds up builds 
and searches considerably, reduces wear on my laptop's flash storage, and 
enforces in my mind the idea that the working copy is very temporary and can be 
lost or damaged at any time--which encourages small frequent commits. So with 
the addition of local SavePoints, the concern is that if I'm in a RAM-based 
working copy, the SavePoints are no more durable than the working copy itself. 
But if the SavePoints are synchronized to the server, either manually or 
automatically / transparently, then I can continue to work happily in my 
RAM-disk while reaping the benefits of SavePoints and the safety of centralized 
version control.

Hopefully these thoughts are beneficial to the community.

Kind regards,
Nathan 

Re: Let's switch to time-based releases

[Nathan Hartman]

On Dec 1, 2017, at 5:38 AM, Branko Čibej  wrote:
> 
>> On 01.12.2017 13:16, Johan Corveleyn wrote:
>> Great! I gather from the reactions in this thread that we have
>> consensus on the principle, we "just" need to do it :-). And figure
>> out some details.
> 
> Will that be Subversion 18.04 Anticlimactic Albatross?

Please, please, DON'T do names like that!!!

Re: svn commit: r1819391 - /subversion/site/staging/docs/release-notes/1.10.html

[Nathan Hartman]

On Dec 28, 2017, at 5:59 PM, Stefan  wrote:
>  
> Suggestion for a different phrasing:
> 
> section id: svn-1.9-old-stable
> 
> The Subversion 1.9.x line is now the old stable version.  This means that 
> 1.9.x will still receive security relevant fixes as well as bugfixes. While 
> we will evaluate any bugreport with regards to its severity, there might be 
> issues with a lower severity which will only get fixed in 1.10.x (this 
> especially applies to issues which would require API additions/changes and/or 
> require a significant investment to get backported to the old stable version).
> Therefore, if you are running into an issue with the old stable version which 
> has already been fixed in the latest version, we might ask you to upgrade to 
> that version to resolve the issue.
> 
> Regards,
> Stefan
> 

Just chiming in here. As a user, Stefan's suggested text makes sense, sounds 
reasonable from both a dev and a user point of view, and is far less scary 
sounding than "deprecated" or "doomed" -- yes I know the other text said it's 
NOT doomed, but nevertheless!!! :-)

Re: 1.10 API review - svn_io_stdin_readline()

[Nathan Hartman]

> On Jan 15, 2018, at 11:42 AM, Julian Foad  wrote:
> 
> About this new-for-1.10 API:
> [[[
> /** Reads a string from stdin until a newline or EOF is found
> *
> * @since New in 1.10.
> */
> svn_error_t *
> svn_io_stdin_readline(const char **result,
> apr_pool_t *result_pool,
> apr_pool_t *scratch_pool);
> ]]]
> 
> Compare with svn_stream_readline() and svn_io_file_readline():
> * they read into a svn_stringbuf_t;
> * they have EOL and EOF params;
> * svn_io_file_readline() has max_len param;
> 
> It seems to me it would be better to make this new function more similar to 
> them.
> 
> Thoughts?
> 
> - Julian

I didn't look at the context but it looks like, at a bare minimum, this 
function needs a size of result param to avoid overrunning a buffer.

Re: Windows Compile Help

[Nathan Hartman]

On Jan 27, 2018, at 11:44 PM, Troy Curtis Jr  wrote:
> 
> I'm hoping someone can point me in the right direction with an issue I'm 
> having compiling Subversion on Windows 10 using Visual Studio 2015 tools.
> 
> I decided to break out of my comfort zone a bit and see if I could get the 
> changes in for the py3c dependency added on the Windows side, but I am *not* 
> a Windows dev.  I've done a lot of learning, which as been fun, but I can't 
> figure this last error out.  I've attached the error log, and my WIP visual 
> studio script that basically got me this far.
> 
> It seems to complain the it can't find a handful of symbols related to zlib, 
> but if I look at the static archive I see those names (though there are all 
> those different calling conventions on windows, so maybe that is related to 
> my issue?).
> 
> Anyway, I've run out of ideas and was hoping for a little nudge.
> …
> 
> 
> Troy
> 
> 

There seems to be a mix of relative and absolute paths with respect to zlib in 
the build script. I'm writing this on my phone so I can't look at the script 
while writing this but the ZLIBPROJ variable (if memory serves) is assigned a 
relative path; the library binaries are copied from there to another relative 
path location; but the --with-zlib= for building Subversion uses an absolute 
path starting with C:\ -- perhaps you have a different zlib there? If so then 
you're building one zlib in this script but using a different zlib when 
building Subversion, perhaps one built with mingw instead of MSVC or something. 
That would explain the linker errors. Unless I'm missing something else :-)

Hope this helps

Re: Windows Compile Help

[Nathan Hartman]

On Jan 27, 2018, at 11:44 PM, Troy Curtis Jr  wrote:
> 
> I'm hoping someone can point me in the right direction with an issue I'm 
> having compiling Subversion on Windows 10 using Visual Studio 2015 tools.
> 
> I decided to break out of my comfort zone a bit and see if I could get the 
> changes in for the py3c dependency added on the Windows side, but I am *not* 
> a Windows dev.  I've done a lot of learning, which as been fun, but I can't 
> figure this last error out.  I've attached the error log, and my WIP visual 
> studio script that basically got me this far.
> 
> It seems to complain the it can't find a handful of symbols related to zlib, 
> but if I look at the static archive I see those names (though there are all 
> those different calling conventions on windows, so maybe that is related to 
> my issue?).
> 
> Anyway, I've run out of ideas and was hoping for a little nudge.
> …
> 
> 
> Troy
> 
> 

Forgive the second reply but on further study of the build log and some 
googling around, I think the absolute/relative paths are not the culprit, and 
that your suspicion about calling conventions may be correct.

https://stackoverflow.com/questions/5424549/unresolved-externals-despite-linking-in-zlib-lib

Which led to:

http://www.zlib.net/DLL_FAQ.txt

To summarize, CDECL is default and therefore probably what Subversion is 
building with, but zlib may be building with STDCALL.

I would check if the zlib project defines ZLIB_WINAPI and if so, remove it and 
retry the build.

Re: Windows Compile Help

[Nathan Hartman]

On Sun, Jan 28, 2018 at 10:23 AM, Troy Curtis Jr 
wrote:

>
>
> On Sun, Jan 28, 2018 at 12:21 AM Nathan Hartman 
> wrote:
>
>> On Jan 27, 2018, at 11:44 PM, Troy Curtis Jr 
>> wrote:
>>
>> I'm hoping someone can point me in the right direction with an issue I'm
>> having compiling Subversion on Windows 10 using Visual Studio 2015 tools.
>>
>> I decided to break out of my comfort zone a bit and see if I could get
>> the changes in for the py3c dependency added on the Windows side, but I am
>> *not* a Windows dev.  I've done a lot of learning, which as been fun, but I
>> can't figure this last error out.  I've attached the error log, and my WIP
>> visual studio script that basically got me this far.
>>
>> It seems to complain the it can't find a handful of symbols related to
>> zlib, but if I look at the static archive I see those names (though there
>> are all those different calling conventions on windows, so maybe that is
>> related to my issue?).
>>
>> Anyway, I've run out of ideas and was hoping for a little nudge.
>> …
>>
>>
>> Troy
>>
>> 
>>
>> 
>>
>>
>> Forgive the second reply but on further study of the build log and some
>> googling around, I think the absolute/relative paths are not the culprit,
>> and that your suspicion about calling conventions may be correct.
>>
>> https://stackoverflow.com/questions/5424549/unresolved-
>> externals-despite-linking-in-zlib-lib
>>
>> Which led to:
>>
>> http://www.zlib.net/DLL_FAQ.txt
>>
>> To summarize, CDECL is default and therefore probably what Subversion is
>> building with, but zlib may be building with STDCALL.
>>
>> I would check if the zlib project defines ZLIB_WINAPI and if so, remove
>> it and retry the build.
>>
>
> Thanks so much for taking the time to look at this Nathan! You were right
> on.  I had gotten close earlier but went the wrong way.  At one point I
> *added* ZLIB_WINAPI to the config header, but of course it complained about
> a redefinition.   It didn't click that I needed to *remove* it.  Pulling
> that out of the build configuration finally got me linking (well, after
> added /safeseh to the asm build in zlib as well).
>
> Now to add swig to the mix and maybe eventually actually adding the change
> I want to test! XD
>
> Thanks again!
>
> Troy
>


Glad I could help. Out of curiosity is this a 64-bit build and did you have
to do anything out of the ordinary because of that?

Re: Backward or forward deltas, backend, FSX

[Nathan Hartman]

On Feb 15, 2018, at 4:11 PM, Daniel Shahaf  wrote:
> 
> Péter wrote on Thu, 15 Feb 2018 19:47 +0100:
> I'm not sure why you say "at least" 17 deltas.  The default value of
> max-linear-deltification (see fsfs.conf) is 16, meaning that no fulltext
> will require 17 delta applications to produce.
> 

Does this mean that when checking out HEAD from a repository with a large 
number of commits, the oldest revision it must access is HEAD - 16? In other 
words, is a compressed full text stored every 16 revisions?

Nathan Hartman 

Re: Backward or forward deltas, backend, FSX

[Nathan Hartman]

On Feb 15, 2018, at 10:17 PM, Daniel Shahaf  wrote:
> 
> Nathan Hartman wrote on Thu, 15 Feb 2018 22:01 -0500:
>>> On Feb 15, 2018, at 4:11 PM, Daniel Shahaf  wrote:
>>> 
>>> Péter wrote on Thu, 15 Feb 2018 19:47 +0100:
>>> I'm not sure why you say "at least" 17 deltas.  The default value of
>>> max-linear-deltification (see fsfs.conf) is 16, meaning that no fulltext
>>> will require 17 delta applications to produce.
>>> 
>> 
>> Does this mean that when checking out HEAD from a repository with a 
>> large number of commits, the oldest revision it must access is HEAD - 
>> 16?
> 
> No.
> 
> Besides, if that were the case, then any commit to the ASF repository, which
> has over 200 projects, would have had to replicate the contents of 184 
> projects
> in full (including all tags and branches).  That would be impractical and 
> inefficient.
> 
>> In other words, is a compressed full text stored every 16 revisions?
> 
> No, for two reasons.
> 
> First, we're talking about revisions of a particular file here: not 'svn log 
> -q ^/'
> but 'svn log -q file.c'.
> 
> Second, Subversion uses skip-deltas, so a fulltext would be stored only
> every O(2**16) ≈ O(65k) revisions (of a particular file):
> 
> https://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas
> 
> Cheers,
> 
> Daniel

Thanks. That's a very good explanation, and a very elegant solution. I 
especially like that past revisions are not rewritten to avoid introducing 
errors.

Re: SHA-1 collision in repository?

[Nathan Hartman]

On Mar 7, 2018, at 6:18 PM, Philip Martin  wrote:
> 
> [Moving this to the dev@s.a.o list.]
> 
> Well done!  It looks like you have identified a serious bug here.  The
> function svn_fs_fs__get_contents_from_file() that was recently added to
> 1.9 for the SHA1 collision detection so the code is new and it is also
> different from that on trunk.
> 
> Your proposed fix looks like it might be correct, although rb->rep is
> just rep so it could be a bit simpler.  One other consequence of this
> bug is that the checksum calculated in rep_read_contents is not
> finalized.
> 
> Myria  writes:
> 
>> During rep_write_contents_close, there is a call to get_shared_rep.
>> get_shared_rep calls svn_fs_fs__get_contents_from_file, which has the
>> code pasted below.
>> 
>> 
>>  /* Build the representation list (delta chain). */
>>  if (rh->type == svn_fs_fs__rep_plain)
>>{
>>  rb->rs_list = apr_array_make(pool, 0, sizeof(rep_state_t *));
>>  rb->src_state = rs;
>>}
>>  else if (rh->type == svn_fs_fs__rep_self_delta)
>>{
>>  rb->rs_list = apr_array_make(pool, 1, sizeof(rep_state_t *));
>>  APR_ARRAY_PUSH(rb->rs_list, rep_state_t *) = rs;
>>  rb->src_state = NULL;
>>}
>>  else
>>{
>>  representation_t next_rep = { 0 };
>> 
>>  /* skip "SVNx" diff marker */
>>  rs->current = 4;
>> 
>>  /* REP's base rep is inside a proper revision.
>>   * It can be reconstructed in the usual way.  */
>>  next_rep.revision = rh->base_revision;
>>  next_rep.item_index = rh->base_item_index;
>>  next_rep.size = rh->base_length;
>>  svn_fs_fs__id_txn_reset(&next_rep.txn_id);
>> 
>>  SVN_ERR(build_rep_list(&rb->rs_list, &rb->base_window,
>> &rb->src_state, &rb->len, rb->fs, &next_rep,
>> rb->filehandle_pool));
>> 
>> 
>> The bug is occurring because build_rep_list is being called with
>> first_rep->expanded_size set to zero.  Well, the reason it's zero is
>> because first_rep is the second to last parameter to build_rep_list,
>> and the above code initialized expanded_size to zero:
>> 
>> representation_t next_rep = { 0 };
>> 
>> Does the code just need this?  I don't know this call >.<
>> 
>> next_rep.expanded_size = rb->rep.expanded_size;
>> 
>> Melissa
>> 
>>> On Wed, Mar 7, 2018 at 9:02 AM, Nathan Hartman  
>>> wrote:
>>>> On Mar 5, 2018, at 10:54 PM, Myria  wrote:
>>>> 
>>>> Final email for the night >.<
>>>> 
>>>> What's clobbering the expanded_size is this in build_rep_list:
>>>> 
>>>> /* The value as stored in the data struct.
>>>>0 is either for unknown length or actually zero length. */
>>>> *expanded_size = first_rep->expanded_size;
>>>> 
>>>> first_rep->expanded_size here is zero for the last call to this
>>>> function before the error.  In every other case before the error, the
>>>> two values are equal.
>>>> 
>>>> Then this code executes:
>>>> 
>>>> if (*expanded_size == 0)
>>>>   if (rep_header->type == svn_fs_fs__rep_plain || first_rep->size != 4)
>>>> *expanded_size = first_rep->size;
>>>> 
>>>> first_rep->size is 16384, and this is why rb->len becomes 16384,
>>>> leading to the error.
>>>> 
>>>> I don't know what all this code is doing, but that's the proximate
>>>> cause of the failure.
>>>> 
>>>> Melissa
>>> 
>>> Has it been possible to determine what is setting expanded_size to 0
>>> before that last call? I wonder if there is specific logic that
>>> decides (perhaps incorrectly?) to do that?
>>> 
>>> Alternatively is it being clobbered by some out-of-bounds access,
>>> use-after-free, or another such issue?
>>> 
>>> Is it possible in your debugger setup to determine the address of
>>> that variable and set a breakpoint that triggers when that memory is
>>> written? (It may be called a watchpoint?)
>>> 
>>> Which leads me to another thought: if you can set such a breakpoint
>>> / watchpoint and it does not trigger, then this expanded_size might
>>> not be the same instance in that final call. Perhaps a shallow copy
>>> of an enclosing structure is made which leaves out the known size
>>> and sets it to 0 for some reason, and that final call is given that
>>> (incomplete) copy.
>>> 
>>> Caveat: I am not familiar with the codebase but these are my
>>> thoughts based on adventures in other code bases.
>>> 
>> 
> 
> -- 
> Philip

Congrats for finding that!

It looks like this falls under the "shallow copy ... which leaves out the known 
size" possibility I surmised about earlier, in which case it is zero because 
the enclosing structure was previously memset()ed to 0 and this field was not 
assigned.

That makes me wonder why this has not triggered more frequently for users? Is 
there some obscure set of circumstances that triggers this code path in this 
particular way? If so, can a test be added to the test suite to prevent this 
sort of thing from slipping in again?

In what way is the code different on trunk?

Re: SHA-1 collision in repository?

[Nathan Hartman]

On Wed, Mar 7, 2018 at 10:37 PM, Philip Martin 
 wrote:

>
> The cause of the bug, as identified by Melissa, is that the wrong
> expanded size if computed -- it gets set to the size of the delta in the
> protorev file.  The svn_stream_t that is producing the fulltext works in
> 16K chunks, so the total amout of fulltext goes up in steps: 16K, 32K,
> 48K, etc.  If one of those steps happens to match the erroneous expanded
> size the stream treats that as the end of the fulltext.  The stream then
> finalizes the MD5 checksum for the partial fulltext and the MD5 checksum
> failure occurs.
>
> For most commits the protorev delta is not a multiple of 16K and so the
> erroneous expanded size does not match any of the fulltext steps.
> Eventually the stream reaches EOF and gets a short read less than 16K.
> The function svn_stream_contents_same2 recognises the short read as EOF
> and ends the comparison between the two streams, however the stream
> itself has not finalized the checksum because of the length mismatch.
> This means we did not verify the MD5 checksum for the protorev fulltext
> but we did verify that the protorev fulltext matches the fulltext in the
> repository.
>

Is it possible and does it make sense to always continue reading until
EOF, when the read is either 0 or < 16k? In other words to eliminate
the comparison against the expanded size?

Alternatively, if reading up to the expanded size and then stopping,
does it make sense to attempt another read, which must come back as 0,
to verify that the expanded size and actual size are equal? If not
equal, an error message on this issue would be far more helpful than
the one currently output.


On Thu, Mar 8, 2018 at 6:41 AM, Philip Martin 
 wrote:

>
> https://issues.apache.org/jira/browse/SVN-4722
>
> My reproduction doesn't trigger the bug in 1.8 but that seems to be
> because 1.8 has some other problem and the rep-cache deduplication
> doesn't trigger.  The third commit restoring the content in the first
> commit simply stores a new delta.
>


Have you had a chance to test against the 1.10 rc?

Re: Script to obliterate the most recent revision(s)

[Nathan Hartman]

On Thu, Mar 22, 2018 at 6:24 PM, Julian Foad  wrote:

> TODO:
>
> 'svnadmin verify' doesn't detect if the rep-cache still contains too-new
> revs, which would cause silent corruption during later commits if allowed
> to remain in place. We should fix that. (I will file an issue.)
>
>
It just occurred to me that because correct operation of the rep-
cache is so crucial to the reliability of the system, perhaps it
would be a good idea to make sure the rep-cache does not contain too-
new revs as a sanity check during normal commits?

Re: Wiki migration complete -- new wiki is now live

[Nathan Hartman]

On Fri, Apr 20, 2018 at 9:20 AM, Johan Corveleyn  wrote:

> After several more iterations, I'm happy to report that the wiki
> migration to the ASF's Confluence wiki is now considered "done". See:
>
> https://cwiki.apache.org/SVN


How do ordinary users access the new Wiki (for reading)? The link above
leads to
a login page.


The old MoinMoin wiki at https://wiki.apache.org/subversion/ still
>
needs to be edited so all pages become redirects to their cwiki
> counterpart.
>

While the old wiki remains online I think there should be a big yellow box
informing
users that this is old and superseded by the new Confluence wiki.

Re: Wiki migration complete -- new wiki is now live

[Nathan Hartman]

On Sun, Apr 22, 2018 at 3:13 PM, Johan Corveleyn  wrote:

> On Fri, Apr 20, 2018 at 3:32 PM, Nathan Hartman
>  wrote:
> > How do ordinary users access the new Wiki (for reading)? The link above
> > leads to a login page.
>
> Sorry, I forgot to enable anonymous access for our wiki space. I've
> added it now. Please try again.
>

I can confirm that anonymous access works now. The new pages look
good. Thank you for your hard work.

Re: Shelve & checkpoint - next steps

[Nathan Hartman]

On Mon, May 21, 2018 at 12:01 PM Julian Foad  wrote:

> Since http://svn.apache.org/r1831908 the "svn status" command can operate
> directly on a shelf.
>
> $ svn shelves -q
> foo
> $ svn st --cl svn:shelf:foo
> --- Changelist 'svn:shelf:foo':
> A   D1
> A   new-file
> MM  config.txt
> D   hello.txt
> A   D1/D2
>
> The main WC state for those paths may be unmodified, or modified in a
> completely different way:
>
> $ svn st
> A  +D1
> M   config.txt
>
> This, to me, is the beginning of the more exciting side of shelving, when
> it is no longer doing just what a simple add-on script could do, but is
> becoming more deeply integrated into the work flows and commands that users
> are already familiar with.


Very nice! When I get some free cycles -- I'm assuming I have to build a
client myself to try it? :-)

An obvious CLI enhancement would be translate a new "--shelf=SHELF" to
> "--cl=svn:shelf:SHELF" and translate "--- Changelist 'svn:shelf:SHELF'" to
> "--- Shelf 'SHELF'".


I don't really see how changelists are related to shelves. I thought
changelists were a feature that should have been more descriptively named
"tags" or "filters" or "groups" or "attributes" or something. But I
probably misunderstand. But in any event I like this idea better:

An alternative is to extend the 'revision specifier' dimension instead, as
> I mentioned before, like this (made-up example, not implemented):
>

> $ svn diff --summarize -r foo
> --- Shelf 'foo':
> A   D1
> A   new-file
> MM  config.txt
> D   hello.txt
> A   D1/D2


This makes sense to me because a shelf is like a potential future revision
(or one in the making). And this syntax is so much cleaner and shorter.
Plus this lends itself to things like:

$ svn diff -r 141:foo

to get the difference between an arbitrary revision and the contents of a
shelf. Whether that would be a nightmare to implement is another story
altogether, as is what to do when shelves become a series of checkpoints
and you want differences between arbitrary items in the series...

Anyway, my 2 cents for now.

Re: Plumbing work to make shelving complete and robust

[Nathan Hartman]

On Fri, Aug 24, 2018 at 12:26 PM Julian Foad  wrote:

> Only by implementing more than one edit driver for each editor (and vice
> versa) can we prove that the components are cleanly separated by an API and
> thus re-usable.
>
> Then there is the need for a test framework that can generate all
> different combinations of changes and test each of the subsystems with all
> of those changes.
>
> These improvements are not just to benefit shelving. In the longer term,
> if we are to make a major improvement like supporting moves/renames
> properly, in my opinion we need to do it starting from a baseline where we
> consistently and cleanly use APIs that encode the current semantics of
> versioned changes, and then migrate those.
>
>
I'm not expert enough on Subversion internals to give in-depth
technical feedback here, but overall this refactoring sounds like a
good game plan, as it will improve consistency and testability, and
it sounds like it will make it possible (and/or easier) to
implement all sorts of nifty new features in the long run. Not only
should this benefit shelving, but checkpointing (which in my view
seems like an extended version of shelving) should benefit
significantly as well.

Re: The future of the Subversion book

[Nathan Hartman]

On Wed, Sep 5, 2018 at 4:49 PM Mark Phippard  wrote:

> Assuming the PMC wanted it, is it possible for the book to be contributed
> to this project and hosted in the Apache SVN repository?  Many people seem
> to post questions and issues in these mailing lists as if it is part of the
> project anyway so maybe we ought to just make this the reality.  I guess
> what I am saying is, before we gauge opinion on whether we want to bring
> this into the project, my question is whether there are any blockers that
> prevent this on the book side from being an option?  Such as copyright or
> licensing issues that make it not possible.  It feels like this has been
> discussed in the past and there were reasons it was kept separate from the
> project even after the publishing of the book by O'Reilly was in the past,
> but I no longer recall them.


I know we're not gauging opinions yet but I think the book should be
consolidated into the official Apache Subversion project. It would be a
boost to both efforts for many reasons. Furthermore having the
documentation presented on the same website is much more sensible and
professional from a user perspective. It would also help in a future
redesign of the website, as the documentation section would be thorough and
quite complete.

Re: API review for 1.11; do we need to mark new APIs as experimental?

[Nathan Hartman]

On Sun, Sep 16, 2018 at 5:17 AM Greg Stein  wrote:

> On Sat, Sep 15, 2018 at 8:48 AM Greg Stein  wrote:
> >...
>
>> No no no... I agree with Brane above. It is confusing, and if people
>> mistakenly mix/match releases things will Just Break. Mysteriously. And
>> horribly. And possibly data-destructively.
>>
>
> To clarify the above a bit:
>
> Consider if the mid-LTS had an entrypoint with 3 parameters, so a client
> coded to that to (also) experiment with the feature set. So Alan has got
> his client installed, trying out this new "shelve" feature, running against
> the mid-LTS release that has been on the system for the past year.
>
> The following week, Brian, his system administrator upgrades to the LTS
> release, for the admin's sanity. "What? LTS releases? YAY! Less work for
> me."
>
> In the LTS, the entrypoint takes 5 parameters. So the function reads wonky
> stuff from the stack. Hilarity ensues.
>
> Brian now gets a call from Alan: "I was working with $client, doing all my
> normal Subversion work. But now it seems that my working copy is corrupted.
> What happened?"
>
> The hilarity ends. Alan is told he can't use his nifty client. Alan gets
> angry. Brian bangs his head on his desk, and wonders how 18 years of random
> Subversion upgrades were always safe. But not this week. Why did it break
> this week? And it was an LTS release!?! Why
>

If the function name begins with x_ until the API stabilizes, that should
prevent the 3 parameter/5 parameter hilarity described above, no? The
client should fail to start due to dynamic linking failure.

Re: API review for 1.11; do we need to mark new APIs as experimental?

[Nathan Hartman]

On Sun, Sep 16, 2018 at 2:09 PM Stefan Sperling  wrote:

> I'm not sure. Exposing these APIs as private ones looked like a simple
> solution to me. On the other hand, maybe "experimental" is a designation
> which is easier for downstream users to understand as opposed to "private"
> which already has an implied meaning of "don't ever use this".
>
> In any case, we should consider declaring experimental APIs in
> dedicated header files, and maybe even in a separate directory.
> That might reduce the potential for confusion between "public"
> and "experimental".
>

There's a difference between *developer* "users" downstream and
actual users of software that uses the svn libs.

Developer users understand the difference between "private,"
"experimental," "public," etc.

Actual users shouldn't need to understand that, or be exposed to
mysterious breakage (or worse, corruption) that results from an API
changing because of an upgrade.

I think the experimental APIs should have the x_ prefix and version
number postfix that increases as development progresses; and when
an API is "blessed" the function is renamed to remove the x_ prefix
and all x_ versions of the experimental function are either removed
or made to unconditionally return an error code.

Removal means client software built against the libs will not link
(dynamically or statically), causing users to see breakage.

Returning an error code is probably a better option but many such
functions may accumulate over time -- unless they are only kept for
some predefined length of time and then ultimately removed.

I think there is no reason to add a unique error code for each removed
function because those would accumulate forever as well. Instead,
I'd create only one systemwide error code for this purpose.

Re: API review for 1.11; do we need to mark new APIs as experimental?

[Nathan Hartman]

In order to strike a balance between:

* Developing new features across the more frequent release
  schedule

* Allowing developers to offer these features early, and users to
  opt in to them

* Avoiding bricking a program as described by Daniel (program
  fails to start after DLLs are upgraded)

* Avoiding the hilarity scenario described by Greg (an API with
  formerly three parameters now takes five. Two of these will be
  undefined values from the stack.

* Avoiding keeping every defunct experimental API in the
  namespace forever

* (Did I miss anything else that should be in this list?)

I suggest the following:

* When an experimental API is declared stable:

  It is moved to the stable namespace. The experimental name is
  kept as an alias for the duration of that major version (e.g.,
  Subversion 1.x).

* When an experimental API is declared defunct:

  The Subversion project should define, as part of its API/ABI
  stability rules, a length of time after which defunct
  experimental APIs are removed.

  During that length of time, the function unconditionally returns
  an error (whichever error code that ends up being) and produces a
  compile-time deprecation warning, which lists the date.

  All such APIs are kept in a single source file, sorted by their
  scheduled destruction date. That significantly reduces the burden
  of maintenance and opens up an opportunity to automate the
  process.

  The next release after that date will not contain the removed
  APIs.

  I suggest one year as the length of time.

* When an experimental API changes (Greg's scenario), the names
  are changed to protect the innocent, and the old name is treated
  the same as a defunct experimental API described above.

Clients that use experimental APIs *should* implement the pattern
of requiring the user to opt in (e.g., by checking a box in a
preference dialog) and notify the user that this feature may break
or be removed in the near future. This should be stated in
Subversion's docs for downstream developers' consideration.

Rationale: That gives downstream developers, OS distributors,
system administrators, and end users a reasonable window of time
during which client and library upgrades will not break each other;
it provides a defined expectation that all parties can plan
against; and it avoids forever accumulating a perpetually growing
list of defunct APIs.

Re: [ANNOUNCE] Apache Subversion 1.10.3 released

[Nathan Hartman]

On Wed, Oct 10, 2018 at 10:31 AM Julian Foad  wrote:

> sebb wrote:
> >> https://subversion.apache.org/download.cgi#supported-releases
> >
> > I think that is the wrong link.
> > It does not point to 1.10.3
>
> Thanks ... you're right. I have now figured out what I did wrong.


The list of people who provided PGP signatures in the announcement was
empty as well. Not sure if that's correct.

Re: Staging the 1.11.0 website updates

[Nathan Hartman]

>
> On 29.10.2018 18:43, Julian Foad wrote:
> > I just pushed the website updates for 1.11.0 to staging:
> >
> > https://subversion-staging.apache.org/
> > https://subversion-staging.apache.org/news
> > https://subversion-staging.apache.org/download
> >
> https://subversion-staging.apache.org/docs/release-notes/release-history.html
> > https://subversion-staging.apache.org/doap  (is not HTML)
> >
> > Please review if you have a mind to.
> >
> > I hope to be able to publish tomorrow 30th Oct (that's the date I've put
> in the website and CHANGES file in the tarball) which would be possible if
> we can get 3 signatures today, or at the very latest the day after (which
> would be close enough for the discrepancy not to matter, and would still
> achieve our stated October release date target).


Not a showstopper, but "Founded in 2000 by CollabNet, Inc., the Subversion
project and software have seen incredible success over the past decade"
should be changed to "last two decades" one of these days, no? Especially
as someone pointed out earlier that Subversion is now of legal age. :-)

Re: SVN version numbering

[Nathan Hartman]

On Wed, Oct 31, 2018 at 6:14 AM Thomas Singer 
wrote:

> Hi all,
>
> OK, we are now at SVN 1.11 because you have agreed to release often with
> only a few changes. What does the prefix "1." mean - will there be some
> "2." or "3." in the future? If not, then it is redundant. For time-based
> releases, wouldn't it be more useful to use the year, e.g. the next one
> could be SVN 19 or SVN 19.04?
>
> Cheers,
> Tom
>
Please don't. Some Linux distros do their version numbering this way and I
can never understand what that means. Much better for version numbers to
denote API compatibility as Subversion does.

Re: Configuration file syntax

[Nathan Hartman]

On Thu, Dec 6, 2018 at 11:50 AM Branko Čibej  wrote:

> As noted in another thread, I've written a page in Confluence that
> describes the syntax of our configuration files:
>
> https://cwiki.apache.org/confluence/x/oYvQBQ
>
> Please review it, especially the formal definition; and please use
> in-line comments to note any problems.


Are those pi and square root in "The [DEFAULT] Section" supposed to look
like Unicode mathematical symbols?

Re: Configuration file syntax

[Nathan Hartman]

On Sun, Dec 9, 2018 at 9:53 AM Branko Čibej  wrote:

> On 09.12.2018 15:32, Nathan Hartman wrote:
> > On Thu, Dec 6, 2018 at 11:50 AM Branko Čibej  wrote:
> >
> >> https://cwiki.apache.org/confluence/x/oYvQBQ
> >>
> >> Please review it,
> >
> > Are those pi and square root in "The [DEFAULT] Section" supposed to look
> > like Unicode mathematical symbols?
>
> Yes, they are. And I promise that Subversion's config files do indeed
> support what's written there — as long as the locale is set up correctly
> so that it can convert the contents as UTF-8.


Cool!

I think there should be a subsection after Ignored Matter and before
Sections called Character Encoding that documents that, with a yellow box
cautioning that locale must be setup correctly.

Re: Subversion Exception!

[Nathan Hartman]

On Thu, Dec 13, 2018 at 11:59 AM Branko Čibej  wrote:

> I never said that it's a good idea to abort in a library. We made a
> mistake in the early days of this project to allow such patterns.


>
> I am quite angry at the contrariness and stubbornness of one TSVN
> developer, who is *also* a Subversion PMC member.


I propose a compromise.

Remove this mistake in 2.0, when API/ABI compatibility with old mistakes no
longer applies, but meanwhile improve the message in TSvn.

Just to be clear, I *don't* propose to make the jump to 2.0 anytime soon,
nor to do so in haste. But I do propose the need for a Confluence page to
start the conversation about what 2.0 should be. Right now I can think of
two things for that page: (1) composing a new statement of Subversion's
goal for 2.0 (being a better CVS is just so 1.0), and (2) a list of old
mistakes that should be fixed at the turn of the major version number, like
this abort() thing.

Re: Display outstanding backported fixes for each release?

[Nathan Hartman]

On Fri, Jan 4, 2019 at 9:24 AM Mark Phippard  wrote:

> On Fri, Jan 4, 2019 at 4:47 AM Julian Foad  wrote:
>
>> Julian Foad wrote:
>> > Ha ha! It's laugh-out-loud ugly, that teeny-tiny viewport...
>>
>> I hope my sense of humour was not badly misjudged. Seeing that Mark wrote
>> it "Looks good" without any smiley, maybe everyone else is not seeing what
>> I saw. The attached screenshot shows how it renders in Firefox.
>>
>> I genuinely was delighted to see it working at all.
>>
>
> I was using an iPad.  I do not know if it was the smaller screen or if iOS
> does something to make the iFrame "fit" but in general it looked fine.
> Looking at it now on my desktop I see the same tiny viewport as you.
>
> In general iFrame's are gross and a source of problems, but they are also
> super convenient so I get it.  I was mainly happy to see the info come
> together and assume there are ways it can be finessed into looking better
> on various browsers.  Since we have SSI's available that seems like an easy
> initial solution to avoid needing the iFrame.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>

The "responsive iframes" technique described at the following page works
with things like embedded YouTube videos to size the frame correctly for
desktop and mobile:

https://blog.theodo.fr/2018/01/responsive-iframes-css-trick/

Maybe it will help in this case too.


>

Re: SHA1 collisions became cheaper to create.

[Nathan Hartman]

On Tue, May 21, 2019 at 1:06 AM Paul Hammant  wrote:

> The Git folks moved to a hardened SHA1 function as an interim measure
> on the way to SHA-256 -
>
> https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt
>
> I think you're generally right. While I might think that an auditor
> would simply be advised of the root hash for a Merkle tree that for a
> branch at a moment in time, or a tag, Subversion doesn't have a a
> Merkle tree under the hood. I coded something niche to retrofit
> Subversion with that, but it's not core and far from perfect as it
> relies on an LRU cache and keeps no history itself. Git's merkle tree
> would be perfect if it didn't blow up when repos get too big, and if
> allowed clone from nodes other than root (branches and tags are in
> respect of root of course).  So, ignore me here


Why a merkle tree? One of Subversion's strengths is its linear revision
history. You could use blockchain and get financial strength audit ability.

Re: Subversion's community health

[Nathan Hartman]

On Fri, Jun 14, 2019 at 10:35 AM Eric S. Raymond  wrote:

> Julian Foad :
> > not dwell on our sadness and criticism of what went before; let us try to
> > keep this thread focused on positive solutions for what to do next.
>

It's all a matter of publicity.

Git gets all the publicity because open source uses Git and open
source happens in public.

Subversion is applicable to business and other centrally organized
entities. Some do their work in public; most don't.

Subversion's centralized nature is actually a big strength in those
situations -- and while I can go on about its technical superiorities,
that's a subject for another thread. The point is that because there
is no publicity, you don't see it, and neither do potential users or
contributors.

To Make Subversion Sexy Again there is a need for visibility and
publicity -- Subversion evangelism.

It starts with this community changing its thinking TODAY from "we're
old and tired" to "we're sexy again."

Talk about Subversion. Not just here. Everywhere. With everyone. Raise
awareness about the strengths Subversion has today. Talk about
Subversion 2.0 and all the wonderful things in it. Yes, even though it
doesn't exist yet. Even if the present members of this community won't
be the ones implementing it. Talk is cheap, yet it's a powerful thing.
Every conversation increases the probability of piquing someone's
interests and is a step toward attracting the new blood this community
needs.

Re: Subversion's community health

[Nathan Hartman]

On Tue, Jun 18, 2019 at 7:00 AM Julian Foad  wrote:

> Here is my suggestion.
>
>
> Primary goals:
>
> * Stability
>




> * Availability


All of the above -- being mature, reaching the stability phase, etc --
is true of Subversion 1.x. It is _not_ true of "Subversion" without a
1.x after it.

Subversion 2.0 hasn't been born yet. Ironically, now is the time,
specifically because stability of 1.x means not introducing huge
groundbreaking features. But under no circumstances should such new
development be discouraged and turned away!! On the contrary, the
Subversion project should encourage it!

I believe there _will_ be new development in the future. Partly I
believe this because it's on my own to-do list, and I have some big
ideas that will _have_ to go in a 2.0 (even if 1.x didn't enter a
stability phase). Partly I believe it because Subversion offers some
great things that no other tool does. And partly because in my short
time on this earth, I've seen entirely too many occasions when
something was almost dead and came back stronger than ever, while
other things were flying high and mighty and then crashed and burned.

The name "Subversion" is actually the perfect name for this project.
It's a double entendre. While the technical idea is to control "sub-
versions" -- versions between versions -- the word "subversion" means
to transform an established social order. I'll say no more. :-)

Subversion 1.x is mature. Subversion 2.0 is now on the drawing board.
Let's make 1.x as stable and available as possible and let's encourage
discussion about 2.0 and all the great things ahead.

I recommend a two pronged approach.

Prong 1: Everything you said about stability and availability for 1.x.
People need to know that the Subversion they know, love, and rely upon
will continue to take care of them.

Prong 2: Open up a 2.0-dev branch even if there's nothing to put there
yet. In any announcements about 1.x going stable make sure to mention
that 2.0 is now open for business. People need to know that there is a
future -- and they can help shape it!!

Re: GitHub pull requests

[Nathan Hartman]

On Thu, Jun 20, 2019 at 3:27 AM Branko Čibej  wrote:

> Moving the source to git would be less than ideal in terms of eating our
> own dogfood. It would also be a terrible move from the "marketing"
> perspective.


I agree with that. There is a lot to be said for "dogfooding." Keeping the
project in svn with better GitHub integration would be a win. Also it would
be a demonstration that Subversion can do that, particularly for those who
need Subversion's features but would like to benefit from that possibility.

Subversion 2.0

[Nathan Hartman]

I first heard about Subversion from an article in Linux Journal back in
2002 [1]. The only viable open source version control at the time was CVS,
which wasn't very good, but "everyone" used it because it was available and
it worked, despite its shortcomings. Subversion promised to be a massive
improvement over CVS and I could tell from the article that some serious
thought had gone into its design. By the time I finished reading, I was
really excited.

Next year the Subversion project turns 20. Subversion met and exceeded its
original goals by a lot. My personal experience has been many years of use,
ZERO problems, and Subversion's enterprise features are a big win.

Subversion 1.x is mature, stable, rock-solid, reliable, and safe. The goal
of 1.x is now stability and availability. Big changes and whiz-bang new
features don't really belong there. It's time for Subversion 2.0, the
Subversion of the future.

I have many thoughts to share in the coming days, including my observations
about the world of technology and why things happening right now mean there
are opportunities to attract new users and developers to the project.

But I won't be the only voice here. This post is only the first page of a
big conversation and everyone is encouraged to participate.

The future isn't written yet. It can be anything. And since this is the
idea phase of Subversion 2.0, there's no need to worry about specifics,
like how to solve particular coding problems or who specifically is going
to write what. Right now is the time to dream, out loud. What is your dream
version control system, if you could have it all? Why would it be that way?

Subversion 2.0, The Idea Phase, now open for business. :-)


[1] The Subversion Project: Building a Better CVS, Ben Collins-Sussman, Feb
2002 Linux Journal:
https://www.linuxjournal.com/article/4768

Re: Subversion 2.0

[Nathan Hartman]

On Fri, Jun 21, 2019 at 10:38 AM Mark Phippard  wrote:

> I think the reason that both Subversion and Git were successful is that
> they both had very clear and compelling visions and goals for what they
> wanted to accomplish and then they did that.
>
> I do not think a few new features or design changes to Subversion will
> make a difference at this point .. and I am not saying that is what you are
> suggesting.  I would want to be sold on some compelling new ideas for a
> product, and then probably why building those ideas on the Subversion 1.x
> code base makes sense.
>

Agreed 100%.

The purpose of this thread is to have a community-wide brainstorming
session to figure out exactly what we want from the Subversion of the
future, for that very reason.

As a cautionary tale I would look at Veracity.
> http://veracity-scm.com/compare/
>
> I struggle to find some of the original blog posts that Eric Sink made
> when they were creating this product but I know they set out to fix a lot
> of the shortcomings in Git and they did so using an Apache license. AFAIK,
> they accomplished most of their initial goals and then went on to also
> incorporate some of the ideas from Fossil in adding a distributed agile
> tracker and wiki to the product as well.  Despite all of this the product
> landed with a thud and has been discontinued. Aside from wondering why it
> would not be a better code base than Subversion to start a new product from
> I come back to the compelling idea point.  What are the ideas that are
> going to move the needle?  Who is the target audience?  The corporate world
> is probably still in play but it seems very difficult at this point to move
> the open source world away from Git.
>

I'm glad you brought that up because it's exactly what I want to
address today.

One of my goals for Subversion 2.0 is to attract new users and
developers to the project.

The obvious question is: How?

Git is the 800 pound gorilla in the version control room, so any
strategy to attract new users and developers to Subversion must deal
with Git (among other things).

Veracity SCM tried to be a better Git. One could argue that Mercurial
tried the same thing. But Git has been far more widely adopted, at
least it appears that way in public, in the open source world. We
don't know what goes on behind closed doors.

Mercurial could be perceived as a Git wanna-be. It's easier to use but
a little slower. Git blasted Mercurial out of the water because people
generally don't like imitations. People want the real deal. Given the
choice between real Git and imitation Git (even if it's not true; it's
perceived), most people will probably choose real Git.

That should give us a hint. The goal "be a better CVS" worked in 1999.
"Be a better Git" will _not_ work in 2019. So we have to go a
different way.

My suggestions for a strategy with respect to Git:
* Do not compete with Git in areas where Git is strong. Instead,
  cooperate with Git in those areas.
* Compete with Git in areas where Git is weak.

Do not compete with Git: I do not suggest to turn Subversion into a
DVCS because we'll be perceived as imitation Git. Subversion is
centralized and that is NOT a weakness. I'd like to point out that in
2004, Internet access was slow and therefore "everything is local" was
a big selling point of Git. But in 2019, when broadband Internet is
cheap, when cell phone plans come with mobile hotspot, with 5G on the
horizon (and they're talking about massive amounts of data at near-
instant speeds), this is becoming much less of a concern with every
passing minute. People want to be on the same sheet of paper with each
other. People are comfortable with "the cloud." As telecommunications
get better and faster every day, Git's "everything is local" starts to
become more of a liability than an asset. GitHub exists because people
want and need a central repository. Like the saying goes, what's old
is new again.

Compete with Git: I suggest to start by amplifying the best things
about Subversion that make it different and better than Git. But
that's just incremental change. We need something more. As Mark said,
we need something compelling. So I will close for now with the
following question, which I have been asking myself: How can we
leverage Subversion's centralized structure to give something _better_
than modern workflows?

If we come up with some compelling ideas, it might be interesting to invite
> Eric to conversation to share what they learned and why what they were
> doing never worked. The one thing I can say is that while they were open
> source and tried to create a community and be open maybe there are things
> they could have done differently that would have had more impact ... such
> as trying to make it an Apache Foundation product.
>

I would like as many people as possible to be invited to the
conversation.

Re: Subversion 2.0

[Nathan Hartman]

>
> On Tue, Jun 25, 2019 at 5:34 PM Branko Čibej  wrote:
>On 25.06.2019 19:16, Thomas Singer wrote:
>>> I don't want to rain on anyone's parade but here's some food for
>>> thought. The only valid reason to call anything 2.0 is if, and only if,
>>> we decide to break backwards compatibility in some area.
>>
>> I disagree. It is quite common use to name something 2.0 if it has
>> serious improvements over 1.x.
>
>That's marketing, not software development. :)

Subversion needs some marketing -- separately from and in addition to plans
for a 2.0.

I understand that from a technical perspective, there is no reason to
change the major version number unless compatibility/API/ABI promises are
going to be broken. A 2.0 means you can break those promises, BUT I propose
that just because you CAN do something doesn't mean you have to. Subversion
2.0 could very well keep 100% of 1.x's promises. Even though the option to
break promises exists, I would err on the side of keeping them anyway,
unless doing so (very sparingly) would provide compelling benefits that
outweigh the hassle caused by such breakage.

So why 2.0 then?

(1) To separate between a stable 1.x that focuses on keeping a clean issue
tracker and a 2.0 that focuses on new and experimental development. This
might give more freedom to experiment while reducing risk of disruption to
existing customers until new features are release-quality.

(2) To make it clear, in light of 1.x "going stable," that the project
won't turn away new development or new developers. Both are encouraged and
invited with open arms, always.

(3) Marketing.

Just to make this clear, I do not think it's a good idea to reimplement
Subversion in another language and I do not think the nature of Subversion
should be changed drastically. That would be a different product. I'm in
favor of longevity: Longevity of the project, longevity of keeping
promises, backward/forward compatibility between server/client and on-disk
data structures, etc. The fact that a dump and load has NOT been needed in
many years, the fact that Subversion is careful about preserving your
history -- in short, Longevity, should be a bragging point of Subversion.

Somewhere you said that it took 4 years to get from nothing to 1.0. The
difference between today and back then is that today you have a rock solid,
reliable, excellent 1.x; back then you had CVS. There's no rush to release
2.0, or even write code for it. The journey of 1000 miles doesn't begin
with a single step; it begins with deciding where to go. :-)

Re: svn_io_file_flush_to_disk fails on AFS filesystems on Darwin

[Nathan Hartman]

On Wed, Jun 26, 2019 at 11:49 AM Branko Čibej  wrote:

> On 26.06.2019 04:52, Quentin Smith wrote:
> > svn_io_file_flush_to_disk in subversion/libsvn_subr/io.c fails to
> > flush files on AFS filesystems on Darwin. The user-visible experience is:


(snip)

> The code ignores EINVAL with a comment about filesystems that don't
> > support it; evidently on Darwin this also needs to include ENOTTY.
> >
> > (Also, I suspect it should fall back from fcntl to fsync, since I
> > suspect fsync /does/ work on AFS filesystems.)


(snip)

Last but not least, I do wish filesystems were consistent in their
> implementation ... what on earth is ENOTTY doing here?
>
> -- Brane


Looks like libuv encountered similar issues and applied similar handling to
that in SQLite:

https://github.com/libuv/libuv/commit/5b0e1d75a207bb1c662f4495c0d8ba1e81a5bb7d

Re: svn_io_file_flush_to_disk fails on AFS filesystems on Darwin

[Nathan Hartman]

On Thu, Jun 27, 2019 at 5:20 AM Branko Čibej  wrote:

> > On 26.06.2019 20:57, Branko Čibej wrote:
> > Turns out that APR is already doing this _almost_ correctly. The kind of
> > change linked to above would fit in APR quite well. The "problem" is
> > that Subversion currently doesn't use the "new" APR functions for
> > sync/datasync. So my suggestion for the fix would be twofold:
> >
> >   * Enhance the sync functionality in APR (trunk, 1.7 and possibly 1.6)
> >   * Change Subversion to use APR's sync functions
> >
> > I'll look into this.
>
> Interesting ... "man fcntl" on macOS does *not* mention ENOTTY at all.
> So everyone who's currently implementing this fix is relying on an
> undocumented feature of the filesystem. :)


Sounds like a BUG, either in macOS, Darwin, APFS, or the man page.

Sadly it's not obvious where to report it.

Re: Subversion 2.0

[Nathan Hartman]

On Tue, Jun 25, 2019 at 1:15 PM Thomas Singer 
wrote:

> What I like most about Git:
>
- it allows to create clean commits, because I can modify all my local
> commits, e.g. reorder and squash them, in case I detected an error in a
> previous, unpushed commit
>


> - I can solve every conflict locally, try again and again, without
> losing any changes (imagine a complicated merge in SVN where you now
> have solved a couple of conflicts, but an update brings new conflicts)
>


> - Git allows me to create a feature in my own branch, turn all my
> commits in this branch up-side-down if I need (even after pushing to the
> repository) and finally rebase it on top of the main development branch
>

Let's put our "future caps" on...

Imagine a fully-functioning checkpointing feature:

Checkpointing is a "local commit history" mechanism, but we don't call
it a "commit" because "commit" is a strong concept in Subversion.
Commit history is immutable: Whatever is committed is safe forever.

A checkpoint is a weak concept, more like the weak commit history you
find in a DVCS. Checkpoints are local and private until committed or
shared.

A checkpoint can represent any committable changes. Checkpoints can be
rewritten, modified, reordered, copied, moved, squashed, divided,
deleted, etc. Their commit messages can be edited easily.

Checkpoints live in arrays of checkpoints. Each array has a user-
assigned descriptive name and serves as a mutable linear mini-history.
Arrays can be copied, renamed, deleted... You can have as many arrays
as you like.

Checkpoints and arrays of checkpoints can be created and manipulated
by the system or the user.

By the System:

Automatic checkpoint before potentially destructive operation: If
there are uncommitted changes in the WC, svn update and svn merge
automatically create a checkpoint. That way, the user never loses a
good working state to a bad one if the update, merge, or ensuing
conflict resolution get messed up (by either the system or user).
You can try again and again until you get it right.

Automatic checkpoint at specified time intervals: This one is more
applicable to GUI clients. You can tell it to make an automatic
checkpoint, say, every 15 minutes, if there are new changes. Better
yet, the GUI client could monitor the directory / get OS change
notifications and make an automatic checkpoint of every change. So
when you hit "save" in your editor, Subversion makes a checkpoint as
well. Automatically.

By the User:

Reordering/rewriting/manipulating means you can work happily and make
checkpoints along the way, ending up with a "messy" checkpoint
history. You can rewrite/reorder checkpoints in place. Or, if you like
"non-destructive editing," create a new separate array and cherrypick
checkpoints onto it, making any edits. If you worked on different
unrelated things, create different unrelated arrays and cherrypick
each checkpoint onto the appropriate array. Once you've built up a
clean linear history of related changes in a checkpoint array, that
array can either be squashed and committed as one commit or left
intact and committed as a sequence of commits. GUI clients could
utilize Subversion's lock-modify-unlock feature to make the separate
commits in order without other unrelated commits getting in the
middle. In the future, a new improved client/server protocol will
support committing an array of checkpoints as a sequence of commits,
atomically. So either all the checkpoints go in or none go in, and
nothing gets in the middle.

Pull requests: A mechanism to pack up an array of checkpoints in a
single file for sharing with colleagues. No big paragraph needed to
explain this one.

How does the future look so far? :-)

Re: Checkpointing

[Nathan Hartman]

On Fri, Jun 28, 2019 at 1:12 PM Thomas Singer 
wrote:

> - so the working copy can have checked out multiple commits or one
> checkpoint?
>

The working copy has always provided one "view." I say "view" for lack
of a better word but I mean the checked out directory of your data
that is under version control. Currently, that "view" can be changed
through updating to a different revision, switching to a different
branch, changing depth on a sparse/shallow checkout, etc; but it's
still one view. As I imagine it, checkpoints would add the ability to
update to a checkpoint, or revert to the last checkpoint.

This begs a few important questions, such as:

When someone does "svn revert" with no additional parameters, what are
we reverting to? Do we revert to BASE as we always have? Or to the
last checkpoint? That requires further study...


> - will it support multiple histories ("branches") planned, e.g. for
> different features?
>

Subversion already provides server-side branches. For local work,
earlier I described multiple "arrays" of checkpoints. We need a better
name than "array" but the idea is that a checkpoint is like a local
commit, and the array is a local linear history of such commits. And
you can have multiple arrays. You could say that each array is like a
local branch. But I would rather think of each array as being for a
certain subject. So, for example if I'm editing code to write a new
feature, I might have a checkpoint array called "feature" and a second
checkpoint array called "unrelated" just as an example. I'd work on my
feature, making checkpoints to the "feature" array as I go. Suppose
that while I'm working I come across typos in comments. I could fix
those typos and make a checkpoint of that un the "unrelated" array.
When I'm ready to commit, I'll commit the typo fixes separately from
the feature work. That would make it much easier to have one subject
per commit.

Anyway that's how I imagine it. If you have other thoughts, I'd love
to hear them!

- will it support "rebasing" such a local history onto the latest
> updated commit?


It will have to support "rebasing" which is what "svn update" already
does today. Otherwise you couldn't commit your work!

Re: Checkpointing

[Nathan Hartman]

On Sat, Jun 29, 2019 at 7:21 AM Branko Čibej  wrote:

> As Mark explained, it will do none of the above unless someone steps up
> and writes the code.
>
> For reference, what Nathan described was discussed here on the list and
> in person during hackathons years ago, yet nothing happened until Julian
> started writing code (and even then, what Julian is doing is a limited
> subset of the "ideal").
>
> If there's no interest amongst people to take the time to write the code
> ... well, we can all tell tall stories about the future, but that won't
> change it one bit.
>

I know.

We all know.

I understand the frustration I see here.

I understand that you've seen these wonderful discussions time and
again and then nothing happened. And you've seen it so many times that
you've become inoculated to the idea that it could change.

But it will change, because:

There was a wise man named Albert Einstein, and I have no idea if he
actually said this or not but he's widely credited with saying that
the definition of insanity is to do the same thing over and over and
expect different results.

Telling the closed dev@ community that we need new developers didn't
work until now and I don't expect it to start working miraculously.
I'm sorry to use an expletive -- marketing -- but that's what we need
with the outside world. No business can sustain itself without telling
the world what it's all about and there's no reason to believe that an
open source project is any different. There's still a profit motive.
In a business, it's profit in money; in an open source project, it's
profit in mindshare and participation. So we need to get out there and
drum up some new business, BUT:

There's a bit of a chicken and egg problem here. If we entice new
potential devs to join dev@ and they come here and see discussions of
decline, defeat, and despair, they'll get turned off and go somewhere
else. People want to be part of something successful! We need those
who join to see discussions of all the cool things Subversion WILL do.

Of course it won't do any of it until after the code gets written. For
the code to get written we need devs. To get devs we need to change
our thinking from despair to planning for a great future. So let's have
some positive discussions over here!

I'm going to search for those old discussions -- and the ones about
what the command line syntax should be like -- and I'll be back later
with some concrete thoughts.

Re: Subversion 2.0

[Nathan Hartman]

On Sun, Jun 30, 2019 at 4:47 AM Greg Stein  wrote:

> On Tue, Jun 25, 2019 at 6:18 PM Nathan Hartman 
> wrote:
>
>> I understand that from a technical perspective, there is no reason to
>> change the major version number unless compatibility/API/ABI promises are
>> going to be broken. A 2.0 means you can break those promises, BUT I propose
>> that just because you CAN do something doesn't mean you have to. Subversion
>> 2.0 could very well keep 100% of 1.x's promises.
>>
>
> That isn't how it works.
>
> Subversion 1.x is a signal to system administrators that they can upgrade
> their 1.x installations to the latest 1.x and NOT WORRY.
>
> Once you bring in 2.x, regardless of what the developers do to keep/lose
> compatibility ... you have lost the 20-year guarantee of compatibility. The
> admin must now do some research. And the question in that admin's head will
> always be "what am I missing? if this is compatible with 1.x, and I should
> not fear upgrading to 2.0 ... then why did they change the version number?
> that was supposed to be a signal."
>
> For 20 years, the promise has been "upgrade to 1.x without fear. 2.x makes
> no guarantee". You speak of "marketing". There is no amount of marketing
> that will alter the past 20 years of our API guarantees.
>
>
That is actually perfect.

There are several challenges here that need to be addressed.

One is the need for more developer participation. Working on that...

Another is that one of Subversion's strengths is also a weakness. The
20 year guarantee is great for system administrators and users. It
demonstrates stability and reliability, which is important given what
Subversion does. This isn't a video game; this software houses your
precious data! Years and years of forward and backward compatibility is
a bragging point and a strength.

But it's also a weakness because it means that we can't be bold and
experiment, as that would break guarantees and bring instability.

So, okay, that's a legitimate explanation as to why we don't up the
version number to 2.0 unnecessarily. But I still think we need the
*concept* of a 2.0 as a way of moving forward. So I'll alter what I
said before, slightly: Bug fixes, stability improvements, and stable
production-ready features should go into 1.x, while 2.0 should be the
playground for bold experiments, developers, and adventurous users.
It doesn't matter if there's ever a 2.0 release. Instead, as features
in 2.0 become stable and production-ready, they can be merged back to
1.x and become part of the next "no worries" 1.x release, provided
they do not break compatibility! If they break compatibility, then
we'll cross that bridge when we get to it.

So, yes, 1.x can live on and on, until 1.414213562373095.

For marketing purposes, we could give names to releases that introduce
major new (but stable and production-ready) functionality.

The important thing is: We want devs! So we do not want to create an
impression that bold new stuff isn't welcome. It's welcome and it has
a place called 2.0!!

Re: Checkpointing

[Nathan Hartman]

On Sun, Jun 30, 2019 at 11:22 AM Thomas Singer 
wrote:

> With "rebasing" I mean, that such list of "local commits" needs to be
> re-applied (on demand, not automatically) onto a different revision.
> Something like a continues series of cherry-picking (with the
> possibility to get a conflict in each step; and a possibility to
> continue after conflict resolution or abort). This means to me, that at
> least cherry-picking needs to be possible from a revision or a "local
> commit".
>

Could you describe how you would like to use this capability? E.g.,
give an example use case?

Re: Subversion 2.0

[Nathan Hartman]

On Fri, Jun 28, 2019 at 12:51 PM Markus Schaber 
wrote:

> It's a very powerful feature, on par or even superior to other (D)VCSes -
> as long as we manage to keep the interface clear enough that users can
> handle everything.
>
> I'm always astonished how complicated GIT can be for seemingly "simple"
> tasks, and even the available GUIs are not always helpful. HG is doing a
> much better job here, as far as I can see...
>
> It stand and falls with the user interface.
>
> And we should take it seriously from the beginning. When the new features
> are implemented with unusable/complex UI first, users will want to try it,
> fail, and turn away. We won't be able to catch them later when the UI is
> better...


I agree. A bad user interface will result in complaints that repeat
around the Internet in perpetuity, even after the problems are fixed.
I think we know this from experience! Also, once the interface gets
"grandfathered in," it can't / won't change because of compatibility.

I'm studying this issue and I'll be back with some concrete
suggestions; in the meantime I'd love to hear your thoughts as well!
Especially use cases. :-)

1.9.12 test failure

[Nathan Hartman]

FYI:

[067/109]
externals_tests.py.FAILURE
[068/109] getopt_tests.pymake: *** [check] Error 1

Platform: macOS 10.13.6

Investigating... be back soon.

By the way, is there a script that generates the list of dependencies and
their versions?

Re: 1.9.12 test failure

[Nathan Hartman]

On Fri, Jul 19, 2019 at 11:57 AM Nathan Hartman 
wrote:

> FYI:
>
> [067/109]
> externals_tests.py.FAILURE
>
>
Apologies for the noise. This was caused by a volume full error!

I'll rerun on a bigger volume and let you know.

Re: 1.9.12 test failure

[Nathan Hartman]

On Fri, Jul 19, 2019 at 12:10 PM Julian Foad  wrote:

> Nathan Hartman wrote:
> > Apologies for the noise. This was caused by a volume full error!
> >
> > I'll rerun on a bigger volume and let you know.
>
> Hehe. Glad to know you're testing it.
>

Thanks for your hard work! I'll test the other rc's as well, also on Linux
and Windows.

> By the way, is there a script that generates the list of dependencies and
> their versions?
>
> I think the most 'official' source is 'get-deps.sh' in the source root
> dir. The list of version numbers is near the top of that file.
>

I meant is there a script that generates the list of dependencies actually
used
on the test system. E.g., as in this testing/signing message from a prior
release:

https://svn.haxx.se/dev/archive-2019-04/0012.shtml

Because even though I'm not signing, I'd like to report what was actually
used.

subversion-1.9.12 tests successful on macOS

[Nathan Hartman]

I used get-deps.sh, but modified the zlib version to 1.2.11 and
download address to https://www.zlib.net/zlib-1.2.11.tar.gz because
it failed to get zlib.

Summary of test results:
  2223 tests PASSED
  83 tests SKIPPED
  47 tests XFAILED (1 WORK-IN-PROGRESS)
SUMMARY: All tests successful.

Platform: macOS 10.13.6

subversion-1.9.12 tests successful on Linux

[Nathan Hartman]

Same comment as before on modifying get-deps.sh to pull zlib 1.2.11
from https://www.zlib.net/zlib-1.2.11.tar.gz.

Platform: Linux (Debian "Stretch") x86_64

Summary of test results:
  2225 tests PASSED
  83 tests SKIPPED
  45 tests XFAILED (1 WORK-IN-PROGRESS)
SUMMARY: All tests successful.

subversion-1.10.6: tests successful on Linux

[Nathan Hartman]

Same note as before: Modified get-deps.sh to use zlib 1.2.11 from
https://www.zlib.net/zlib-1.2.11.tar.gz

Platform: Linux (Debian "Stretch") x86_64

Summary of test results:
  2415 tests PASSED
  94 tests SKIPPED
  57 tests XFAILED (1 WORK-IN-PROGRESS)
SUMMARY: All tests successful.

subversion-1.10.6: tests successful on macOS

[Nathan Hartman]

Same as before: Modified get-deps.sh to use zlib 1.2.11 from
https://www.zlib.net/zlib-1.2.11.tar.gz

Summary of test results:
  2413 tests PASSED
  94 tests SKIPPED
  59 tests XFAILED (1 WORK-IN-PROGRESS)
SUMMARY: All tests successful.

subversion-1.12.2: tests successful on Linux

[Nathan Hartman]

Same note as earlier: Modified get-deps.sh to use zlib 1.2.11 from
https://www.zlib.net/zlib-1.2.11.tar.gz

Platform: Linux (Debian "Stretch") x86_64

Summary of test results:
  2526 tests PASSED
  97 tests SKIPPED
  87 tests XFAILED (17 WORK-IN-PROGRESS)
SUMMARY: All tests successful.

Re: 1.9.12 test failure

[Nathan Hartman]

On Fri, Jul 19, 2019 at 6:03 PM Daniel Shahaf 
wrote:

> Nathan Hartman wrote on Fri, 19 Jul 2019 17:32 +00:00:
> > I meant is there a script that generates the list of dependencies
> > actually used on the test system. E.g., as in this testing/signing
> > message from a prior release:
> >
> > https://svn.haxx.se/dev/archive-2019-04/0012.shtml
> >
> > Because even though I'm not signing, I'd like to report what was
> actually used.
>
> There's 'svn --version --verbose', and I think stsp's distro
> (tools/dev/unix-build/)
> has a target for this too, but beyond that, I don't think there's a single
> script
> you can use.  Many developers use Debian derivatives, though; perhaps one
> of
> them will share a script you can use.
>
> People usually report what test combinations they ran.  (That basically
> means what FS backend and RA layer you tested.  If you set any relevant
> 'make'- or 'make check'-time knobs, it's useful to say that, too.)
>
> Also, I can't think of a reason why you shouldn't sign the tarballs.
>
> Thanks for testing,
>
> Daniel
>

Thanks. That does make it much easier to include the dependency info
for future tests.

I was under the impression that a signature is only meaningful when the
signer is a committer. :-)

Glad to help. Thanks to everyone for the latest Subversion releases!

Re: 1.9.12 test failure

[Nathan Hartman]

On Fri, Jul 26, 2019 at 12:08 PM Mark Phippard  wrote:

> On Jul 26, 2019, at 12:06 PM, Nathan Hartman 
> wrote:
>
> On Fri, Jul 19, 2019 at 6:03 PM Daniel Shahaf 
> wrote:
>
>> Also, I can't think of a reason why you shouldn't sign the tarballs.
>>
>
> I was under the impression that a signature is only meaningful when the
> signer is a committer. :-)
>
>
> The signature only counts as a binding vote for the release when it is
> from a committer but in terms of strengthening the web of trust we ought to
> accept a signature from anyone.
>

In that case, I'll be happy to do that in the future. :-)

Re: Subversion 1.12.2: "svn diff --changelist ARG" broken in subdirectories?

[Nathan Hartman]

On Tue, Jul 30, 2019 at 9:40 AM Tobias Bading  wrote:

> Hi.
>
> I just built Subversion 1.12.2 on GNU/Linux and "make check" didn't show
> any problems.
> But in this version, "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.
>

I can confirm that the outcome on my system is exactly as you
describe.

svn diff --changelist ARG appears to work only in the root of a
working copy, not in a subdirectory.

When run in a subdirectory there is no output, even though the file
has changed.

FYI I did not run your reproduction script but I did perform similar
actions on one of my working copies and I can confirm.

I am using Subversion 1.12.2 which I likewise built and installed from
source a couple of days ago. There were no problems in make check.

Not that it appears to make any difference but my platform: Debian 9.9
"Stretch" and svn version: 1.12.2 (r1863366).

The rest of your email with reproduction script follows. I'm
preserving it because it has been a couple of weeks since you
wrote:


Here's a little shell script that reproduces the problem:
>
> --- %< ---
>
> #!/bin/sh
>
>
> ##
> ##
>   ##
> ##  Script to reproduce a bug where "svn diff --changelist ABC" shows
>  ##
> ##  nothing when executed in a subdirectory of a working copy root.
>  ##
> ##
>   ##
>
> ##
>
> SVN=`which svn`
> SVNADMIN=`which svnadmin`
>
> URL=file:///`pwd`/test-repo
>
> rm -rf test-repo test-repo-wc
>
> echo ""
> echo "### Creating empty test repository..."
> ${SVNADMIN} create test-repo
> echo ""
>
> echo "### Checking out working copy of empty repository..."
> ${SVN} co -q ${URL} test-repo-wc
> echo ""
>
> echo "### Creating/adding file subdir/abc.txt in working copy..."
> mkdir test-repo-wc/subdir
> echo "This sucks." > test-repo-wc/subdir/abc.txt
> ${SVN} add --parents test-repo-wc/subdir/abc.txt
> echo ""
>
> echo "### Committing changes to repository..."
> ${SVN} ci -m "file added" test-repo-wc
> echo ""
>
> echo "### Adding file to changelist test..."
> ${SVN} changelist test test-repo-wc/subdir/abc.txt
> echo ""
>
> echo "### Adding line to file..."
> echo 'It does.' >> test-repo-wc/subdir/abc.txt
> echo ""
>
> echo '### Output of "svn diff --changelist test" in root of working copy:'
> ( cd test-repo-wc ; ${SVN} diff --changelist test )
> echo ""
>
> echo '### Output of "svn diff --changelist test" in directory subdir:'
> echo "### (except for the path name, this diff should be identical to the
> previous,"
> echo " but there is no output at all in Subversion 1.12.2)"
> ( cd test-repo-wc/subdir ; ${SVN} diff --changelist test )
> echo ""
>
> --- >% ---
>
> The last diff has no output. This script works fine with Subversion 1.10.6.
>
> Is anyone able to reproduce this?
>
> Thanks,
> Tobias
>
> PS: I'm not subscribed to the mailing list, so please keep me CC'd.
>
>
>

Re: What comes after 1.12?

[Nathan Hartman]

On Tue, Aug 20, 2019 at 3:06 PM Branko Čibej  wrote:

> On 20.08.2019 20:50, Paul Hammant wrote:
> > If you all developed on trunk (patchsets for trunk, or direct to it),
> > and had an automated CI build setup that tested all permutations in
> > parallel, and a merging bot that attempted to cherry-pick commits
> > marked as [BUGFIX] back to all supported release branches without
> > human intervention (and Apache-TM votes), then you might have
> > streamlined things. Such a bot shouldn't shit the bed if the
> > cherry-pick fails *
>
> Duh. We have all that, except for the automated backport because no-one
> sane believes the word of *one* person that some [BUGFIX] commit is
> actually a viable candidate for any particular release branch. This is
> all documented in our community guide, which you'd be well advised to
> read before pontificating.
>

Yes. Someone definitely needs to LOOK at the "[BUGFIX]" commit first!

Re: Change to Subversion PMC rule for approving backports

[Nathan Hartman]

On Thu, Aug 29, 2019 at 11:36 AM Julian Foad  wrote:

>
> + A change needs three +1 votes (for an LTS release line) or one +1 vote
> (for a non-LTS release line) from full committers (or partial committers
> for the involved areas), and no vetoes, to go into A.B.x.

snip

- (If a change affects the build system, however, it is considered a
> core change, and needs three +1's.)
> + (If a change affects the build system, however, it is considered a
> core change, and so for an LTS release line needs three +1's.)


Just proofreading...

Is this 2nd change correct or was the intention three +1s for build system
changes regardless if LTS or not?

I'm asking because the 1st change already says that changes to LTS require
three +1s.

Re: Change to Subversion PMC rule for approving backports

[Nathan Hartman]

On Fri, Aug 30, 2019 at 2:54 AM Julian Foad  wrote:

> I strongly urge that we simplify any and all of our documentation at any
> opportunity. Nearly all of it is much too long. It would be much better
> to state the facts in a few bullet points, and move the discussion of
> rationale and history to a dedicated subsection so readers just wanting
> the facts can easily skip that part.
>

Which document would you consider most important to fix the soonest?

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

[Nathan Hartman]

On Mon, Sep 2, 2019 at 8:23 AM Julian Foad  wrote:

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


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

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

Re: buildbot failure in on svn-bb-openbsd

[Nathan Hartman]

On Mon, Sep 9, 2019 at 8:54 PM  wrote:
> The Buildbot has detected a new failure on builder svn-bb-openbsd
> while building . Full details are available at:
>https://ci.apache.org/builders/svn-bb-openbsd/builds/397

[snip]

> Blamelist: hartmannathan

Blame the new guy :-)

Seems related to the invocation of libtool shown on line 5781 of the
stdio log for step 3. I'd expect to see --mode=compile cc. Instead I
see --mode=compile none:

/bin/sh "/var/buildslave/svn-bb-openbsd/svn-trunk/libtool" --tag=CC --
silent --mode=compile none -D_POSIX_THREADS -DAPR_POOL_DEBUG=1 -
I/var/buildslave/svn-bb-openbsd/svn-
trunk/subversion/bindings/swig/ruby/libsvn_swig_ruby -
I./subversion/include -I./subversion -I/var/buildslave/svn-bb-
openbsd/prefix/apr/include/apr-1 -I/var/buildslave/svn-bb-
openbsd/prefix/apr/include/apr-1 -I/var/buildslave/svn-bb-
openbsd/prefix/bdb/include -I/var/buildslave/svn-bb-
openbsd/prefix/iconv/include -I/var/buildslave/svn-bb-
openbsd/prefix/bdb/include -I/var/buildslave/svn-bb-
openbsd/prefix/libmagic/include -I/var/buildslave/svn-bb-
openbsd/prefix/cyrus-sasl/include -I/var/buildslave/svn-bb-
openbsd/prefix/serf/include/serf-1 -I/var/buildslave/svn-bb-
openbsd/prefix/sqlite/include -I/usr/include -I/var/buildslave/svn-bb-
openbsd/prefix/lz4/include -o
subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.lo -c
subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.c/var/build
slave/svn-bb-openbsd/svn-trunk/libtool: none: not found

Re: Simplifying our documentation

[Nathan Hartman]

On Fri, Aug 30, 2019 at 11:09 AM Julian Foad  wrote:
> Nathan Hartman wrote in thread "Change to Subversion PMC rule for
> approving backports":
> > Julian Foad wrote:
> >> I strongly urge that we simplify any and all of our documentation at
any
> >> opportunity. Nearly all of it is much too long. It would be much better
> >> to state the facts in a few bullet points, and move the discussion of
> >> rationale and history to a dedicated subsection so readers just wanting
> >> the facts can easily skip that part.
> >
> > Which document would you consider most important to fix the soonest?
>
> In line with current transition to emphasise stabilization and
> availability, I suppose these user-facing docs should take priority:
>
>* finding/downloading/installing svn from *binaries*:
>  - http://subversion.apache.org/packages
>
>* how to contact us; reduce/combine some of these?
>  - http://subversion.apache.org/reporting-issues
>  - http://subversion.apache.org/docs/community-guide/issues
>  - http://subversion.apache.org/mailing-lists
>  - http://subversion.apache.org/docs/community-guide/mailing-lists
>  - http://subversion.apache.org/faq#more-information
>  - http://subversion.apache.org/security/
>
>* and the home page should make those things extremely easy to find:
>  - http://subversion.apache.org/
>
> If you or anyone wants to help, I think any of those would be an
> excellent place to do so.
>
> The various contact info is particularly scattered, and pointers often
> state "users@" email with no hint of the IRC/Matrix alternative. Could
> we make a good "contact us" landing page which directs users
> appropriately to all forms of contact?

I've been studying the site and there is a site-ng branch created 2015. I
remember a discussion about it around that time but I can't find it in the
archives now.

Since there are no commits on site-ng beyond branch creation / readme,
would it be agreeable if I catch it up to the present and use it?

Re: Simplifying our documentation

[Nathan Hartman]

On Thu, Sep 12, 2019 at 3:12 AM Branko Čibej  wrote:

> On 12.09.2019 05:00, Nathan Hartman wrote:
> > I've been studying the site and there is a site-ng branch created
> > 2015. I remember a discussion about it around that time but I can't
> > find it in the archives now.
> >
> > Since there are no commits on site-ng beyond branch creation / readme,
> > would it be agreeable if I catch it up to the present and use it?
>
> site-ng was a misguided attempt at changing how our site implementation
> works (from server-side includes to generated static pages). If we ever
> do that overhaul, we'll probably use the new templating automation that
> Infra is working on.
>
> I'd prefer to *delete* the site-ng branch. The staging branch is there
> for preparing content changes.
>
> -- Brane


I know about staging and it's convenient that it's served. But I'd like to
experiment without worrying about breaking things. I hope to achieve three
things:

* Reorganize the information so visitors find what they want with minimal
reading and searching

* A more modern look

* Improve display on mobile phones

I'd like to emphasize that I am *not* thinking about changing the
implementation (SSI vs something else) at this time. Nor am I thinking
about removing or rewriting the text. The information we have on the site
is good and thorough. I just want to reorganize it and make a good first
impression on visitors with an attractive home page -- and make sure we're
all happy with it before it moves to staging.

Thoughts?

Re: Simplifying our documentation

[Nathan Hartman]

On Thu, Sep 12, 2019 at 10:45 PM Branko Čibej  wrote:

> On 13.09.2019 04:18, Nathan Hartman wrote:
> > On Thu, Sep 12, 2019 at 3:12 AM Branko Čibej  > <mailto:br...@apache.org>> wrote:
> >
> > On 12.09.2019 05:00, Nathan Hartman wrote:
> > > I've been studying the site and there is a site-ng branch created
> > > 2015. I remember a discussion about it around that time but I can't
> > > find it in the archives now.
> > >
> > > Since there are no commits on site-ng beyond branch creation /
> > readme,
> > > would it be agreeable if I catch it up to the present and use it?
> >
> > site-ng was a misguided attempt at changing how our site
> > implementation
> > works (from server-side includes to generated static pages). If we
> > ever
> > do that overhaul, we'll probably use the new templating automation
> > that
> > Infra is working on.
> >
> > I'd prefer to *delete* the site-ng branch. The staging branch is
> there
> > for preparing content changes.
> >
> > -- Brane
> >
> >
> > I know about staging and it's convenient that it's served. But I'd
> > like to experiment without worrying about breaking things. I hope to
> > achieve three things:
> >
> > * Reorganize the information so visitors find what they want with
> > minimal reading and searching
> >
> > * A more modern look
> >
> > * Improve display on mobile phones
> >
> > I'd like to emphasize that I am *not* thinking about changing the
> > implementation (SSI vs something else) at this time. Nor am I thinking
> > about removing or rewriting the text. The information we have on the
> > site is good and thorough. I just want to reorganize it and make a
> > good first impression on visitors with an attractive home page -- and
> > make sure we're all happy with it before it moves to staging.
>
> Oh, then sure, either use site-ng or create another branch, whatever
> suits you best. The only (minor) issue is that you'll have to cook up a
> local server for testing. Or of course we could ask Infra nicely to
> publish yet another branch of our site.
>
> -- Brane


That's the easy part. I have a virtual machine with a LAMP stack. :-)

Once there's actually something to show we can cross the bridge of either
asking Infra (nicely of course) or moving it to a subdirectory of staging,
with a link to coming soon, preview the new site. But let's not get ahead
of ourselves.

Re: Simplifying our documentation

[Nathan Hartman]

On Fri, Sep 13, 2019 at 3:08 AM Branko Čibej  wrote:

> On 13.09.2019 09:00, Julian Foad wrote:
> > Nathan Hartman wrote:
> >> Once there's actually something to show we can cross the bridge of
> either asking Infra (nicely of course) or moving it to a subdirectory of
> staging, with a link to coming soon, preview the new site. But let's not
> get ahead of ourselves.
> >
> > That all sounds good. Just one thing: a new branch that is a sibling of
> 'publish' and 'staging' would seem to be the right level. The existing
> 'site-ng' branch contains virtual copies of both, which seems the wrong
> level, and also catching up and re-purposing an old branch makes slightly
> confusing (and slightly inefficient) history. Create a new one!
>
> Yes indeed ... and maybe even create a copy of staging/, not publish/,
> to make future merge history clearer.
>
> -- Brane
>
> Yes. I reached this conclusion also when I ran the merge and realized that
this is a branch that contains branches. So I didn't commit that mess.

If there are no objections I'll remove site-ng and create a branch from
staging called staging-ng. I think it should be under site, adjacent to
staging and publish, and not under subversion root?

Re: Simplifying our documentation

[Nathan Hartman]

On Fri, Sep 13, 2019 at 8:21 AM Julian Foad  wrote:

> Are you on Matrix or IRC? It's easier to continue this kind of
> conversation there, if you are. Freenode #svn-dev, or
> https://matrix.to/#/#freenode_#svn-dev:matrix.org


Haven't reached my desk yet today. I'm emailing from my phone. :-)

Re: Simplifying our documentation

[Nathan Hartman]

On Fri, Sep 13, 2019 at 8:18 AM Branko Čibej  wrote:
> On 13.09.2019 14:16, Nathan Hartman wrote:
>> If there are no objections I'll remove site-ng and create a branch
>> from staging called staging-ng. I think it should be under site,
>> adjacent to staging and publish, and not under subversion root?
>
> Yes, that's correct.

Deleted site-ng in r1866904.

Added site/staging-ng in r1866905.

Re: Subversion 1.13.0-rc1 up for testing/signing

[Nathan Hartman]

On Mon, Sep 23, 2019 at 12:33 PM Julian Foad  wrote:
>
> Julian Foad wrote:
> > The 1.13.0-rc1 release artifacts are now available for testing/signing.
> > Please get the tarballs from
> >https://dist.apache.org/repos/dist/dev/subversion
> > and add your signatures there.
>
> Is anyone going to be able to help get the 1.13 release under way?
>
> Please?
>
> Is there anything I can do to make it easier?
>
> - Julian

Apologies for my silence lately.

I have been backlogged but started running tests today.

Re: Subversion 1.13.0-rc1 up for testing/signing

[Nathan Hartman]

On Tue, Sep 24, 2019 at 2:22 AM Johan Corveleyn  wrote:
> Contents of subversion-1.13.0-rc1.zip are identical to tags/1.13.0-rc1,
> and to branches/1.13.x@1867053 (except for expected differences in
> svn_version.h and svnpubsub, svnwcsub and nominate.pl (symlinks vs. file
> contents), and generated files).

What do you use to compare the tarball contents to a working copy?

Re: Subversion 1.13.0-rc1 up for testing/signing

[Nathan Hartman]

On Fri, Sep 27, 2019 at 3:41 AM Johan Corveleyn  wrote:
>
> On Fri, Sep 27, 2019 at 2:54 AM Nathan Hartman  
> wrote:
> > What do you use to compare the tarball contents to a working copy?
>
> Ah, good question :-).

Thank you for your very detailed answer, including the time zone.

Yes, it's much easier on *nix with a command like:

$ TZ=UTC bash -c 'svn export
https://svn.apache.org/repos/asf/subversion/tags/1.13.0-rc1'

Thanks again

Re: Subversion 1.13.0-rc1 up for testing/signing

[Nathan Hartman]

On Tue, Sep 17, 2019 at 10:17 AM Julian Foad  wrote:
>
> The 1.13.0-rc1 release artifacts are now available for testing/signing.
> Please get the tarballs from
>https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.

Please bear with me and all my n00b questions... :-)

The ASF committer keys list (https://people.apache.org/keys/committer/)
is showing my key as "key not found." Not really sure what to do about
that.

Also, some ASF help page (that I can't seem to locate now) said I need
to add my key to a KEYS file. Not sure where that is.

I've signed the bz2 and gz tarballs and am ready to commit my sigs;
should I wait until after fixing the above issue(s)?

Re: Subversion 1.13.0-rc1 up for testing/signing

[Nathan Hartman]

On Tue, Sep 17, 2019 at 10:17 AM Julian Foad  wrote:
>
> The 1.13.0-rc1 release artifacts are now available for testing/signing.
> Please get the tarballs from
>https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.

Signed! 1.13.0-rc1
+1 to release

Tested on *nix platforms:
* Debian GNU/Linux 10 "Buster" x64
* macOS 10.13.6 "High Sierra" x64

Verified contents, signatures, and checksums:
* subversion-1.13.0-rc1.tar.bz2:
  - Compared contents to tags/1.13.0-rc1; identical except generated files.
  - Verified signature
  - Verified SHA-512
* subversion-1.13.0-rc1.tar.gz:
  - All contents identical to those of subversion-1.13.0-rc1.tar.bz2.
  - Verified signature
  - Verified SHA-512

Test details, Debian GNU/Linux 10 "Buster" x64:
* Tests:
  - fsfs, file | svn | http: 2528 PASSED, 98 SKIPPED, 89 XFAILED
  - swig-python passed
  - swig-perl passed
* Dependencies:
  - APR 1.6.5
  - APRUTIL 1.6.1
  - Serf 1.3.9
  - Swig 3.0.12
  - Python 2.7.16
  - Perl 5.28.1

Test details, macOS 10.13.6 "High Sierra" x64:
* Tests:
  - fsfs, file | svn: 2526 PASSED, 98 SKIPPED, 91 XFAILED
* Dependencies:
  - APR 1.6.3
  - APRUTIL 1.6.1

Signatures added to https://dist.apache.org/repos/dist/dev/subversion
in r36099.

Signature, subversion-1.13.0-rc1.tar.bz2:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEP45GfLM2bjAT4RINWD8ArfmBw58FAl2OHcoACgkQWD8ArfmB
w594VRAAn/tGgpsMQW24ra4t2yx8IdbdivED90Zybl8RXqXlMdwZsH2bfNrtloZw
BbnVKJZde5rT+sGh3bwdoMlKzfvhyds7V+lM9UPzeJg7T3GnYmqr1qgbwPsD9PMy
JjMz27WmoA/QP1H+kYW0Flo2f3HGZf3e9eawwHNeh7qk6GBwS2MCxm8PXLpchiLZ
BvxMVNDtYbJGA9ktEG1lCxEX3wdDJ4wbpqFIKOC2o2L/U27oV0vOKYK5VVmuJL56
wYACqtbRR6oGRHAmBWHhpPs3rcVXnzzHKNSs2pf6Zh4egyL/yVckoyTi1MHoyAh/
R5w1YQAbij/w+U5b91fFAei+i3oPJSP2PhO41X2i5p3MTJptv8FwIJQhHnWWfo48
lUYG87krk4uZCszJQoK4d/UlLlupiIh+ydPpSC4j/7jnXB5tpgr9gcfP6uqdVaXo
c07wFUxOtxrE9hWDgVHYqDaPWx8zQwZ8dVbL32oMLS3kz87pJe19Sny6q4TIXG9M
XhetvXI1uQbCU4nSm+H1GInF7IEcUhE75OwhRLByg2MAxHyuKfi0CEqned5zZxTZ
Nz3IxVcUr/wuAxkpPUJ5MsUsaIqNWDfkC23RWwxwvGX9KPDz19chbPEpZmKcna76
IxJUIF3PCPRJ/Wk5NFJo6HnwF6DVqoWRFUseSZyK2LLjLCxqn84=
=b/yD
-END PGP SIGNATURE-

Signature, subversion-1.13.0-rc1.tar.gz:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEP45GfLM2bjAT4RINWD8ArfmBw58FAl2OHfsACgkQWD8ArfmB
w5+NuxAAmjtupcsM5Hrf/oRiFmijy+7YcFmPCWWwn5RJ8vQpuc9nNQE/2NxV+tYr
kpbTlfbvxGgJ2bgChmLKKR0EoEQtp4hSkz+1BM/P4q5qW33FR1+qf3c9grHJwAx6
TU8SwKsGkBk3bw7ZF3Ho5qTU3akehio1dOnjHr/UAX3PeQ1j8Wa7/N0lQ6um67cE
plWXH3iLSL72jOXvIVFXN7Kkp6LkWv0W2/gqwItheJAYgsJ04QnYYGWXH5K5gIGV
XtrUwKn7YWypo5dmarpmOfz9Kp9HdE8gp8P5xiFphD5G3bfrMLnCq3UEtbHL4nLu
fDPbeyVbt/Xe6ieTuvNmmGUGeR6BxQsYYUOIKaQkuOEQjbBGxTGYtg2yxpFVE+KI
K8Wv0Gfcnfg8QCpd/E1zIxBiePOpSoy3vyYXoVIwH4ozm2ELcfzvSa8wQK05+TnE
lmjsqrU/fKiIV5gZcVSrdRsrvUFC0j/ULrsqtWnCp1/otb95TI58tpjWm2gAT4Yt
uSSpUuM3zEY+V3H97AyMuz2CEYhwECthUVf6e7zwoMTMXb3bdwv5lRR6bzW1qnJl
HNCpupaGZuihh0ZmRyHuPoYk9P08qVR7XGhH7GBxqAd5H9uU+P7SrH7MEyY1JhrS
HkwpBcQPZi+nRwb0DZWo5+mFi+40lobF4PMfK8v9n9m9fFNOqfY=
=lZAJ
-END PGP SIGNATURE-

Re: Simplifying our documentation

[Nathan Hartman]

On Fri, Sep 13, 2019 at 9:40 AM Nathan Hartman  wrote:
> Deleted site-ng in r1866904.
>
> Added site/staging-ng in r1866905.Regarding the site/staging-ng branch:

Regarding the site/staging-ng branch:

In the past, I've used two files from html5boilerplate.com:
normalize.css and main.css for other projects.

html5boilerplate is under a MIT license:
https://github.com/h5bp/html5-boilerplate/blob/master/LICENSE.txt

Can this (or snippets from it) be used for Subversion's website?

(Asking because one of my objectives is better display on mobile.)

Re: Simplifying our documentation

[Nathan Hartman]

On Sun, Sep 29, 2019 at 11:56 AM Daniel Shahaf  wrote:
>
> Nathan Hartman wrote on Sun, 29 Sep 2019 15:48 +00:00:
> > html5boilerplate is under a MIT license:
> > https://github.com/h5bp/html5-boilerplate/blob/master/LICENSE.txt
> >
> > Can this (or snippets from it) be used for Subversion's website?
>
> Yes.  https://www.apache.org/legal/resolved#category-a

Thank you.

Re: Link to KEYS file on our download page

[Nathan Hartman]

Nathan Hartman wrote:
> The ASF committer keys list (https://people.apache.org/keys/committer/)
> is showing my key as "key not found." Not really sure what to do about
> that.

I checked again and my key is found now. :-)

> Also, some ASF help page (that I can't seem to locate now) said I need
> to add my key to a KEYS file. Not sure where that is.

Well this answers that question!

If there's anything else I need to do, please let me know.

Re: Link to KEYS file on our download page

[Nathan Hartman]

On Wed, Oct 2, 2019 at 1:32 PM Daniel Shahaf  wrote:
> Nathan Hartman wrote on Wed, 02 Oct 2019 15:41 +00:00:
> > If there's anything else I need to do, please let me know.
>
> For bonus points, get your key cross-signed and linked to the web of trust :)

Agreed. I am keeping an eye out for key signing opportunities...

Re: PMCs: any Hackathon requests? (deadline 11 October)

[Nathan Hartman]

On Mon, Oct 7, 2019 at 5:13 AM Julian Foad  wrote:
> Moving this thread to dev@ as it should be public [1].

Sally Khudairi  wrote:
> We received an email from hackCBS 2.0, a hackathon that will be
> taking place 19-20 October at the University of Delhi with 700+
> students.
>
> They are interested in our participation by providing a list of
> tasks from various Apache projects for them to work on.
>
> If you would like to submit a list of work areas, please let me
> know your interest and forward your list(s) no later than 11
> October.

We should take advantage of this hackathon request. We should do the
same for any opportunity to increase participation!

Since there will be 700+ university participants, there may be a
variety of different skill sets, but we don't know what they are.

Let's make a list of 2 or 3 items, each from a different skill area.

Perhaps:
* 1 "byte size" code quality issue from the issue tracker
* 1 website task
* 1 Py3 support task

Byte size issue tracker task: Some suggestions were already made but
are not a good fit for several reasons. Let's suggest other ones. I'll
go first again: https://issues.apache.org/jira/browse/SVN-1722 "svn
diff may missreport a revision as the working copy."

Website task: Johan suggests the website overhaul and Julian suggests
a subtask of that. I think that's a good idea. The task I suggest is
to incorporate normalize.css and main.css from html5boilerplate.com
and improve the navigation bar to make the static pages mobile
friendly.

Python 3 support task: I think something Python-related should be on
the list. How about https://issues.apache.org/jira/browse/SVN-2079
"utf8_tests.py should be made non-iso8859-1 specific"

Thoughts? Other items we should consider?

Nathan

Issue tracker review [was: PMCs: any Hackathon requests? (deadline 11 October)]

[Nathan Hartman]

On Mon, Oct 7, 2019 at 11:13 AM Julian Foad  wrote:
> Nathan Hartman wrote:
> > https://issues.apache.org/jira/browse/SVN-1722 "svn
> > diff may missreport a revision as the working copy."
>
> Errm... last reviewed 9 years ago.  Is it really what it says it is?
>
> Sadly, we have hundreds of unreviewed (or not recently reviewed) open
> issues.  Some are misleadingly labeled "bite-sized" but are really
> symptoms of deeper problems.  Can we take this opportunity to do
> something about that?  Like, maybe start bringing one old issue to the
> dev list for review each week?

I'll be happy to do that.

I like the idea of tackling one a week because that is manageable and
allows developers and interested parties enough time to look at the
issue and give their opinions.

SVN-1722 can be the first one. I'll start looking into it myself a
little later today.

Re: PMCs: any Hackathon requests? (deadline 11 October)

[Nathan Hartman]

On Mon, Oct 7, 2019 at 10:49 AM Nathan Hartman  wrote:
> Since there will be 700+ university participants, there may be a
> variety of different skill sets, but we don't know what they are.
>
> Let's make a list of 2 or 3 items, each from a different skill area.
>
> Perhaps:
> * 1 "byte size" code quality issue from the issue tracker
> * 1 website task
> * 1 Py3 support task

I think we have our website task:
> to incorporate normalize.css and main.css from html5boilerplate.com
> and improve the navigation bar to make the static pages mobile
> friendly.

Now can we please have some more suggestions for a "byte size"
issue and a Python-related task?

Reminder: We must reply to the hackathon request this week!

Re: PMCs: any Hackathon requests? (deadline 11 October)

[Nathan Hartman]

On Wed, Oct 2, 2019 at 5:43 PM Sally Khudairi  wrote:
> Hello PMCs --I hope you are well.
>
> We received an email from hackCBS 2.0, a hackathon that will be taking place 
> 19-20 October at the University of Delhi with 700+ students.
>
> They are interested in our participation by providing a list of tasks from 
> various Apache projects for them to work on.
>
> If you would like to submit a list of work areas, please let me know your 
> interest and forward your list(s) no later than 11 October.
>
> Many thanks,
> Sally
>
> - - -
> Vice President Marketing & Publicity
> Vice President Sponsor Relations
> The Apache Software Foundation
>
> Tel +1 617 921 8656 | s...@apache.org

We are basically out of time.

Unless there are any reasonable objections, I propose to reply to
Sally's email with the following.

I've taken into account everything that was discussed previously,
incorporated Johan's and Daniel's suggested tasks, removed the ones
that Julian pointed out are a bad idea, need review, or are pending a
design, etc.

Please speak up with any improvements as soon as possible!

If I hear nothing to the contrary, I'll assume silence = agreement
and reply to Sally (with CC to this list) at 12:00 AM GMT.

Proposed message follows:

[[[

Dear Sally,

We have opportunities for the 2-day hackathon across several skill set
areas including: web design, documentation, swig bindings, Python, and
C programming:


* Web design on https://subversion.apache.org:

  - Incorporate normalize.css and main.css from html5boilerplate.com.

  - Improve the navigation bar to make the static pages mobile
friendly, while keeping the site in a form that can be
hand-edited.

* Documentation:

  - SVN-3914 - INSTALL: document how to compile with libmagic on
Windows.
https://issues.apache.org/jira/browse/SVN-3914?issueNumber=3914

* Python programming:

  - Implement linking with libmagic on Windows in the build scripts.

* Swig bindings:

  - SVN-4781 - expose svn_fs_change_rev_prop2() to swig.
https://issues.apache.org/jira/browse/SVN-4781?issueNumber=4781

  - SVN-4568 - expose svn_fs_set_warning_func() to swig.
https://issues.apache.org/jira/browse/SVN-4568?issueNumber=4568

* C programming:

  - SVN-4343 - FSFS backend work: "svnadmin verify" should verify
changed-paths list.
https://issues.apache.org/jira/browse/SVN-4343?issueNumber=4343

  - SVN-4605 - "svnadmin verify" doesn't verify locks.
https://issues.apache.org/jira/browse/SVN-4605?issueNumber=4605


Hackathon participants should join our 'dev' mailing list and introduce
themselves. To join, email dev-subscr...@subversion.apache.org -- see
https://subversion.apache.org/mailing-lists.html for details.

We'll be happy to provide whatever guidance we can, as well as review
and (hopefully) apply some quality patches!

If you have any questions, please let us know by emailing
dev@subversion.apache.org!

Kind regards,
The Apache Subversion PMC

]]]

Re: PMCs: any Hackathon requests? (deadline 11 October)

[Nathan Hartman]

On Thu, Oct 10, 2019 at 1:15 PM Daniel Shahaf  wrote:
>
> Nathan Hartman wrote on Thu, Oct 10, 2019 at 10:24:28 -0400:
> > * Documentation:
> >
> >   - SVN-3914 - INSTALL: document how to compile with libmagic on
> > Windows.
> > https://issues.apache.org/jira/browse/SVN-3914?issueNumber=3914
>
> This is a subtask of the next one, isn't it?

I separated them because one is documentation, the other is Python
programming. I tried to keep things organized by skill set. Also SVN-3914
didn't actually include updating the scripts (unless I missed something).

Should these be re-merged into one item, as you had it before?

> > We'll be happy to provide whatever guidance we can, as well as review
> > and (hopefully) apply some quality patches!
> >
>
> I wonder how many participants we're excluding here just by using a dated
> expression such as "apply patches", as opposed to "merge a pull request"… ;-)

Is applying a patch really such a strange concept these days? I
participate in some projects that use Git and take as many patches as
they do pull requests.

We can include the github link but there was a whole discussion here
about how pull requests were sitting there untouched, and there was no
clean way to accept them and have them marked as such. Has that been
fixed? If not, I'd rather avoid the confusion that would cause. Let me
know...

Thanks,
Nathan Hartman

Re: PMCs: any Hackathon requests? (deadline 11 October)

[Nathan Hartman]

On Thu, Oct 10, 2019 at 1:48 PM Daniel Shahaf 
wrote:

> Nathan Hartman wrote on Thu, 10 Oct 2019 17:36 +00:00:
> > On Thu, Oct 10, 2019 at 1:15 PM Daniel Shahaf 
> wrote:
> > >
> > > Nathan Hartman wrote on Thu, Oct 10, 2019 at 10:24:28 -0400:
> > > > * Documentation:
> > > >
> > > >   - SVN-3914 - INSTALL: document how to compile with libmagic on
> > > > Windows.
> > > > https://issues.apache.org/jira/browse/SVN-3914?issueNumber=3914
> > >
> > > This is a subtask of the next one, isn't it?
> >
> > I separated them because one is documentation, the other is Python
> > programming. I tried to keep things organized by skill set. Also SVN-3914
> > didn't actually include updating the scripts (unless I missed something).
> >
> > Should these be re-merged into one item, as you had it before?
>
> That depends.  _Do_ the Windows build scripts support libmagic?
>

Good question. I've never built SVN on Windows, only Unix, so I don't
actually know. I can look at the build scripts but if someone knows the
answer to this please chime in!!

More below

> We can include the github link but there was a whole discussion here
> > about how pull requests were sitting there untouched, and there was no
> > clean way to accept them and have them marked as such. Has that been
> > fixed? If not, I'd rather avoid the confusion that would cause. Let me
> > know...
>
> Sure, there's no point in recommending a patch submission channel that's
> not easy for us to work with.  However, there's a third option: post the
> github link but ask patches to be emailed.  (We should probably just add
> the link to HACKING, though, in that case; it's not specific to this
> event.)


We could do that and monitor github during the event in case some
participants don't notice the request to mail patches.

But we should eventually figure out a better solution for that submission
channel.

Re: PMCs: any Hackathon requests? (deadline 11 October)

[Nathan Hartman]

On Thu, Oct 10, 2019 at 1:48 PM Daniel Shahaf  wrote:
> > Should these be re-merged into one item, as you had it before?
>
> That depends.  _Do_ the Windows build scripts support libmagic?

I think they don't. Unless I missed something.

It looks as though the Windows build uses the makefile at
tools/dev/windows-build/Makefile. I am guessing that packagers for the
Windows platform are using this as their starting point? Anyway, this
makefile makes absolutely no mention of libmagic.

I'll merge the two items into one:

* Python programming:

  - SVN-3914 - Implement building with libmagic on Windows in the build
scripts and document it in INSTALL.
https://issues.apache.org/jira/browse/SVN-3914?issueNumber=3914

Nathan