And figure
> > out some details.
>
> Will that be Subversion 18.04 Anticlimactic Albatross?
>
>
> -- Brane
>
--
Jacek Materna
Chief Technology Officer
Assembla
+1 210 410 7661
> > >
> > If you ask people comfortable with donating code via PR to email patches
> > (or similar) to dev@ instead, you'll get a 1/100th contribution rate. Or
> > worse.
> >
> > There's no easy answer.
>
> Couldn't some automated process mail PRs from github as (--git) diffs to
> dev@?
>
--
Jacek Materna
Chief Technology Officer
Assembla
+1 210 410 7661
that make LZ4 the new default compression
> algorithm, I think that option (2) is better. The reasoning here is that
> using LZ4 compression would improve the performance even for existing
> repositories by making new commits faster and by speeding up read
> operations for the new committed files. Apart from this, option (3)
> needs implementation and is probably going to have a couple of related
> challenges, which can be otherwise avoided.
>
> With all that in mind, I propose that we do (2). Any objections?
>
>
> Thanks,
> Evgeny Kotkov
>
--
Jacek Materna
Chief Technology Officer
Assembla
+1 210 410 7661
PM, Andreas Stieger
> <andreas.stie...@gmx.de> wrote:
>> The openSUSE project has 1.10 alpha3 binaries ready for all current
>> openSUSE and SUSE Linux Enterprise distributions.
>>
>> https://software.opensuse.org//download.html?project=home%3AAndreasStieger%3Abranches%3Adevel%3Atools%3Ascm%3Asvn=subversion
>>
>> Andreas
>
> Great, thanks Andreas!
>
> --
> Johan
--
Jacek Materna
Chief Technology Officer
Assembla
+1 210 410 7661
ignificant for large repos. Is it feasible to
> get the best of both worlds by using LZ4 for fast commits and then
> recompress using zlib in svnadmin pack?
--
Jacek Materna
Chief Technology Officer
Assembla
+1 210 410 7661
On Tue, Jul 25, 2017 at 6:39 AM, Daniel Shahaf wrote:
> Good morning Evgeny,
>
> First of all, thanks for the well written response.
>
> Evgeny Kotkov wrote on Mon, 24 Jul 2017 19:19 +0300:
>> Daniel Shahaf writes:
>> > I'm a bit uncomfortable
ch can be acceptable
>> for temp folders – but never for backend storage, of course).
>>
>>
>>
>> And I also guess the speed difference is more siginificant if there are
>> several concurrent accesses, so the I/O operations overlap. A single SVN
>> backend
On Thu, Jul 13, 2017 at 9:36 AM, Johan Corveleyn wrote:
>
> On Thu, Jul 13, 2017 at 8:27 AM, Branko Čibej wrote:
> > On 13.07.2017 04:07, Paul Hammant wrote:
> >> I flipped _back_ to Python's requests.put(..) in my solution - from a
> >> regular Svn client.
Fair enough!
Rest looks great.
--
Jacek Materna
Assembla
CTO
+1 210 410 7661
+48 578 296 708
Sent from my Mobile Device
> On Jul 7, 2017, at 5:47 PM, Evgeny Kotkov <evgeny.kot...@visualsvn.com> wrote:
>
> Jacek Materna <ja...@assembla.com> writes:
>
>> Shoul
th colliding SHA-1 hash values, we suggest you transform it
> via gzip before committing it to avoid the collision altogether. Moreover,
> an upgrade to 1.9.6 to prevent future insertion of duplicates is highly
> recommended.
> ]]]
>
>
> Regards,
> Evgeny Kotkov
--
Jacek Materna
CTO
Assembla
+1 210 410 7661
+48 578 296 708
ave it tuned the max via the metrics above.
Most of the real world use cases require the default settings so curl, etc
isn't seen a lot in the wild.
Overall Dav and http is a poor transport in general for SVN.
Hope it helps.
--
Jacek Materna
Assembla
CTO
+1 210 410 7661
+48 578 296 708
ible deltas at all,
> doesn't mean that Svn doesn't attempt to make its own determination. I
> wasn't using .bin suffixes as it happens but I'll bet there's something in
> amongst mimetypes and suffixes somewhere that allows skipping.
>
> -ph
>
> On Thu, Jul 6, 2017 at 8:07 AM, J
_dav --> mod_dav_svn handoff does
> the 512MB temporarily manifest itself in a file system on the way to its
> ultimate destination? Is 1/10th speed the expectation? Sure, I get that
> 7bit/8bit shenanigans are a factor, but not that much right?
>
> - Paul
>
>
--
Jacek Materna
CTO
Assembla
+1 210 410 7661
+48 578 296 708
Is there a general GA or BETA timeframe/date on the roadmap for the
1.10 rls? Trying to understand timeline.
thanks-
On Mon, May 22, 2017 at 10:56 PM, Johan Corveleyn wrote:
> On Tue, May 9, 2017 at 1:21 PM, Johan Corveleyn wrote:
>> On Tue, Apr 4, 2017 at 11:33 AM, Stefan Sperling wrote:
>>> On Mon, Feb 20, 2017 at 09:05:25AM +0100, Bert Huijben wrote:
On Sun, May 14, 2017 at 1:59 PM, Stefan Fuhrmann
<stefanfuhrm...@alice-dsl.de> wrote:
> On 09.05.2017 20:43, Stefan Sperling wrote:
>>
>> On Mon, May 08, 2017 at 10:46:39AM +0200, Jacek Materna wrote:
>>>
>>> Team,
>>>
>>> I wanted
tacking this
topic around work flow preservation. Thanks Daniel.
On Mon, May 15, 2017 at 2:37 PM, Johan Corveleyn <jcor...@gmail.com> wrote:
> On Thu, May 11, 2017 at 4:03 PM, Jacek Materna <ja...@assembla.com> wrote:
>> On Thu, May 11, 2017 at 10:14 AM, Stefan Sperling &l
?
>
> They use github :)
On Thu, May 11, 2017 at 1:04 AM, Johan Corveleyn <jcor...@gmail.com> wrote:
> On Tue, May 9, 2017 at 3:32 PM, Jacek Materna <ja...@assembla.com> wrote:
>> Just observing from afar, in my opinion the root of what you are
>> trying to achieve here t
For review.
best.
-j
On Wed, May 10, 2017 at 10:52 AM, Jacek Materna <ja...@assembla.com> wrote:
> Correct. #2 is moot given the rejection strategy moving forward.
>
> On Tue, May 9, 2017 at 6:12 PM, Daniel Shahaf <d...@daniel.shahaf.name>
> wrote:
>>
>> Jace
Correct. #2 is moot given the rejection strategy moving forward.
On Tue, May 9, 2017 at 6:12 PM, Daniel Shahaf <d...@daniel.shahaf.name>
wrote:
> Jacek Materna wrote on Tue, May 09, 2017 at 14:39:51 +0200:
> > On Tue, May 9, 2017 at 2:12 PM, Daniel Shahaf <d...@daniel.sh
Looks great Stefan - will review and work on the FAQ patch this week.
On Tue, May 9, 2017 at 8:43 PM, Stefan Sperling <s...@elego.de> wrote:
> On Mon, May 08, 2017 at 10:46:39AM +0200, Jacek Materna wrote:
> > Team,
> >
> > I wanted to start a discussion around t
t;
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
--
Jacek Materna
CTO
Assembla
210-410-7661
ion focused around beta-testing 1.10 (in that case, maybe we
> should call the next 1.10 pre-release a "beta" instead of an "alpha"
> -- otherwise the announcement on our website might be a bit weird:
> "Subversion 1.10 alpha 3 has been released. Please test and report
> your feedback on beta-users@s.a.o" :-))
>
> --
> Johan
--
Jacek Materna
CTO
Assembla
210-410-7661
Hi,
On Tue, May 9, 2017 at 2:12 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote:
> Jacek Materna wrote on Mon, May 08, 2017 at 10:46:39 +0200:
>> Team,
>>
>> I wanted to start a discussion around the FAQ (and 1.10 rls. notes) as it
>> pertains to the SHA-1 issue
have become a lot more painful
> than they used to be. I don't think this is going to be a good sell.
--
Jacek Materna
CTO
Assembla
210-410-7661
inst known
collisions. While this will not guarantee protection from new collisions,
we will keep the hook up-to date as new collisions are publicly released.
The hook can be found here:
https://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/reject-known-sha1-collisions.sh
<<<<<<<<
Best.
--
Jacek Materna
CTO
Assembla
210-410-7661
Great! Will do - thanks for the guidance-
-j
On Thu, May 4, 2017 at 1:53 PM, Johan Corveleyn <jcor...@gmail.com> wrote:
> On Thu, May 4, 2017 at 12:34 PM, Jacek Materna <ja...@assembla.com> wrote:
> > Agreed - let me looking in Stefan's mods - I can take a look at the
il.com> wrote:
> On Tue, May 2, 2017 at 3:21 PM, Jacek Materna <ja...@assembla.com> wrote:
> > Great to hear on 1.10 move along.
> >
> > On SHA1 I can help if you feel it may move things along in parallel - we
> > ended up having to use the pre-commit hook for ou
r focus again on releasing 1.10, and
> > get the improvements it brings in the hands of users.
>
> I agree!
>
> I was one of the people pushing for more SHA1 fixes but I did not find
> time to do any of that work myself. I will not object if we decide that
> these changes will have to happen later on. We do not seem to have enough
> resources to push more SHA1 fixes through right now. So let's do whatever
> else we can get done instead.
>
--
Jacek Materna
CTO
Assembla
210-410-7661
29 matches
Mail list logo