RE: No-op changes no longer dumped by 'svnadmin dump' in 1.9

2015-10-27 Thread bert
But as Julian and Branko pointed out Subversion's update operation works on calculating deltas over the actual changes. Seeing non-changes as changes there introduces unwanted behavior. Going back to the old code that assumes something is changed in these cases + in some unknown/undocumented/un

RE: No-op changes no longer dumped by 'svnadmin dump' in 1.9

2015-10-27 Thread Bert Huijben
Summarizing a few mental notes: Broken behavior (1 revision to the direct next/previous) · Replay / svnadmin dump (svnadmin dump is tightly integrated with replay. Svnrdump works on top of replay) · Log Mostly caused by having the old behavior for years… never intended/desig

Re: svn commit: r1710631 - in /subversion/trunk/subversion: include/svn_fs.h libsvn_fs/fs-loader.c libsvn_repos/repos.c tests/svn_test_fs.c

2015-10-27 Thread Ivan Zhakov
On 26 October 2015 at 22:33, Bert Huijben wrote: >> -Original Message- >> From: Ivan Zhakov [mailto:i...@visualsvn.com] >> Sent: maandag 26 oktober 2015 19:37 >> To: dev@subversion.apache.org; Bert Huijben >> Subject: Re: svn commit: r1710631 - in /subversion/trunk/subversion: >> include/

Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9

2015-10-27 Thread Ivan Zhakov
On 27 October 2015 at 04:52, Johan Corveleyn wrote: > Bert, > > As the OP of this mail-thread, which spun out of the discovery of a > loss of information by 'dump' in 1.9 [1], I'd like to add some things. > > I found out about this problem during the Berlin hackathon, when I > tested various dumpe

Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9

2015-10-27 Thread Evgeny Kotkov
Bert Huijben writes: > But this 'go back to 1.8' suggestio changes Subversion everywhere. It will > make 'svn annotate' slower... Makes 'svn update' slower and report more tree > conflicts, etc. etc. For 'svn blame', the only difference is that we would be processing no-op changes in file histor

RE: No-op changes no longer dumped by 'svnadmin dump' in 1.9

2015-10-27 Thread Bert Huijben
> -Original Message- > From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com] > Sent: dinsdag 27 oktober 2015 14:38 > To: Bert Huijben > Cc: Johan Corveleyn ; Stefan Fuhrmann > ; Julian Foad > ; dev > Subject: Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9 > In 1.9 we

Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9

2015-10-27 Thread Julian Foad
Evgeny Kotkov wrote: > Bert Huijben writes: >> But this 'go back to 1.8' suggestio changes Subversion everywhere. It will >> make 'svn annotate' slower... Makes 'svn update' slower and report more tree >> conflicts, etc. etc. > > For 'svn blame', the only difference is that we would be processing

Re: svn commit: r1703689 - in /subversion/trunk/subversion: libsvn_client/merge.c tests/cmdline/merge_automatic_tests.py

2015-10-27 Thread Branko Čibej
On 26.10.2015 16:03, Ivan Zhakov wrote: > On 18 September 2015 at 00:00, wrote: >> Author: rhuijben >> Date: Thu Sep 17 21:00:36 2015 >> New Revision: 1703689 >> >> URL: http://svn.apache.org/viewvc?rev=1703689&view=rev >> Log: >> Following up on r1703688 fix conflicts reported on merging deletes

Re: svn commit: r1703689 - in /subversion/trunk/subversion: libsvn_client/merge.c tests/cmdline/merge_automatic_tests.py

2015-10-27 Thread Branko Čibej
On 27.10.2015 20:48, Branko Čibej wrote: > On 26.10.2015 16:03, Ivan Zhakov wrote: >> Do you know why we do not convert eol style/collapse keywords for >> special files? I know that it's not related to this commit, but may be >> you know rationale behind this behavior. > The contents of special fil