On Mon, Jun 15, 2015 at 1:20 PM, Julian Foad
wrote:
> My understanding of the situation is as follows. I'm not adding much
> to what Philip and Stefan have already diagnosed, I just want to say
> how I see it as well, and allow others to confirm it or correct me if
> necessary.
>
[snip insightfu
My understanding of the situation is as follows. I'm not adding much
to what Philip and Stefan have already diagnosed, I just want to say
how I see it as well, and allow others to confirm it or correct me if
necessary.
First we need to be clear about 'change' and 'difference'. There has
been some
On Fri, Jun 12, 2015 at 8:38 PM, Branko Čibej wrote:
> 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 al
+1.
Just noting that only -g appears to be affected, while I don’t know if the
server side change also affects non -g. If non -g was optimized while it didn't
affect clients we should try to keep that part.
Instead of announcing a client side capabilty that is transfered for every ra
operati
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
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
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
Branko Čibej writes:
> I think there's no doubt that the 1.9 server has to send no-op deltas
> the same way the 1.8 server did. Changing an API should not affect
> server behaviour as seen by the clients.
A simple testcase:
svnadmin create repo --compatible-version 1.8
svnmucc -mm -U file://`pw
On 09.06.2015 21:31, Philip Martin wrote:
> Philip Martin writes:
>
>> The 1.9 server is sending the same revisions as the 1.8 server but some
>> of the revisions from the 1.9 server do not have a textdelta. Both the
>> 1.8 and 1.9 servers call svn_repos_get_file_revs2() which calls
>> send_path_
Philip Martin writes:
> The 1.9 server is sending the same revisions as the 1.8 server but some
> of the revisions from the 1.9 server do not have a textdelta. Both the
> 1.8 and 1.9 servers call svn_repos_get_file_revs2() which calls
> send_path_revision(). Inside send_path_revision() the 1.8
Philip Martin writes:
> $ ../../svn/svn blame -g
> svn-test-work/working_copies/blame_tests-10/trunk/iota
>2jrandom This is the file 'iota'.
>2jrandom 'A' has changed a bit, with 'upsilon', and 'xi'.
>
> while the 1.9 client gives the correct output:
>
> $ svn blame -g sv
11 matches
Mail list logo
