On 03.08.2020 15:19, Johan Corveleyn wrote:
On Mon, Aug 3, 2020 at 2:44 PM Marc Strapetz wrote:
>> ...
>>
D:\temp\tiny.dir.svn>svn x-shelve shelf1
--- Shelve 'shelf1' in WC root 'D:/temp/tiny.dir.svn'
--- Shelving...
Updating '.svn\experimental\shel
0cbe10e07301c114c
actual: b89724a2cec6a05364bb3af4c74fd452
Tested on Windows 8.1 with Subversion 1.14.0 (built ourselves).
--
Best regards,
Marc Strapetz
=
syntevo GmbH
http://www.syntevo.com
On 25.06.2019 23:35, Branko Čibej wrote:> On 25.06.2019 19:15, Thomas
Singer wrote:
What I don't like:
- after more than a decade the umlaut problem of composed/decomposed
UTF-8 has not been solved
It has, actually, in Apple's APFS, where the fix belongs.
That sounds interesting. Just to be s
On 10.01.2018 02:44, Philip Martin wrote:
Marc Strapetz writes:
Marc, please let us know if you learnt any more about this problem.
Unfortunately we didn't make progress here since my posting.
I have just fixed a bug in the JavaHL implementation of SSL trust
prompting, see r182071
earnt any more about this problem.
Thanks,
- Julian
Marc Strapetz wrote:
One of our users is encountering following exception:
svn: Java exception
svn: Wrapped Java Exception
at org.apache.subversion.javahl.remote.RemoteFactory.open
(Native Method)
One of our users is encountering following exception:
svn: Java exception
svn: Wrapped Java Exception
at org.apache.subversion.javahl.remote.RemoteFactory.open
(Native Method)
at org.apache.subversion.javahl.remote.RemoteFactory.openRemoteSession
(RemoteFactory.java:228)
...
Caused by:
On 24.05.2017 19:59, Branko Čibej wrote:
On 24.05.2017 19:37, Branko Čibej wrote:
On 24.05.2017 12:19, Marc Strapetz wrote:
I have following Apache virtual host configuration which contains a
redirect:
RedirectMatch 301 ^/svntest/(.*)$ /svntests/$1
DAV svn
SVNParentPath /misc
I have following Apache virtual host configuration which contains a
redirect:
RedirectMatch 301 ^/svntest/(.*)$ /svntests/$1
DAV svn
SVNParentPath /misc/svntests
...
When trying to access a redirected repository from command line, this
works fine:
$ svn ls https://host/s
We have been requested to support
svn blame -x "--ignore-eol-style -w"
for our Java client. AFAIU, this is currently not possible using JavaHL?
If so, please take this as RFE: --extensions options support for blame,
diff and related operations.
-Marc
On 25.11.2015 17:04, Bert Huijben wrote:
-Original Message-
From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
Sent: woensdag 25 november 2015 16:09
To: Branko Čibej ; dev@subversion.apache.org
Subject: Re: JavaHL: "Not implemented" error in StatusEditor.addAbsent
On
One of our users is reporting frequent clean up errors:
svn: E720032: Can't remove
'C:\Project\Path\To\WorkingCopy\.svn\tmp\svn-30D0973'
svn: E720032: Can't remove file
'C:\Project\Path\To\WorkingCopy\.svn\tmp\svn-30D0973': Det går inte att
komma åt filen eftersom den används av en annan process
On 25.11.2015 10:43, Branko Čibej wrote:
On 25.11.2015 09:49, Marc Strapetz wrote:
One of our users has reported following Exception against Subversion
1.9.2:
Caused by: java.lang.RuntimeException: Not implemented:
StatusEditor.addAbsent
at
One of our users has reported following Exception against Subversion 1.9.2:
Caused by: java.lang.RuntimeException: Not implemented:
StatusEditor.addAbsent
at
org.apache.subversion.javahl.remote.StatusEditor.addAbsent(StatusEditor.java:110)
... 15 more
Actually, StatusEditor.addAbsent
On 12.10.2015 13:49, Bert Huijben wrote:
-Original Message- From: Marc Strapetz
[mailto:marc.strap...@syntevo.com] Sent: maandag 12 oktober 2015
13:37 To: Bert Huijben ; dev@subversion.apache.org
Subject: Re: svn status API and missing switched flag
The old behavior makes sense if
On 12.10.2015 12:31, Bert Huijben wrote:
-Original Message-
From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
Sent: maandag 12 oktober 2015 10:56
To: dev@subversion.apache.org
Subject: svn status API and missing switched flag
Consider following working copy for which directory &quo
Consider following working copy for which directory "dir" is switched:
$ svn status -v
814 813 marc .
S 814 813 marc dir
814 356 strapetz dir\sub.txt
Now, when invoking "svn status" in sub-directory "dir", the "switche
We have just received following bug report which shows an impossible
stack trace:
java.io.IOException: No space left on device
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(Unknown Source)
at
org.apache.subversion.javahl.remote.
On 14.08.2015 11:21, Philip Martin wrote:
Marc Strapetz writes:
It's reproducible with an empty repository on the server (just
initialized with svnadmin) and a local repository which has been
prepared for the initial import:
C:\temp\svn> svn status -v
0
On 14.08.2015 00:20, Branko Čibej wrote:
On 13.08.2015 13:32, Marc Strapetz wrote:
On 27.07.2015 09:21, Branko Čibej wrote:
On 27.07.2015 09:17, Marc Strapetz wrote:
One of our 1.9 (early-access) users is reporting problems when
performing remote commands, for example a copy URL->
On 27.07.2015 09:21, Branko Čibej wrote:
On 27.07.2015 09:17, Marc Strapetz wrote:
One of our 1.9 (early-access) users is reporting problems when
performing remote commands, for example a copy URL->URL:
org.apache.subversion.javahl.ClientException: Stream doesn't support
this capabi
On 27.07.2015 09:21, Branko Čibej wrote:
On 27.07.2015 09:17, Marc Strapetz wrote:
One of our 1.9 (early-access) users is reporting problems when
performing remote commands, for example a copy URL->URL:
org.apache.subversion.javahl.ClientException: Stream doesn't support
this capabi
One of our 1.9 (early-access) users is reporting problems when
performing remote commands, for example a copy URL->URL:
org.apache.subversion.javahl.ClientException: Stream doesn't support
this capability
Bad file descriptor
svn: Polling for available data on filestream failed: Bad file descri
Starting with Subversion 1.9, as part of the SmartSVN build process we
are also creating Subversion command line binaries (client-side only)
which we are now providing as separate download for Windows (32 bit
only) and OSX. Windows binaries are built in a Windows 7 VM with the
minimum requireme
On 19.05.2015 16:40, Bert Huijben wrote:
-Original Message-
From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
Sent: dinsdag 19 mei 2015 15:59
To: dev@subversion.apache.org
Subject: JavaHL: ClientNotifyCallback reports unexpected kind "file" for
symlinks
When recursivel
When recursively adding a directory "test" which contains another
directory "sub" and a symlink "sub.link" pointing to "sub", "sub.link"
is reported with kind=file where I would expect to receive kind=symlink.
The problem can be reproduced by following code snippet, using quite
recent 1.9 binar
On 29.04.2015 17:44, Branko Čibej wrote:
On 29.04.2015 17:03, Branko Čibej wrote:
On 29.04.2015 16:02, Branko Čibej wrote:
On 29.04.2015 11:57, Marc Strapetz wrote:
On 29.04.2015 05:31, Branko Čibej wrote:
On 28.04.2015 21:22, Bert Huijben wrote:
-Original Message-
From: Marc
On 29.04.2015 05:31, Branko Čibej wrote:
On 28.04.2015 21:22, Bert Huijben wrote:
-Original Message-
From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
Sent: dinsdag 28 april 2015 20:26
To: Branko Čibej
Cc: Subversion Development
Subject: Re: 1.9 JavaHL memory leak in ISVNRemote
On 28.04.2015 20:06, Marc Strapetz wrote:
On 28.04.2015 18:12, Branko Čibej wrote:
On 28.04.2015 18:03, Marc Strapetz wrote:
Hi Brane,
On 28.04.2015 07:36, Branko Čibej wrote:
On 24.04.2015 14:11, Branko Čibej wrote:
Hi Marc,
Just a quick note: your last msg jogged my memory and I think I
On 28.04.2015 18:12, Branko Čibej wrote:
On 28.04.2015 18:03, Marc Strapetz wrote:
Hi Brane,
On 28.04.2015 07:36, Branko Čibej wrote:
On 24.04.2015 14:11, Branko Čibej wrote:
Hi Marc,
Just a quick note: your last msg jogged my memory and I think I know
the root cause of the leak: improper
emove the
close-stream requirement I just added.
On 24 Apr 2015 11:00 am, "Marc Strapetz" mailto:marc.strap...@syntevo.com>> wrote:
On 24.04.2015 06 :34, Branko Čibej wrote:
On 22.03.2015 05 :06, Branko Čibej wrote:
On 21.03.2015 16 :23, Branko Čibej wrote
To allow users to browse through all contents of a file (as part of an
interactive blame), it's necessary to have an efficient API to retrieve
these file contents.
AFAIU, the low-level file_rev_handler already provides this information
via svn_txdelta_window_handler_t. Unfortunately, in Remote
On 24.04.2015 06:34, Branko Čibej wrote:
On 22.03.2015 05:06, Branko Čibej wrote:
On 21.03.2015 16:23, Branko Čibej wrote:
On 19.03.2015 11:43, Marc Strapetz wrote:
Attached example performs an endless series of remote status against
the Subversion repository. When invoked with -Xmx24M, the
On 23.04.2015 16:59, Julian Foad wrote:
Marc Strapetz wrote:
Using copy with the new metadataOnly option (through the API) only allows to
"move" or "copy" a missing file onto an unversioned file. It could also be
helpful to copy/move metadata from a removed (or replaced)
On 23.04.2015 16:01, Branko Čibej wrote:
On 22.04.2015 20:28, Marc Strapetz wrote:
Using copy with the new metadataOnly option (through the API) only
allows to "move" or "copy" a missing file onto an unversioned file. It
could also be helpful to copy/move metadata from a
cleanup-related code which is working fine with 1.8 JavaHL starts
failing with 1.9 JavaHL.
According to the docs, ISVNClient#cleanup(String) does not break locks,
which seems to cause the problems:
/**
* Recursively cleans up a local directory, finishing any
* incomplete operations, r
On 23.04.2015 11:27, Stefan Sperling wrote:
On Wed, Apr 22, 2015 at 07:58:35PM +0200, Marc Strapetz wrote:
$ svn proplist -r2 -R -v ^/
...
Properties on 'file://localhost/D:/temp/externals/repo/dst/dir':
svn:externals
^/ext@1 ext
$ svn proplist -r1 -R -v ^/
...
Propertie
Using copy with the new metadataOnly option (through the API) only
allows to "move" or "copy" a missing file onto an unversioned file. It
could also be helpful to copy/move metadata from a removed (or replaced)
source to an already added (or replaced) target.
Use case 1: the user has removed
After invoking following series of commands:
svnadmin create repo
svn checkout file://localhost/d:/temp/externals/repo wc
mkdir wc
cd wc
mkdir ext
touch ext\file
mkdir src\dir
svn add *
svn propset svn:externals "^/ext ext" src
svn propset svn:externals "^/ext@1 ext" src\dir
For a working copy which has been checked out using SVN 1.8, "svn info"
output is slightly different between version 1.8 and 1.9 -- for 1.9 the
local *dir* is missing.
For 1.8:
$ svn info a/b
Path: a\b
Name: b
Repository Root: ...
Repository UUID: ...
Node Kind: none
Schedule: normal
Tree conf
On 16.03.2015 17:54, Bert Huijben wrote:
-Original Message-
From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
Sent: maandag 16 maart 2015 17:30
To: dev@subversion.apache.org
Subject: JavaHL: Exceptions in LogMessageCallback.singleMessage should abort
the log immediately
If e.g
Attached example performs an endless series of remote status against the
Subversion repository. When invoked with -Xmx24M, the VM will run out of
memory soon. Monitoring with jvisualvm shows that the used heap size
constantly grows. Monitoring with the Task Manager shows that the
allocated memo
On 17.03.2015 13:28, Marc Strapetz wrote:
We are currently faced with the decision whether to release a new
"major" version of SmartSVN which is compatible with Subversion 8 or
wait for Subversion 9 release. The two main factors driving this
decision are:
(i) whether Subversion 1.9 wi
We are currently faced with the decision whether to release a new
"major" version of SmartSVN which is compatible with Subversion 8 or
wait for Subversion 9 release. The two main factors driving this
decision are:
(i) whether Subversion 1.9 will be able to access Subversion 1.8 working
copies
ecked
ProgressCancelledExceptions.
-Marc
On 16.03.2015 17:54, Bert Huijben wrote:
-Original Message-
From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
Sent: maandag 16 maart 2015 17:30
To: dev@subversion.apache.org
Subject: JavaHL: Exceptions in LogMessageCallback.singleMessage should abor
If e.g. a RuntimeException is thrown in
LogMessageCallback#singleMessage, it's not processed in
LogMessageCallback::singleMessage and the log is continued nevertheless:
(1) At line 77 in LogMessageCallback.cpp, there should be returned an
appropriate error code.
(2) After line 122, JNIUtil::
Since SmartSVN has been switched from SVNKit to JavaHL (in version 8.5),
we have a quite large amount of users complaining about problems with
special characters in file names on Mac OSX.
This is in particular a problem for SmartSVN, because SVNKit was
automatically converting to composed form
On 16.03.2015 01:50, Bert Huijben wrote:
-Original Message-
From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
Once the log responds, a bunch of revisions are reported, so it seems
that there is some kind of caching of log records.
I've tested with latest 1.9.x sources on Wi
hen results+detailed are spooled back the other way.
It's a standard youngest-to-oldest log; parameters for getLogs are
(paths, start-revision, end-revision, limit, ...).
The normal svn invocation you compare to is the most efficient one...
Bert
-
I'm experiencing a strange initial delay when performing a log using JavaHL.
svn log http://svn.apache.org/repos/asf/subversion/branches/1.8.x
shows first results after 2-3 seconds, while following code snippet
takes at least 20 seconds (sometimes significantly more, might depend on
the server
On 19.02.2014 16:06, Julian Foad wrote:
> Marc Strapetz wrote:
>> Julian Foad wrote:
>>> It looks like we have an agreement in principle. Would you like
>>> to file an enhancement issue?
>>
>> Great. I've filed an issue now:
>>
>>
On 18.02.2014 15:26, Julian Foad wrote:
> Marc Strapetz wrote:
>> On 17.02.2014 18:36, Julian Foad wrote:
>>> Marc Strapetz wrote:
>>>> Hence an API like the following should work well for us:
>>>>
>>>> interface Mergeinfo
On 17.02.2014 18:36, Julian Foad wrote:
> Marc Strapetz wrote:
>
>>> ... I'll dig into the cache code ...
>>
>> I did that now and the storage is quite simple: we have a main file
>> which contains the diff (added, removed) for every path in every
>> r
On 14.02.2014 14:18, Marc Strapetz wrote:
>>> Can we think of a better way to design the API so that it returns the
>>> interesting data without all the redundancy? Basically I think we want to
>>> describe changes to mergeinfo, rather than raw mergeinfo.
>>
&g
>> Can we think of a better way to design the API so that it returns the
>> interesting data without all the redundancy? Basically I think we want to
>> describe changes to mergeinfo, rather than raw mergeinfo.
>
> Marc,
>
> Perhaps a better way to ask the question is: Can I encourage you to wr
On 14.02.2014 11:38, Julian Foad wrote:
> Marc Strapetz wrote:
>> For SmartSVN we are optionally displaying merge arrows in the Revision
>> Graph. Here is a sample image, how this looks like:
>>
>> http://imgur.com/MzrLq00
>>
>>> From the JavaHL sources
For SmartSVN we are optionally displaying merge arrows in the Revision
Graph. Here is a sample image, how this looks like:
http://imgur.com/MzrLq00
>From the JavaHL sources I understand that there is currently only one
method to retrieve server-side mergeinfo and this one works on a single
revisi
For SmartSVN, we are looking for a way to support multiple credentials
(username and password) for the same realm. When using the command line
client, --username will do the job, however this option is not well
suited for a GUI client. Here, a quite flexible as well as intuitive
approach would be t
On 12.09.2011 11:15, Philip Martin wrote:
> Marc Strapetz writes:
>
>> There are some problems when capitalization of a file or directory name
>> changes in the working copy (at least on Windows). I'm starting off with
>> following tree:
>>
>
ect
working with case-changed entries at all to avoid mentioned problems?
Instead the user could be told to fix the file name case changes or the
client does that automatically (like TSVN does for SVN 1.6).
--
Best regards,
Marc Strapetz
=
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
60 matches
Mail list logo
