On Mar 4, 2018, at 5:28 AM, Stefan Sperling wrote:
>
>> On Sat, Mar 03, 2018 at 09:08:41PM -0500, Nathan Hartman wrote:
>> Does this mean that content being committed to the repository is never elided
>> based on the SHA hash alone but only after a fulltext verification that the
>> content actual
On Sun, Mar 04, 2018 at 11:12:00AM +, Philip Martin wrote:
> Stefan Sperling writes:
>
> > Yes. And if the content differs, it must be rejected, because an FSFS
> > repository can only store one content per SHA1 checksum.
>
> To be accurate the server-side code can handle the files perfectly
Myria writes:
> How can I dump out the two things that Subversion thinks have the same
> SHA-1 checksum but don't match? This seems to be rather difficult to do.
On the server side:
svnlook cat repository path-in-repository
svnlook cat -r N repository path-in-repository
svnlook cat -t TX
Stefan Sperling writes:
> Yes. And if the content differs, it must be rejected, because an FSFS
> repository can only store one content per SHA1 checksum.
To be accurate the server-side code can handle the files perfectly well
if rep-caching is disabled. One can retreive either file, dump/load
How can I dump out the two things that Subversion thinks have the same
SHA-1 checksum but don't match? This seems to be rather difficult to do.
That said, it's far more likely that there's a bug in Subversion than that
we randomly collided SHA-1.
On Sun, Mar 4, 2018 at 02:29 Philip Martin wrote
Nathan Hartman writes:
> Does this mean that content being committed to the repository is never
> elided based on the SHA hash alone but only after a fulltext
> verification that the content actually already exists in the
> repository?
That's correct. Fulltext matching was added in 1.9.6 and 1.
On Sat, Mar 03, 2018 at 09:08:41PM -0500, Nathan Hartman wrote:
> On Mar 2, 2018, at 6:16 PM, Philip Martin wrote:
> >
> > Since the file being committed matched a SHA1 in the rep-cache the
> > commit process will attempt to remove this delta but will first verify
> > that the fulltext obtained b
