Re: Blame behaviour change in 1.9

2015-06-12 Thread Philip Martin
Philip Martin writes: > 1.9 has a more accurate svn_fs_contents_changed() that doesn't report as > many false positives. This means that some (or all?) of the -g revisions > reported by svn_repos_get_file_revs2() do not include a textdelta that > was included by 1.8. It appears at some level the

Re: svn commit: r1682265 - /subversion/trunk/subversion/libsvn_fs_fs/util.c

2015-06-12 Thread Stefan Fuhrmann
On Fri, May 29, 2015 at 4:54 PM, Evgeny Kotkov wrote: > Stefan Fuhrmann writes: > > > However, it does not tell you anything about consistency with outside > > parties, say some svnsync'ed repository. The problem is that Windows may > > end up not persisting the rename (of e.g. the 'current' fil

Re: Efficient and effective fsync during commit

2015-06-12 Thread Stefan Fuhrmann
On Fri, May 29, 2015 at 6:23 PM, Ivan Zhakov wrote: > On 29 May 2015 at 18:55, Stefan Fuhrmann > wrote: > > On Fri, May 29, 2015 at 4:14 PM, Ivan Zhakov wrote: > >> On 28 May 2015 at 20:47, Stefan Fuhrmann > wrote: > >>> Hi all, > >>> > >>> Most of us would agree that way we fsync FS changes >

Re: Blame behaviour change in 1.9

2015-06-12 Thread Philip Martin
Philip Martin writes: > Philip Martin writes: > >> 1.9 has a more accurate svn_fs_contents_changed() that doesn't report as >> many false positives. This means that some (or all?) of the -g revisions >> reported by svn_repos_get_file_revs2() do not include a textdelta that >> was included by 1.8

Re: Blame behaviour change in 1.9

2015-06-12 Thread Branko Čibej
On 12.06.2015 16:55, Philip Martin wrote: > Philip Martin writes: > >> Philip Martin writes: >> >>> 1.9 has a more accurate svn_fs_contents_changed() that doesn't report as >>> many false positives. This means that some (or all?) of the -g revisions >>> reported by svn_repos_get_file_revs2() do n