One of our Subversion 1.9 users is encountering a slow SSL handshake (or
maybe even subsequent connection) to a Jetty 7.6.16.v20140903 server.
This happens on Windows and OSX. Interestingly, when using Subversion
1.7, access works fast as expected. Also, accessing the same URL using
curl or fro
On 27.01.2016 09:35, Johan Corveleyn wrote:
On Tue, Jan 26, 2016 at 8:26 PM, Corey Meyer wrote:
Howdy, I have a repository that I have multi-users updating and committing to
and from. Sadly my machine can’t commit. Since updating from SmartSVN7 to
SmartSVN9 I get a number of errors depending
On 16.03.2015 16:34, Branko Čibej wrote:> On 16.03.2015 15:58, Marc
Strapetz wrote:
From my experiments with Subversion 1.9 binaries and the listed
changes in the release notes, Subversion 1.9 seems to be backwards
compatible with Subversion 1.8 working copies. Is that correct?
There are
From my experiments with Subversion 1.9 binaries and the listed changes
in the release notes, Subversion 1.9 seems to be backwards compatible
with Subversion 1.8 working copies. Is that correct? If so, it makes
sense to update the "Upgrading the Working Copy" section:
https://subversion.apache
On 27.11.2013 11:32, Bert Huijben wrote:
>
>
>> -Original Message-----
>> From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
>> Sent: woensdag 27 november 2013 09:30
>> To: Philip Martin
>> Cc: Branko Čibej; users@subversion.apache.org
>>
On 26.11.2013 21:38, Philip Martin wrote:
> Marc Strapetz writes:
>
>>>>> As far as I have been told, this has already been fixed and backported
>>>>> to 1.8.5. Still, for those users which already have this corruption, is
>>>>> there
On 26.11.2013 18:27, Branko Čibej wrote:
> On 26.11.2013 18:08, Philip Martin wrote:
>> Marc Strapetz writes:
>>
>>> We are encountering working copies with
>>>
>>> nodes.presence = moved and nodes.moved_to =
>> What does "nodes.presence = m
We are encountering working copies with
nodes.presence = moved and nodes.moved_to =
As far as I have been told, this has already been fixed and backported
to 1.8.5. Still, for those users which already have this corruption, is
there a way to recover their working copies with standard Subversion
One of our users encounters a strange order of log revisions. When
invoking an:
svn log -v -g
the top-level revision r1605930 is reported before top-level revision
r2571860. In my understanding, this should not be possible. For a log
without merged revisions included, the order is fine. How can
nflict_action_delete || action ==
svn_wc_conflict_action_replace)
D:\svntest\small-1.7-1>svn --version
svn, version 1.7.0 (r1176462)
compiled Oct 12 2011, 16:57:34
--
Best regards,
Marc Strapetz
=
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
On 07.09.2011 17:02, Bert Huijben wrote:
>
>
>> -Original Message-----
>> From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
>> Sent: woensdag 7 september 2011 14:40
>> To: users@subversion.apache.org
>> Subject: 1.7.0-rc2: abnormal program termination
al
way.
Please contact the application's support team for more information.
--
Best regards,
Marc Strapetz
=
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
12 matches
Mail list logo