On Tue, May 09, 2017 at 06:48:03PM +0200, Johan Corveleyn wrote:
> If needed, admins
> can (re-)enable rep-sharing for an existing repository (as long as a
> collision hasn't been committed yet), right?
Sure. However, any content committed while rep-sharing was
disabled will not be considered
On Tue, May 09, 2017 at 12:27:40PM -0400, Mark Phippard wrote:
> From the best I can tell we have no plan on how or when we could support
> this in the working copy. I have also seen a lot of people express
> interest in the hook scripts to block the sha1 collisions and not any real
>
On Tue, May 9, 2017 at 6:27 PM, Mark Phippard wrote:
> On Tue, May 9, 2017 at 12:08 PM, Stefan Sperling wrote:
>>
>> On Tue, May 09, 2017 at 03:44:22PM +, Daniel Shahaf wrote:
>> > Stefan Sperling wrote on Tue, May 09, 2017 at 15:25:23 +0200:
>> > > This
On Tue, May 9, 2017 at 12:08 PM, Stefan Sperling wrote:
> On Tue, May 09, 2017 at 03:44:22PM +, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Tue, May 09, 2017 at 15:25:23 +0200:
> > > This could be further extended by the config knob to give users a
> choice.
> > > I
On Tue, May 09, 2017 at 03:44:22PM +, Daniel Shahaf wrote:
> Stefan Sperling wrote on Tue, May 09, 2017 at 15:25:23 +0200:
> > This could be further extended by the config knob to give users a choice.
> > I don't see a good way of adding such a knob in a patch release, though.
>
> Just give
Stefan Sperling wrote on Tue, May 09, 2017 at 15:25:23 +0200:
> This could be further extended by the config knob to give users a choice.
> I don't see a good way of adding such a knob in a patch release, though.
Just give the knob a name that indicates it's not forward compatible?
For
+1 on rejection.
On Tue, May 9, 2017 at 3:37 PM, Mark Phippard wrote:
> On Tue, May 9, 2017 at 9:25 AM, Stefan Sperling wrote:
>>
>> On IRC, Branko and Johan raised concerns about the proposed backport.
>>
>> The proposed backport allows files with SHA1
On Tue, May 9, 2017 at 9:25 AM, Stefan Sperling wrote:
> On IRC, Branko and Johan raised concerns about the proposed backport.
>
> The proposed backport allows files with SHA1 collisions into the repository
> and avoids de-duplication of such content by the rep-cache. It fixes the
On Tue, May 09, 2017 at 01:39:49PM +0200, Stefan Sperling wrote:
> On Tue, May 09, 2017 at 11:38:51AM +0200, Stefan Sperling wrote:
> > On Tue, Apr 18, 2017 at 12:54:20AM +, Daniel Shahaf wrote:
> > > % svnadmin load r2 < dump
> > > <<< Started new transaction, based on original revision 1
>
Stefan Sperling wrote on Thu, Mar 30, 2017 at 19:40:10 +0200:
> Should we disable ra_serf's callback for fetching content from the
> pristine store instead of from the repository when SHA1 matches?
> This could be done without a format change.
On IRC today, Johan and I both think that that
On Tue, May 09, 2017 at 11:38:51AM +0200, Stefan Sperling wrote:
> On Tue, Apr 18, 2017 at 12:54:20AM +, Daniel Shahaf wrote:
> > % svnadmin load r2 < dump
> > <<< Started new transaction, based on original revision 1
> > * editing path : shattered-1.pdf ... done.
> > * editing path
On Tue, Apr 18, 2017 at 12:54:20AM +, Daniel Shahaf wrote:
> % svnadmin load r2 < dump
> <<< Started new transaction, based on original revision 1
> * editing path : shattered-1.pdf ... done.
> * editing path : shattered-2.pdf ...svnadmin: E200014: Checksum mismatch
> for
Daniel Shahaf wrote on Tue, Apr 18, 2017 at 00:54:20 +:
> Incidentally: the error code added in r1785754 is misspelled:
> SVN_ERR_FS_AMBIUGOUS_CHECKSUM_REP should be
> SVN_ERR_FS_AMBIGUOUS_CHECKSUM_REP.
> ---^^
>
> Not only in the error message, also in the code.
s/error
Stefan Fuhrmann wrote on Mon, Apr 17, 2017 at 22:17:46 +0200:
> On 30.03.2017 21:38, Daniel Shahaf wrote:
> >Let's use jira or moinmoin to track all the different issues that need
> >looking into? I count at least fsfs, fsx, svnadmin load, libsvn_wc, and
> >zhakov's change that Bert mentioned.
>
On 30.03.2017 21:38, Daniel Shahaf wrote:
Let's use jira or moinmoin to track all the different issues that need
looking into? I count at least fsfs, fsx, svnadmin load, libsvn_wc, and
zhakov's change that Bert mentioned.
What is the problem with 'svnadmin load'?
It uses SHA1 and MD5 to
Let's use jira or moinmoin to track all the different issues that need
looking into? I count at least fsfs, fsx, svnadmin load, libsvn_wc, and
zhakov's change that Bert mentioned.
(We can use SVN-4673 as a parent issue.)
On Thu, Mar 30, 2017 at 07:04:29PM +0200, Bert Huijben wrote:
> The server side fixes currently need a third vote for backporting. These
> fixes are nominated for 1.8.x and 1.9.x.
>
> I don’t think we can really do much more on the released versions without a
> backwards incompatible change to
: Progress on SHA-1 fixes in patch releases?
On Thu, Mar 30, 2017 at 06:30:55AM -0400, Paul Hammant wrote:
> My apologies. When I wrote "No patch releases though, right?" my intention
> was to communicate "No patch releases YET though, right?
There are no patch releases yet, no.
On Thu, Mar 30, 2017 at 06:30:55AM -0400, Paul Hammant wrote:
> My apologies. When I wrote "No patch releases though, right?" my intention
> was to communicate "No patch releases YET though, right?
There are no patch releases yet, no.
My apologies. When I wrote "No patch releases though, right?" my intention
was to communicate "No patch releases YET though, right?
-ph
On Thu, Mar 30, 2017 at 6:28 AM, Branko Čibej wrote:
> On 30.03.2017 12:26, Paul Hammant wrote:
> >> Eh? Patch release changelogs get
On 30.03.2017 12:26, Paul Hammant wrote:
>> Eh? Patch release changelogs get written when the patch is released.
> I'm not following what you're saying there.
The fact that there's no entry for 1.9.6 in CHANGES does not mean that
1.9.6 will not be released, nor does it mean that the hash
> Eh? Patch release changelogs get written when the patch is released.
I'm not following what you're saying there.
On 30.03.2017 12:01, Paul Hammant wrote:
> No patch releases though, right?
>
> http://svn.apache.org/repos/asf/subversion/trunk/CHANGES
Eh? Patch release changelogs get written when the patch is released.
No patch releases though, right?
http://svn.apache.org/repos/asf/subversion/trunk/CHANGES
Is that because, "the server can store the offending PDFs" isn't enough of
a releasable in its own right? Or because the "the server can store the
offending PDFs" specifically is imperfect and
On Thu, Mar 30, 2017 at 09:30:57AM +0100, Julian Foad wrote:
> Hi, devs. Re. the SHA-1 fixes contemplated or in-the-works for SVN 1.8 and
> 1.9: Any idea on how those are coming along and when they might see the
> light of day (in patch releases)?
>
> - Julian
>
As far as I can tell, these
Hi, devs. Re. the SHA-1 fixes contemplated or in-the-works for SVN 1.8
and 1.9: Any idea on how those are coming along and when they might see
the light of day (in patch releases)?
- Julian
26 matches
Mail list logo