Re: JavaHL problem with NativeException
Hi Daniel,
Thanks for the quick investigation. I would simplify the test:
@Test
public void testGetMessage() {
assertEquals("", new NativeException(null, null, null,
0).getMessage());
assertEquals("messagesvn: source: )apr_err=0)", new
NativeException("message", "source", null, 0).getMessage());
}
--
Best regards,
Thomas Singer
On 2022-07-16 22:49, Daniel Sahlberg wrote:
Den fre 15 juli 2022 kl 23:19 skrev Daniel Sahlberg <
daniel.l.sahlb...@gmail.com>:
Den fre 15 juli 2022 kl 10:46 skrev Thomas Singer <
thomas.sin...@syntevo.com>:
Hi SVN developers,
Hi Thomas,
Thanks for the detailed report!
First, there are 2 classes of NativeException, one in
org.tigris.subversion.javahl package, the other in
org.apache.subversion.javahl package. They only slightly differ in a
constructor parameter. I recommend to use one class with 2 constructors
instead.
I'm not experienced enough in the Java world to fully grasp this but I
assume the org.tigtis package is older and that it has been kept for
historical reasons (not to break an API used by older applications).
If you have a suggestion on how to consolidate this without breaking the
old API, feel free to send to the list!
Second, the getMessage() method might throw a NullPointerException in
the StringBuffer constructor if the NativeException was created with a
null message (happened for a user's bug report).
Alright. I've been working on making a test case for this and I believe
I've managed to reproduce your issue. I would like to sleep on it and
verify once more tomorrow.
Third, the usage of StringBuffer is discouraged in favor of StringBuilder.
Sounds good.
I recommend to change the code for NativeException from
public String getMessage()
{
StringBuffer msg = new StringBuffer(super.getMessage());
to
public String getMessage()
{
StringBuilder msg = new StringBuilder();
String message = super.getMessage();
if (message != null) {
msg.append(message);
}
I've implemented the above and I believe this also resolves the failure.
I believe I have everything covered with the patch below. @Thomas Singer
Can you check if this looks good and in
particular if it works for you? If you have the possibility, please also
run the javahl test suite in your environment to make sure I didn't screw
up anything else.
dev@: I would prefer to commit this in two separate commits, first the test
cases and second the fix. But I could not find any way to "XFail" the test
case. If I commit the tests as-is, they will fail. Obviously this will be
resolved in a second commit a few moments later but I'm reluctant to
intentionally screwing up the test suite. Is there something I'm missing or
should I commit as below?
[[[
Index:
subversion/bindings/javahl/src/org/apache/subversion/javahl/NativeException.java
===
---
subversion/bindings/javahl/src/org/apache/subversion/javahl/NativeException.java
(revision
1902721)
+++
subversion/bindings/javahl/src/org/apache/subversion/javahl/NativeException.java
(working
copy)
@@ -86,7 +86,11 @@
*/
public String getMessage()
{
-StringBuffer msg = new StringBuffer(super.getMessage());
+StringBuilder msg = new StringBuilder();
+String message = super.getMessage();
+if (message != null) {
+msg.append(message);
+}
// ### This might be better off in JNIUtil::handleSVNError().
String src = getSource();
if (src != null)
Index:
subversion/bindings/javahl/src/org/tigris/subversion/javahl/NativeException.java
===
---
subversion/bindings/javahl/src/org/tigris/subversion/javahl/NativeException.java
(revision
1902721)
+++
subversion/bindings/javahl/src/org/tigris/subversion/javahl/NativeException.java
(working
copy)
@@ -85,7 +85,11 @@
*/
public String getMessage()
{
-StringBuffer msg = new StringBuffer(super.getMessage());
+StringBuilder msg = new StringBuilder();
+String message = super.getMessage();
+if (message != null) {
+msg.append(message);
+}
// ### This might be better off in JNIUtil::handleSVNError().
String src = getSource();
if (src != null)
Index:
subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java
===
---
subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java
(revision
1902721)
+++
subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java
(working
copy)
@@ -27,6 +27,7 @@
import org.apache.subversion.javahl.callback.*;
import org.apache.subversion.javahl.re
SVN 1.14.1 slightly broken on Windows for working copies in drive root?
Hello, I have a working copy of the SVN repository at D:\src\svn. With SVN 1.14.1 binaries I'm getting following status output D:\src\svn>svn.exe status -u Status against revision: 1893746 When I create a 'substed' drive G: for that directory using D:\src\svn>subst g: D:\src\svn D:\src\svn>g: I'm getting following output (note the exclamation mark): G:\>C:\temp\svn\svn.exe status -u ! 1892650 . Status against revision: 1893746 Is this a known/already fixed regression? -- Best regards, Thomas Singer = syntevo GmbH www.syntevo.com
Re: JavaHL: SVNClient.copy throws not very helpful exception
Hi Karl, Thanks for the answer. Looks like this problem exists since >10 years... -- Best regards, Thomas Singer = syntevo GmbH www.syntevo.com On 2021-06-08 17:09, Karl Fogel wrote: On 08 Jun 2021, Thomas Singer wrote: Hi, A user wanted to copy a working copy to an URL and it fails with following exception: org.apache.subversion.javahl.ClientException: Wrong or unexpected property value svn: Commit failed (details follow): svn: Invalid property value at org.apache.subversion.javahl.SVNClient.copy(Native Method) at at com.syntevo.smartsvn.client.SuSvnClient.copyImpl(SuSvnClient:1225) ... Unfortunately, it is completely unclear what property value is rejected by SVN. How to fix the working copy to make the copy operation succeed? This is just a guess, but https://rt.cpan.org/Public/Bug/Display.html?id=52024 discusses how the value of the "svn:ignore" property (on a directory) can cause this, if that value uses non-LF line endings. So try investigating the values of that property wherever it is used? I agree that the error message you're getting is missing some useful information! Best regards, -Karl
JavaHL: SVNClient.copy throws not very helpful exception
Hi, A user wanted to copy a working copy to an URL and it fails with following exception: org.apache.subversion.javahl.ClientException: Wrong or unexpected property value svn: Commit failed (details follow): svn: Invalid property value at org.apache.subversion.javahl.SVNClient.copy(Native Method) at at com.syntevo.smartsvn.client.SuSvnClient.copyImpl(SuSvnClient:1225) ... Unfortunately, it is completely unclear what property value is rejected by SVN. How to fix the working copy to make the copy operation succeed? -- Best regards, Thomas Singer = syntevo GmbH www.syntevo.com
Re: Windows Build
Hi Alan, This reads for me just like setting up Ubuntu 20.04 in Virtualbox, but is not related to Subversion. Did you miss some Subversion-relevant steps at the end? BR Tom On 2021-02-18 19:47, Alan Fry wrote: On Wed, Feb 17, 2021 at 11:31 AM Nathan Hartman wrote: On Wed, Feb 17, 2021 at 11:12 AM Alan Fry wrote: For all that helped w/ the Linux build, thank you, I have a set of repeatable build instructions for Subversion on linux. If there is value, I'd be happy to post those. I verified those instructions last night, building from ground up a VM that builds and successfully runs 'make check'. Yes, please do! It will likely help others. Also perhaps others will chime in and offer suggestions on easier ways to do some things. Sure. For anyone who would like them, they are below. Note that I have not formatted them, so maybe soon I'll write up a nice html/markdown for them. start To generate a virtual machine that builds SVN Download iso: ubuntu-20.04.2-desktop-amd64.iso Create a new virtual machine in Virtualbox Name: SVN Build OS: Linux / Ubuntu 64bit 4096MB of ram virtual hard disk VDI (Virtualbox Disk image) Dymanic allocated Max 200g Select your VM and click settings: System tab: Deselect floppy Set to 4 processors Display Tab: Set video memory to 128k Start Select ubuntu-20.04.2-desktop-amd64.iso at boot At install complete, let the system reboot When it comes back up, install guest additions : $ sudo add-apt-repository multiverse $ sudo apt install virtualbox-guest-dkms virtualbox-guest-x11 restart machine Your VM machine is now setup. Log in as the user you have setup.
Re: preparing to release 1.14.1 and 1.10.7
Hi Johan, Yes, I mean those of Alex' patches that hang around in pending state since October. Thank you for reviewing them. I'm not sure whether other patches from Alex from August - [PATCH] Fix JavaHL crash in RequestChannel.nativeRead - [PATCH] Fix JavaHL crash in TunnelAgent.CloseTunnelCallback after GC or September - [PATCH] Fix JavaHL error in SVNBase::createCppBoundObject already were accepted. -- Best regards, Thomas Singer On 2021-01-27 10:45, Johan Corveleyn wrote: On Wed, Jan 27, 2021 at 10:30 AM Thomas Singer wrote: Please include Alexandr Miloslavskii's JavaHL fixes with SVN 1.14.1. Thanks in advance. Yep, working on it :-). I assume you're referring to the javahl-1.14-fixes branch, which he pointed to in the dev@ thread with subject "A series of JavaHL fixes on branch 'javahl-1.14-fixes'"? Or are there other fixes that slipped through the cracks? I agree we should try to get them in, if possible. I hope to wrap up my review today.
Re: preparing to release 1.14.1 and 1.10.7
Please include Alexandr Miloslavskii's JavaHL fixes with SVN 1.14.1. Thanks in advance. -- Best regards, Thomas Singer On 2021-01-22 14:36, Stefan Sperling wrote: I am volunteering to prepare release artifacts for new 1.14 and 1.10 releases soon. Hopefully, these artifacts will be up for testing and signing by the end of next week (January 29), to be released within the first two weeks of February. Please go through STATUS files on the 1.14.x and 1.10.x branches now and add your votes and any concerns about already nominated changes. If you have any outstanding changes that haven't been committed or nominated yet, they would need to be dealt with as soon as possible. I will try not to miss out on any fixes that are still brewing right now and could still make it into this next release. Anything not merged by end of next week is likely going to miss the boat and will have to wait for the next one. Though I will allow myself to merge any nominations which received at least two +1 votes and no vetoes. Thanks, Stefan
Re: Error E170013: The server unexpectedly closed the,connection.
Hi Daniel and Brane, Thanks for your feedback. I haven't heard back from the user whether your suggestions solved the problem. -- Best regards, Thomas Singer = syntevo GmbH www.syntevo.com On 2020-11-28 16:40, Branko Čibej wrote: On 27.11.2020 22:24, Daniel Sahlberg wrote: Den fre 27 nov. 2020 kl 20:45 skrev Thomas Singer mailto:thomas.sin...@syntevo.com>>: How valuable is the information that the user can access the SVN server from a browser? How to analyze/debug the access to find out at what stage it fails? Not a Mac guy myself, but I on Windows would suspect proxy configurations in the browser, application aware firewall that filter out requests from Subversion or some trickery with the https certificate chain. I would assume these are also possible on macOS. On corporate networks I have seen firewalls or transparent proxy servers that decrypt https traffic and filter based on for example user agent strings or usage patterns. It seems Wireshark is available for macOS so I would start there to make sure traffic is actually getting out of the box. Then working my way through the network to see where the packages are dropped. I concur, all of the above makes sense. -- Brane
Re: Error E170013: The server unexpectedly closed the,connection.
How valuable is the information that the user can access the SVN server from a browser? How to analyze/debug the access to find out at what stage it fails? -- Tom On 2020-11-27 9:27, Branko Čibej wrote: On 27.11.2020 07:18, Thomas Singer wrote: Hi, According to the user this error occurs now permanently on macOS 10.15 for him while in previous versions it only occurred sometimes with macOS 10.14/15, but not with 10.12/13. Just as a data point, I use svn-1.14 on macOS 10.15 all the time with no problems. But I can't even connect to port 443 on this server, there's no response, with or without Subversion. My guess would be that something is wrong with the configuration on the server end, it sure looks like it's just dropping packets. -- Brane
Re: Error E170013: The server unexpectedly closed the,connection.
Hi, According to the user this error occurs now permanently on macOS 10.15 for him while in previous versions it only occurred sometimes with macOS 10.14/15, but not with 10.12/13. -- Best regards, Thomas Singer On 2020-11-26 8:41, Thomas Singer wrote: Hi, A user of SmartSVN with SVN 1.14 reports a problem in connecting to the SVN server while it works in the browser. I redirected him to use our self-built SVN 1.14 binaries and he reports following error MacBook-Pro:user$ svn update Updating '.': *svn: E170013*: Unable to connect to a repository at URL ' https://svn.workapps.com/svn/OneWorkbook/trunk' *svn: E120108*: Error running context: The server unexpectedly closed the connection. How to diagnose the problem? Is it a problem of SVN or the server? Thanks in advance.
Error E170013: The server unexpectedly closed the,connection.
Hi, A user of SmartSVN with SVN 1.14 reports a problem in connecting to the SVN server while it works in the browser. I redirected him to use our self-built SVN 1.14 binaries and he reports following error MacBook-Pro:user$ svn update Updating '.': *svn: E170013*: Unable to connect to a repository at URL ' https://svn.workapps.com/svn/OneWorkbook/trunk' *svn: E120108*: Error running context: The server unexpectedly closed the connection. How to diagnose the problem? Is it a problem of SVN or the server? Thanks in advance. -- Best regards, Thomas Singer
Re: [PATCH] Fix JavaHL crash in TunnelAgent.CloseTunnelCallback after GC
Has this patch been merged yet? If not, what input is needed to get it accepted? Tom On 2020-08-07 20:47, Alexandr Miloslavskiy wrote: Please find test snippet and patch attached. [[[ Fix JavaHL crash in TunnelAgent.CloseTunnelCallback after GC When jobject reference is kept across different JNI calls, a new global reference must be requested with NewGlobalRef(). Otherwise, GC is free to remove the object. Even if Java code keeps a reference to the object, GC can still move the object around, invalidating the kept jobject, which results in a native crash when trying to access it. [in subversion/bindings/javahl] * native/OperationContext.cpp (OperationContext::openTunnel): Add NewGlobalRef() for kept jobject. (OperationContext::closeTunnel): Add a matching DeleteGlobalRef(). ]]]
Re: [PATCH] Fix JavaHL crash in RequestChannel.nativeRead
Has this patch been merged yet? If not, what input is needed to get it accepted? Tom On 2020-08-10 21:30, Alexandr Miloslavskiy wrote: Please find test snippet and patch attached. [[[ Fix JavaHL crash in RequestChannel.nativeRead The problem here is that when 'RemoteSession' is destroyed, it also does 'apr_pool_destroy()' which frees memory behind 'apr_file_t', which is represented by 'TunnelChannel.nativeChannel' in Java. 'TunnelChannel' runs on a different thread and is unaware that 'apr_file_t' pointer is now invalid. Fix this by informing 'TunnelChannel' before 'apr_file_t' is freed. One other problem is that when 'TunnelAgent.openTunnel()' throws an exception, 'OperationContext::closeTunnel()' was not called at all. [in subversion/bindings/javahl] * native/OperationContext.cpp (close_TunnelChannel): New function to inform Java side. (openTunnel): Keep references to Java tunnel objects. (openTunnel): In case of exception, clean up properly. (closeTunnel): Inform Java side when tunnel is closed. * src/org/apache/subversion/javahl/util/RequestChannel.java Add 'synchronized' to avoid error described in 'syncClose()' * src/org/apache/subversion/javahl/util/ResponseChannel.java Add 'synchronized' to avoid error described in 'syncClose()' * src/org/apache/subversion/javahl/util/Tunnel.java A new function to clean up. I decided not to change old '.close()' because the new function can lead to a deadlock if used incorrectly. ]]]
Re: What comes after 1.12?
What are the LTS releases? Is this somehow detectable by a user from the name? Ubuntu, for example, adds "LTS" to the name of their releases, e.g. "18.04 LTS". Maybe at <https://subversion.apache.org/download.cgi?update=201708081800> the title "Other Supported Release(s)" should rather be "LTS-Releases" with obvious indication how long they will receive support. And, of course, 1.10 should be named 1.10 LTS. Tom On 21/08/2019 09:07, Julian Foad wrote: Thomas Singer wrote: Probably the thing that would help me the most would be if the releases slowed down. If we want them on a schedule then do it every 12 months instead of 6. +1 But... we are doing releases on a 24-month schedule. We are calling those "LTS" releases. They correspond in purpose and stability and frequency to the old minor releases. What is compelling you to do anything with the new "regular" 6-month releases in between LTS releases? Or did we not communicate sufficiently about the new release schedule? - Julian
Re: What comes after 1.12?
Probably the thing that would help me the most would be if the releases slowed down. If we want them on a schedule then do it every 12 months instead of 6. +1 -- Thomas
Re: Checkpointing
Imagine working on one larger feature (or even multiple features). You already have created a couple of local commits, but are not yet finished. Following use cases come to my mind: 1) some other developer commits new revisions - it should be possible to continue working on your feature-queue keeping it based on the old revision, but sooner or later it comes the time to integrate the new revision(s) - this means to create a new queue on the new revision and cherry-pick all local commits of the old queue onto this new revision (could this be done with purely local information or would each cherry-pick require a possibly slow communication with the server?) - with each cherry-pick, a conflict might occur - aborting should abort the creation of the new queue and application of the old queue, resulting in the deletion of the partly finished new queue keeping the old one - each queue should be rebased independently onto the new revisions 2) you have to make a quick-fix revision - you need to switch from your local feature-queue to the latest revision and fix the bug a coworker requests to get fixed - you may now switch back to your queue to proceed with the work, but there is a new revision now, so you should base your work sooner or later on that revision 3) you want to rework your local commits, e.g. change order, squash some commits, change the message - create a new queue based on the same revision - create new local commits by cherry-picking commits from the other (old) queue, maybe amending some local commits - after the new queue is ready (verify to diff it with the old queue) the old queue can be deleted - often enough I find it useful to be able to make one of my first feature commits public, so the x first local commits should be possible to be become revisions => the queue becomes shorter and based on the new revision(s) 4) you need to fork an existing queue at any local commit - switching to one of the local commits of your current queue you detect that it contains a flaw - creating now a local commit to fix would mean to first create a new queue based on the same revision, apply all previous local commits (no conflict risk) - the old queue would be kept It might be useful to be able to "store" somehow one or another queue on the server, e.g. for backup reasons, so no change is lost if my hard disk crashes or my code fails and cleans the disk. (Creating a new, real feature branch with revisions in the repository I don't like because then they would be cut in stone and this would force me to create nice and clean commits. But because we are not without error, such code will contain back and forth changes and hence hard to read.) As long as I'm working on a non-trivial feature/refactoring, I prefer to have complete control over my commits, I even like to commit completely unstable and incomplete code with Git - because I have the possibility to clean up later. -- Best regards, Thomas Singer On 02/07/2019 18:32, Nathan Hartman wrote: On Sun, Jun 30, 2019 at 11:22 AM Thomas Singer wrote: With "rebasing" I mean, that such list of "local commits" needs to be re-applied (on demand, not automatically) onto a different revision. Something like a continues series of cherry-picking (with the possibility to get a conflict in each step; and a possibility to continue after conflict resolution or abort). This means to me, that at least cherry-picking needs to be possible from a revision or a "local commit". Could you describe how you would like to use this capability? E.g., give an example use case?
Re: Checkpointing
Hi Nathan, Thanks for your detailed answers. - will it support "rebasing" such a local history onto the latest updated commit? It will have to support "rebasing" which is what "svn update" already does today. Otherwise you couldn't commit your work! With "rebasing" I mean, that such list of "local commits" needs to be re-applied (on demand, not automatically) onto a different revision. Something like a continues series of cherry-picking (with the possibility to get a conflict in each step; and a possibility to continue after conflict resolution or abort). This means to me, that at least cherry-picking needs to be possible from a revision or a "local commit". Tom
Re: Checkpointing
Hi Nathan,
Thanks for your explanation. This sounds quite interesting. I have some
questions though:
- so the working copy can have checked out multiple commits or one
checkpoint?
- will it support multiple histories ("branches") planned, e.g. for
different features?
- will it support "rebasing" such a local history onto the latest
updated commit?
--
Best regards,
Thomas Singer
Re: Unicode composable characters on macOS [was: Subversion 2.0]
Hi Branko, Thanks for the detailed explanation. Would you mind to add the description to the linked issue and mark it as resolved/works-for-me/no-bug, so this information is not lost? -- Best regards, Thomas Singer = syntevo GmbH On 26/06/2019 17:39, Branko Čibej wrote: On 26.06.2019 10:40, Marc Strapetz wrote: 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 sure, you are referring to this problem: https://issues.apache.org/jira/browse/SVN-2464 ? It would be great to have some more information for which OSX version and which file systems the problem should be resolved. The original problem was that Apples HFS+ filesystem normalized paths to Unicode Normalisation Form D. In practice that meant that if you created a file with a name that contained a composable character, then read that name from the filesystem, you could get different results (i.e., the name was "the same" as far as Unicode normalisation is concerned, but the actual representation bytes were different). The new APFS filesystem (which is the default in the last two versions of macOS, IIRC) doesn't do that any more. This is on local disk, which is APFS: brane@zulu:~/src/svn/test$ svnadmin create repo brane@zulu:~/src/svn/test$ svn co file://$(pwd)/repo wc Checked out revision 0. brane@zulu:~/src/svn/test$ touch wc/čibej brane@zulu:~/src/svn/test$ svn add wc/čibej A wc/čibej brane@zulu:~/src/svn/test$ svn st wc/ A wc/čibej and this is on an HFS+ disk image: brane@zulu:/Volumes/hfs$ svnadmin create repo brane@zulu:/Volumes/hfs$ svn co file://$(pwd)/repo wc Checked out revision 0. brane@zulu:/Volumes/hfs$ touch wc/čibej brane@zulu:/Volumes/hfs$ svn add wc/čibej A wc/čibej brane@zulu:/Volumes/hfs$ svn st wc/ ? wc/čibej ! wc/čibej The second instance clearly shows that the filesystem changed the file name. -- Brane
Re: Subversion's community health
I agree to all you wrote. But the increased speed of releasing new versions with unstable experimental features somehow contradicts the otherwise mature development state. As a user of the JavaHL API we only consider a feature as stable if it is reflected in all binding APIs, too. -- Best regards, Thomas Singer = syntevo GmbH https://www.syntevo.com https://www.syntevo.com/blog On 2019-06-14 16:34, Eric S. Raymond wrote: Julian Foad : Anyone with constructive suggestions, please do share them. Please let us not dwell on our sadness and criticism of what went before; let us try to keep this thread focused on positive solutions for what to do next. You guys know me. I'm a past contributor, occasional critic, often a supporter. I did my best to push back when Linus Torvalds accused this crew of incompetence. And I, too, have had the recent experience of watching a project I was hugely invested in - GPSD - slide into a semi-active maintainence mode. The main piece of advice I have for all of you is that you should keep your expectations about Subversion's future realistic. The brute fact is that git has taken over the version-control world. It has stomped flat a couple of sttempts to compete with it in DVCS - Mercurial, bzr, monotone. And Subversion is at a massive disdavantage relative to *any* DVCS for reasons that should be too obvious to need repeating. Does Subversion have a future at all? I think the answer is "Yes", but it's not an exciting, sexy future. You guys have only two selling points I can see for new installations (1) Subversion's UI is *massively* simpler than git's, and (2) some customers have political/cultural reasons to prefer a centralized VCS with repositories that can't be easily cloned. I think that's enough for survival. But it's not exciting, not sexy, and not a recipe for drawing in new development talent. Thus, if you try to plan for big things, you will almost certainly fail because you won't be able to collect the investment of developmen time required to realize them. What you *can* hope for is to ship occasional releases of high quality and maintain Subversion's deserved reputation as the best of the pre-DVCS version-control systems. This is what I mean by setting realistic expectations. It means gearing down - accepting that your release tempo is going to be low and your main goal is to keep the issue tracker relatively clean. This is where I am now with GPSD. I had to struggle a bit to accept it, but the truth is GPSD is mature software that doesn't have much of anything left to do in its application domain. In an important way, that is victory. I'll pitch in here myself; I have plans to collect some more information about the semantics of the dump format and add it to the documentation already in the source tree. Because I believe in finishing what I started and leaving behind artifacts that say "Damn, that guy was a pro." You can still have that kind of excellence. It's not a trivial thing.
Re: Subversion 2.0
I don't want to rain on anyone's parade but here's some food for thought. The only valid reason to call anything 2.0 is if, and only if, we decide to break backwards compatibility in some area. I disagree. It is quite common use to name something 2.0 if it has serious improvements over 1.x. -- Best regards, Thomas Singer = syntevo GmbH
Re: Subversion 2.0
What I like with SVN: - it is easy to fix commit messages - the externals are easy to understand - the properties - the file locking What I don't like: - after more than a decade the umlaut problem of composed/decomposed UTF-8 has not been solved What I like most about Git: - it allows to create clean commits, because I can modify all my local commits, e.g. reorder and squash them, in case I detected an error in a previous, unpushed commit - it is still much stronger merging renamed, modified files - I can solve every conflict locally, try again and again, without losing any changes (imagine a complicated merge in SVN where you now have solved a couple of conflicts, but an update brings new conflicts) - I can switch branches very quickly back and forth without the need to transfer the whole project over a network (even having to wait a couple of minutes with a decent connection is too slow if you are used to Git's seconds - we are not talking about the fact that it is wasted energy to transfer the same data again and again just because SVN does not cache it) - Git allows me to create a feature in my own branch, turn all my commits in this branch up-side-down if I need (even after pushing to the repository) and finally rebase it on top of the main development branch Of course, the latter only works fine if there is just one developer of this feature branch, but usually this is the case for me. More than 5 years ago we have massively refactored our products to switch from one GUI library to another (Swing -> SWT). Without Git and rebasing this would have been much more complicated. Most of the things I like in Git are not possible with other DVCS, or require some non-standard extensions, or may produce weird states you don't know how to get out. I don't know what SVN 2 would need to have, so I would consider to use it for a software product repository again. -- Best regards, Thomas Singer = syntevo GmbH
SVN version numbering
Hi all, OK, we are now at SVN 1.11 because you have agreed to release often with only a few changes. What does the prefix "1." mean - will there be some "2." or "3." in the future? If not, then it is redundant. For time-based releases, wouldn't it be more useful to use the year, e.g. the next one could be SVN 19 or SVN 19.04? Cheers, Tom
Commit to external, increase revision in external property
Hello, Usually, externals are configured to use fixed revisions, so checking out an older revision also checks out the belonging revision of the external. When committing to an external, the external property still points to the old external revision - performing an update of the outer working copy will reset the external to the previous revision. Is there already a commit option that would modify the external property automatically if modifications would be committed inside an external? -- Best regards, Thomas Singer
Compile on MinGW-w64 (Windows)
Hi, Did someone succeeded in compiling SVN (and its dependencies) completely using MinGW-w64 (instead of using Visual Studio)? -- Thomas
Re: "Permission denied" committing to sourceforge
Sorry, the problem was that the end-user used a different case of the user name than what he told me to use. -- Best regards, Thomas Singer On 13/08/2018 15:00, Daniel Shahaf wrote: Thomas Singer wrote on Mon, 13 Aug 2018 14:56 +0200: The user ensured to have used the same working copy. Is there some way to debug it to find out why his SVN binary behaves different then ours? Thanks in advance. The simplest explanation is that it's a cygwin svn.exe v. a windows svn.exe. Those two would use different config dirs and hence different credential caches. You can use the 'svn auth' command to list the saved credentials.
Re: AW: AW: "Permission denied" committing to sourceforge
On 2018-08-11 13:18, Branko Čibej wrote: On 10.08.2018 16:06, Markus Schaber wrote: Hi, Brane, Von: Branko Čibej On 10.08.2018 14:30, Branko Čibej wrote: On 10.08.2018 13:37, Markus Schaber wrote: Von: Thomas Singer On 2018-08-10 9:52, Branko Čibej wrote: On 10.08.2018 09:44, Stefan Sperling wrote: On Fri, Aug 10, 2018 at 08:44:08AM +0200, Thomas Singer wrote: When trying to commit to a sourceforge repository using a self-compiled SVN binary, I'm getting following error: D:\temp\irrlicht>svn.exe commit --username HinzKunz -m "a message" Authentication realm: <https://svn.code.sf.net:443> SourceForge User Password for 'HinzKunz': svn: E13: Commit failed (details below): svn: E13: Can't create directory '/svn/p/irrlicht/code/db/transactions/5634-1.txn': Permission denied Could this mean that we have built the SVN binary incomplete (missing a part that is required for committing to sourceforge but not other SVN repositories)? How can I get some helpful logging? Thanks in advance. I believe you'll need to ask sourceforge about this. This looks like a server-side problem and there is nothing an SVN client could do about it. More specifically, it looks like filesystem permissions on the repository storage are incorrect. Thanks. That's what I thought initially, too, simply guessing from the error message. But the user who reported the problem writes that with his default SVN binaries the commit succeeded for him, and I'm not sure that's it's not a problem with our SVN binaries. Is it possible that there's a difference in protocols? If the one user uses https://, and the other uses svn:// or svn+ssh:// protocols, the server side has different software, probably running under different user account and permissions. Of course, but it's still the server administrators responsibility to make things work (i.e., set process/file ownership and permissions correctly) if they support both http:// and svn:// protocols. Nothing on the client side can affect that. Agreed. By the way: the protocol used is determined by the working copy, not by the client software; unless some info is missing from your report, both clients are using the same protocol. Hmm, yes it's in the working copy. But that "missing information" was what I suspected. One part (which is not necessarily covered by working copy) could be user name, especially with svn+ssh:// - on the other hand, the pasted example uses https:// URLs. So I withdraw everything. :-) Actually, the username could be different for https:// as well. In theory, differently compiled clients could use different credentials caches. -- Brane The user ensured to have used the same working copy. Is there some way to debug it to find out why his SVN binary behaves different then ours? Thanks in advance. -- Tom
Re: "Permission denied" committing to sourceforge
On 2018-08-10 9:52, Branko Čibej wrote: On 10.08.2018 09:44, Stefan Sperling wrote: On Fri, Aug 10, 2018 at 08:44:08AM +0200, Thomas Singer wrote: Hi, When trying to commit to a sourceforge repository using a self-compiled SVN binary, I'm getting following error: D:\temp\irrlicht>svn.exe commit --username HinzKunz -m "a message" Authentication realm: <https://svn.code.sf.net:443> SourceForge User Password for 'HinzKunz': svn: E13: Commit failed (details below): svn: E13: Can't create directory '/svn/p/irrlicht/code/db/transactions/5634-1.txn': Permission denied Could this mean that we have built the SVN binary incomplete (missing a part that is required for committing to sourceforge but not other SVN repositories)? How can I get some helpful logging? Thanks in advance. -- Best regards, Thomas Singer Hi Thomas, I believe you'll need to ask sourceforge about this. This looks like a server-side problem and there is nothing an SVN client could do about it. More specifically, it looks like filesystem permissions on the repository storage are incorrect. -- Brane Thanks. That's what I thought initially, too, simply guessing from the error message. But the user who reported the problem writes that with his default SVN binaries the commit succeeded for him, and I'm not sure that's it's not a problem with our SVN binaries. -- Tom
"Permission denied" committing to sourceforge
Hi, When trying to commit to a sourceforge repository using a self-compiled SVN binary, I'm getting following error: D:\temp\irrlicht>svn.exe commit --username HinzKunz -m "a message" Authentication realm: <https://svn.code.sf.net:443> SourceForge User Password for 'HinzKunz': svn: E13: Commit failed (details below): svn: E13: Can't create directory '/svn/p/irrlicht/code/db/transactions/5634-1.txn': Permission denied Could this mean that we have built the SVN binary incomplete (missing a part that is required for committing to sourceforge but not other SVN repositories)? How can I get some helpful logging? Thanks in advance. -- Best regards, Thomas Singer
Re: JavaHL crash on macOS 10.13.5
For adding/committing an empty file he is getting: $ touch testfile.txt $ svn add testfile.txt A testfile.txt $ svn commit -m "commit test" testfile.txt Adding testfile.txt Transmitting file data .svn: E175002: Commit failed (details follow): svn: E175002: Unexpected HTTP status 400 'Bad Request' on '/svn/Projects/!svn/txr/7198-5vq/E867%20MS%20Marin/testfile.txt' -- Best regards, Thomas Singer On 2018-06-08 8:12, Thomas Singer wrote: Thanks for answering. The user tried to commit using our SVN 1.9.7 binaries from <https://www.smartsvn.com/download/#svn>: I attempted the command line commit and got an error. It is a text file, RTF made in TextEdit and is 2 words. here’s the error i got from the command line which makes no sense to me since i have 16gigs of memory and over half of it free. Thanks again! $ svn add Test\ Commit\ File.rtf svn: warning: W150002: '/Users/relic/Documents/SVN/Projects/E867 MS Marin/Test Commit File.rtf' is already under version control svn: E29: Could not add all targets because some targets are already versioned svn: E29: Illegal target for the requested operation $ svn commit -m "commit test" Test\ Commit\ File.rtf Adding Test Commit File.rtf Transmitting file data .libsvn: Out of memory - terminating application. Abort trap: 6 Are there other, portable SVN binaries for macOS available to try them, too? Maybe the problem is caused by how we build?
Re: JavaHL crash on macOS 10.13.5
Thanks for answering. The user tried to commit using our SVN 1.9.7 binaries from <https://www.smartsvn.com/download/#svn>: I attempted the command line commit and got an error. It is a text file, RTF made in TextEdit and is 2 words. here’s the error i got from the command line which makes no sense to me since i have 16gigs of memory and over half of it free. Thanks again! $ svn add Test\ Commit\ File.rtf svn: warning: W150002: '/Users/relic/Documents/SVN/Projects/E867 MS Marin/Test Commit File.rtf' is already under version control svn: E29: Could not add all targets because some targets are already versioned svn: E29: Illegal target for the requested operation $ svn commit -m "commit test" Test\ Commit\ File.rtf Adding Test Commit File.rtf Transmitting file data .libsvn: Out of memory - terminating application. Abort trap: 6 Are there other, portable SVN binaries for macOS available to try them, too? Maybe the problem is caused by how we build? -- Best regards, Thomas Singer On 2018-06-07 11:24, Philip Martin wrote: Thomas Singer writes: Thread 44 Crashed:: Java: WorkerThread-3 0 libsystem_kernel.dylib 0x7fff696a0b6e __pthread_kill + 10 1 libsystem_pthread.dylib 0x7fff6986b080 pthread_kill + 333 2 libsystem_c.dylib 0x7fff695fc1ae abort + 127 3 libsvn_subr-1.0.dylib 0x00011ef564f5 abort_on_pool_failure + 4 libserf-1.dylib 0x00011f0dec53 serf__process_connection + 259 5 libserf-1.dylib 0x00011f0dd263 serf_event_trigger + 163 6 libserf-1.dylib 0x00011f0dd39c serf_context_run + 108 7 libsvn_ra_serf-1.0.dylib 0x00011f394845 svn_ra_serf__context_run + 69 Unfortunately, I neither can't reproduce the crash on our macOS 10.13 machine nor do I understand the reason for the crash. Could it be, somehow, be caused by us having compiled SVN incorrectly? Or could this be a problem of libsystem_kernel.dylib, libsystem_pthread.dylib, libsystem_c.dylib? Thanks in advance for any helpful clue. abort_on_pool_failure() indicates that the process failed to allocate dynamic memory. There could be a memory leak, causing the process to allocate an excessive amount of memory. There could be some limit on the process causing it to fail when attempting to allocate a large, but reasonable, amount of memory. Was the commit "large" in some way? Lots of files? Large files? Deep directories? Lots of properties? Large properties? etc.
JavaHL crash on macOS 10.13.5
Hi experts, We've got a macOS crash report from a user of SmartSVN (that uses JavaHL for performing SVN commands). The following thread crashed when the user tried to add/commit a new file: Thread 44 Crashed:: Java: WorkerThread-3 0 libsystem_kernel.dylib 0x7fff696a0b6e __pthread_kill + 10 1 libsystem_pthread.dylib 0x7fff6986b080 pthread_kill + 333 2 libsystem_c.dylib 0x7fff695fc1ae abort + 127 3 libsvn_subr-1.0.dylib 0x00011ef564f5 abort_on_pool_failure + 21 4 libserf-1.dylib 0x00011f0dec53 serf__process_connection + 259 5 libserf-1.dylib 0x00011f0dd263 serf_event_trigger + 163 6 libserf-1.dylib 0x00011f0dd39c serf_context_run + 108 7 libsvn_ra_serf-1.0.dylib0x00011f394845 svn_ra_serf__context_run + 69 8 libsvn_ra_serf-1.0.dylib0x00011f394976 svn_ra_serf__context_run_wait + 86 9 libsvn_ra_serf-1.0.dylib0x00011f394a5a svn_ra_serf__context_run_one + 138 10 libsvn_ra_serf-1.0.dylib0x00011f3840ef close_file + 223 11 libsvn_wc-1.0.dylib 0x00011f4cccee svn_wc__internal_transmit_text_deltas + 1342 12 libsvn_wc-1.0.dylib 0x00011f4ccd43 svn_wc_transmit_text_deltas3 + 67 13 libsvn_client-1.0.dylib 0x00011f57a554 svn_client__do_commit + 596 14 libsvn_client-1.0.dylib 0x00011f579373 svn_client_commit6 + 3475 15 libsvnjavahl-1.dylib0x00011f5fbed2 SVNClient::commit(Targets&, CommitMessage*, svn_depth_t, bool, bool, StringArray&, PropertyTable&, CommitCallback*) + 242 16 libsvnjavahl-1.dylib0x00011f60e555 Java_org_apache_subversion_javahl_SVNClient_commit + 453 17 ??? 0x00010fe96a74 0 + 4561922676 18 ??? 0x00010fe87302 0 + 4561859330 19 ??? 0x00010fe87040 0 + 4561858624 20 ??? 0x00010fe87114 0 + 4561858836 21 ??? 0x00010fe87040 0 + 4561858624 22 ??? 0x00010fe87040 0 + 4561858624 23 ??? 0x00010fe872bd 0 + 4561859261 24 ??? 0x00010fe872bd 0 + 4561859261 25 ??? 0x00010fe87040 0 + 4561858624 26 ??? 0x00010fe87114 0 + 4561858836 27 ??? 0x00010fe87040 0 + 4561858624 28 ??? 0x00010fe87114 0 + 4561858836 29 ??? 0x00010fe87114 0 + 4561858836 30 ??? 0x00010fe87302 0 + 4561859330 31 ??? 0x00010fe872bd 0 + 4561859261 32 ??? 0x00010fe87302 0 + 4561859330 33 ??? 0x00010fe7f7a7 0 + 4561827751 34 libjvm.dylib0x000100b4870a JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 35 libjvm.dylib0x000100b48eae JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 356 36 libjvm.dylib0x000100b4905a JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 37 libjvm.dylib0x000100ba37b1 thread_entry(JavaThread*, Thread*) + 124 38 libjvm.dylib0x000100dc60b3 JavaThread::thread_main_inner() + 155 39 libjvm.dylib0x000100dc77a0 JavaThread::run() + 450 40 libjvm.dylib0x000100ce5aee java_start(Thread*) + 246 41 libsystem_pthread.dylib 0x7fff69868661 _pthread_body + 340 42 libsystem_pthread.dylib 0x7fff6986850d _pthread_start + 377 43 libsystem_pthread.dylib 0x7fff69867bf9 thread_start + 13 Unfortunately, I neither can't reproduce the crash on our macOS 10.13 machine nor do I understand the reason for the crash. Could it be, somehow, be caused by us having compiled SVN incorrectly? Or could this be a problem of libsystem_kernel.dylib, libsystem_pthread.dylib, libsystem_c.dylib? Thanks in advance for any helpful clue. -- Best regards, Thomas Singer
Re: JDK 10 removal of javah
We are using OS X 10.7.5 for building SVN binaries. This seems to work with Java 1.8. -- Best regards, Thomas Singer = syntevo GmbH https://www.syntevo.com https://www.syntevo.com/blog On 2018-05-18 9:46, Stefan Sperling wrote: On Fri, May 18, 2018 at 08:40:35AM +0200, Thomas Singer wrote: Whatever you do, please keep backward compatibility with older JDKs. Reason is building on older OS X machines for most compatibility which do not allow latest JDKs. Thanks for considering. Could you be more specific about which versions of JDK are required for compatibility with which old versions of OS X? Elsewhere in this discussion thread it was suggested to raise the minimum JDK version requirement to Java 1.8. Your statement "please keep backward compatibility with older JDKs" could mean anything between "please leave everything as it is now" to "bumping the minimum requirement to Java 1.8 is absolutely fine with me". This requirement would be introduced for Subversion 1.11. Can you explain which versions of OS X / JDK you expect to support when Subversion 1.11 will be released in probably 2 to 3 years from now?
Re: JDK 10 removal of javah
Hi James, Whatever you do, please keep backward compatibility with older JDKs. Reason is building on older OS X machines for most compatibility which do not allow latest JDKs. Thanks for considering. -- Best regards, Thomas Singer = syntevo GmbH https://www.syntevo.com https://www.syntevo.com/blog On 2018-05-18 4:27, James McCoy wrote: On Fri, May 04, 2018 at 08:12:29AM -0400, James McCoy wrote: On Sat, Dec 23, 2017 at 06:44:13PM +0100, Branko Čibej wrote: On 23.12.2017 16:30, Andreas Stieger wrote: Hello, I was made aware by our Java package maintainer of the fact that JDK 10 is removing the javah tool, after the deprecation from JDK 8. Our javahl stuff no longer builds and apparently the functionality is in javac now. JEP 313: Remove the Native-Header Generation Tool (javah) http://openjdk.java.net/jeps/313 Was anyone looking at this? Not to my knowledge, and patches are always welcome. If javac has the same functionality, it shouldn't be too hard to tweak the build system. Java 10 has now hit Debian as default, so I've started looking into fixing this. Basically, javac can now be told to generate the headers at the same time it generates the class files, by adding "-h subversion/bindings/javahl/include" to the existing javac calls. However, this only works with Java 8 or newer. It's taken longer than I was hoping, but I'll have something for trunk soon. The biggest wrinkle is that "javac -h" _only_ generates a header file if there are native annotations, whereas "javah" would always generate a header file. This found some places where we didn't have native annotations even though they were needed. It also throws a wrench in our dependency tracking. We can't just say "Hey make, these .java files all generate a .h file, and libsvnjavahl depends on all the .h files" anymore. I was initially going to drop the javah type from build.conf. Since it looks like we'll need to explicitly list the header files we expect to generate, it will probably be cleaner to use the package-based javah stanzas instead. That will also keep the dependencies more accurate. Cheers,
Re: Documentation to build SVN 1.10
Thank you. It looks like this information has helped me to compile on Linux, but on Windows gen-make.py is used and that does not like the parameters --with-lz4=internal or --with-utf8proc=internal. -- Best regards, Thomas Singer On 2018-04-18 11:52, Stefan Sperling wrote: On Wed, Apr 18, 2018 at 10:50:15AM +0200, Thomas Singer wrote: Hi developers, I'm trying to build SVN 1.10 on CentOS 6.2 based on a black-box build script that I have for SVN 1.9. So far it looks like SVN 1.10 requires a newer sqlite-amalgamation-3081101.zip and requires something regarding LZ4. Unfortunately, simply adding "--with-lz4=internal" is not sufficient, because now it complains about "Subversion requires UTF8PROC". How to install that - where can I find documentation about how to build SVN 1.10? See ./configure --help ; utf8proc is another new required dependency and, like with lz4, there's an internal copy you could compile with.
Documentation to build SVN 1.10
Hi developers, I'm trying to build SVN 1.10 on CentOS 6.2 based on a black-box build script that I have for SVN 1.9. So far it looks like SVN 1.10 requires a newer sqlite-amalgamation-3081101.zip and requires something regarding LZ4. Unfortunately, simply adding "--with-lz4=internal" is not sufficient, because now it complains about "Subversion requires UTF8PROC". How to install that - where can I find documentation about how to build SVN 1.10? -- Best regards, Thomas Singer
Re: x509 AlgorithmIdentifier parameters
Hi Philip, Thank you for your effort in analyzing this bug and finding work-arounds or fixes. We are using a magic script to build all subversion dependencies, e.g. openssl-1.0.2 and cyrus-sasl-2.1.26. I've used the master branch from <https://github.com/openssl/openssl> for compiling (~163MB for the master vs. ~24MB for version 1.0.2) which seems to have compiled fine, but unfortunately the cyrus-sasl-2.1.26 fails to build. Without actually understanding what happens there under the hood, I'm a little bit lost. Should cyrus-sasl also be updated to be compatible with the openssl master? -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog On 2018-02-03 22:40, Philip Martin wrote: Philip Martin <phi...@codematters.co.uk> writes: A client using openssl 1.0 will connect to a server serving the RSASSA-PSS cert. Clients using openssl 1.1 fail to verify cert. The underlying openssl 1.1 error appears to be $ openssl s_client -connect localhost:8887 -CAfile apache2/ssl/ca-cert.pem ... Verify return code: 68 (CA signature digest algorithm too weak) This suggests that RSASSA-PSS is obsolete, but as I mentioned earlier in the thread there are recent changes to the openssl project adding/extending RSASSA-PSS support as part of TLS 1.3: I built openssl trunk (1.1.1-dev) and it is able to verify the cert: $ LD_LIBRARY_PATH=/usr/local/openssl/lib /usr/local/openssl/bin/openssl s_client -connect localhost:8887 -CAfile=apache2/ssl/ca-cert.pem ... Verify return code: 0 (ok) This is exactly the same server and cert that cause openssl 1.1 to fail.
Re: Slow ISVNClient.getChangelists on Linux/NFS share
On 2017-10-19 10:44, Johan Corveleyn wrote: I have no idea what ISVNClient.getChangelists corresponds to compared with the native 'svn' commandline. But one thing that might be relevant: in the client-side configuration file 'config' there are two properties that can have a big influence here: (see %APPDATA%/Subversion/config on Windows, or ~/.subversion/config on Unix) [[[ ### Section for configuring working copies. [working-copy] ### Set to a list of the names of specific clients that should use ### exclusive SQLite locking of working copies. This increases the ### performance of the client but prevents concurrent access by ### other clients. Third-party clients may also support this ### option. ### Possible values: ### svn(the command line client) # exclusive-locking-clients = ### Set to true to enable exclusive SQLite locking of working ### copies by all clients using the 1.8 APIs. Enabling this may ### cause some clients to fail to work properly. This does not have ### to be set for exclusive-locking-clients to work. # exclusive-locking = false ]]] So with the above options you can make all clients (that use that config file) respect "exclusive-locking" (with the exclusive-locking flag), or just a subset of specific client applications (with the exclusive-locking-clients property). Perhaps your commandline 'svn' invocation uses the standard ~/.subversion/config file, which has the exclusive-locking flag set, and your SmartSVN application might use another one (it can choose another "config dir"). Thank you for this suggestion. I've tried with exclusive-locking = true but it makes no difference. I don't know what to enter for exclusive-locking-clients = How does SVN detect the client name when using JavaHL? -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog
Re: Slow ISVNClient.getChangelists on Linux/NFS share
On 18.10.2017 19:56, Branko Čibej wrote: On 18.10.2017 13:31, Thomas Singer wrote: Hi, When performing following steps on my old Linux test machine (with slow hard disk): - have a SVN working copy at /home/user/test - sudo apt install nfs-kernel-server - add following line to /etc/exports: /home/user/test *(rw,sync,no_root_squash) - start the NFS server: sudo systemctl start nfs-kernel-server.service - mount the NFS share: sudo mount localhost:/home/user/test /home/user/test.nfs and then open /home/user/test.nfs in SmartSVN 9.2 (using SVN 1.9 JavaHL binaries), adding/removing a file is very slow. It boils down to the call ISVNClient.getChangelists which takes ~8s on the NFS share (/home/user/test.nfs). First, I thought, it would be caused by the native-Java overhead calling the call-back ~11,000 times for my working copy, but when using the working copy directly (/home/user/test), the method just takes <1s though the ~11,000 times call-back invocations are still there. My working copy has no local modifications, no untracked or ignored files, no changelists. Is it expected that this method (ISVNClient.getChangelists) is so slow on a NFS share even if there are no changelists? I don't know if it's "expected" but I bet that NFS is killing SQLite performance. https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg88989.html I'm not sure about the reason but the most likely answer, apart from slow data rate and latency when compared to a local filesystem (which, in your case on loopback, should not be an issue), is that the OS can't really use a cache for files on NFS since it has no way to know whether or not it's valid. With a lot of random-access reads and writes, that can be a HUGE slowdown, as you found. Also this: https://sqlite.org/faq.html#q5 In other words, Subversion working copies on NFS are, and have always been, a bad idea; not only because of SQLite but also because Subversion's code itself relies on atomic renames, which NFS does not provide. -- Brane What SVN command (on command line) I should test to get a similar result as from ISVNClient.getChangelists? I've tried "git status" and it just needs <1s on the NFS working copy. -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog
Slow ISVNClient.getChangelists on Linux/NFS share
Hi, When performing following steps on my old Linux test machine (with slow hard disk): - have a SVN working copy at /home/user/test - sudo apt install nfs-kernel-server - add following line to /etc/exports: /home/user/test *(rw,sync,no_root_squash) - start the NFS server: sudo systemctl start nfs-kernel-server.service - mount the NFS share: sudo mount localhost:/home/user/test /home/user/test.nfs and then open /home/user/test.nfs in SmartSVN 9.2 (using SVN 1.9 JavaHL binaries), adding/removing a file is very slow. It boils down to the call ISVNClient.getChangelists which takes ~8s on the NFS share (/home/user/test.nfs). First, I thought, it would be caused by the native-Java overhead calling the call-back ~11,000 times for my working copy, but when using the working copy directly (/home/user/test), the method just takes <1s though the ~11,000 times call-back invocations are still there. My working copy has no local modifications, no untracked or ignored files, no changelists. Is it expected that this method (ISVNClient.getChangelists) is so slow on a NFS share even if there are no changelists? -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog
Re: Shelving in TortoiseSVN
Just curious: does shelving only works for text files or also for binary files? BTW: what I really miss in SVN is not shelving, but rather the ability to select individually which line/hunk to commit. -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog On 02.10.2017 15:19, Julian Foad wrote: TortoiseSVN now has 'Shelve' and 'Unshelve' commands implemented, if you build it from source using the 'shelve' branch. It uses the shelving prototype API in Subversion's 'shelve' branch. The purpose at this stage is to get early feedback on the Shelving feature from a wider range of users by presenting the shelving prototype in a GUI. If you can try it, please do, and please reply with any thoughts it brings to mind. The UI is very basic in the initial revision (r27987). 'Shelve' shows a selection list of modified files, like commit and revert do, and asks you to type a name. 'Unshelve' just asks you to type a name. Hopefully we'll get some improvements in, even before we try presenting this prototype to a wider range of users outside the dev-lists. For a start, 'Unshelve' should show a list of previously shelved patches and allow selecting one from the list, with the most recent one chosen by default. - Julian
Umlauts on OS X
Hi all, There is the well-known umlaut bug on OS X in SVN since 2005 <https://issues.apache.org/jira/browse/SVN-2464> Are there any plans to finally solve this topic somehow in the near future (e.g. for 1.10) or are there too much concerns regarding upgrading existing repositories and breaking something? Maybe it would be a good time to treat 1.10 as a large bug-fix release (duplicate hash fix, OS X umlaut fix, ...)? -- Best regards, Thomas Singer smartsvn GmbH
Re: JavaHL: Hard crash in libsvn_subr-1.dll
Sergey, Thank you for this valuable information. -- Thomas Singer On 10.09.2015 17:46, Sergey Raevskiy wrote: After digging in some disassembly, I've guessed the [libsvn_subr-1.dll+0xc4c20] as svn_relpath_join() which is called with BASE == NULL. So, the crash might be caused by the same issue as in [1] which was already fixed in r1702198 [2]. [1] http://svn.haxx.se/dev/archive-2015-09/0070.shtml [2] http://svn.apache.org/r1702198 On Wed, Sep 9, 2015 at 5:47 PM, Ivan Zhakov <i...@visualsvn.com> wrote: On 9 September 2015 at 16:58, Thomas Singer <thomas.sin...@syntevo.com> wrote: What further information do you need for this crash? Stack trace with symbols information at least. -- Ivan Zhakov
Re: JavaHL: Hard crash in libsvn_subr-1.dll
What further information do you need for this crash? -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog On 08.09.2015 09:06, Thomas Singer wrote: We've got the attached bug report where libsvn_subr-1.dll crashes. Unfortunately, I have no idea how to reproduce. -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog
JavaHL: Hard crash in libsvn_subr-1.dll
We've got the attached bug report where libsvn_subr-1.dll crashes. Unfortunately, I have no idea how to reproduce. -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x5edc4c20, pid=13340, tid=6728 # # JRE version: Java(TM) SE Runtime Environment (7.0_67-b01) (build 1.7.0_67-b01) # Java VM: Java HotSpot(TM) Client VM (24.65-b04 mixed mode windows-x86 ) # Problematic frame: # C [libsvn_subr-1.dll+0xc4c20] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x3e026400): JavaThread "WorkerThread-3" [_thread_in_native, id=6728, stack(0x3cd5,0x3cda)] siginfo: ExceptionCode=0xc005, reading address 0x Registers: EAX=0x, EBX=0x, ECX=0x, EDX=0x0001 ESP=0x3cd9d6d0, EBP=0x3cd9d6d0, ESI=0x3e193138, EDI=0x EIP=0x5edc4c20, EFLAGS=0x00010202 Top of Stack: (sp=0x3cd9d6d0) 0x3cd9d6d0: 3cd9d6f0 5f4ee618 3e18525c 0x3cd9d6e0: 3e1850c0 3df70180 3e185100 3e18525c 0x3cd9d6f0: 3cd9d73c 5f4f18b0 3e185108 3e193138 0x3cd9d700: 3e1850c0 3df3e1c8 3df414c0 3df4c158 0x3cd9d710: 01e79fa0 3e185108 3e185100 0x3cd9d720: 2008 3e193144 3cd9d74c 0x3cd9d730: 3df70180 3e18b0d8 3cd9d768 0x3cd9d740: 70646fa8 3df3e0a8 3e193138 Instructions: (pc=0x5edc4c20) 0x5edc4c00: 8d 04 31 5e 5d c3 cc cc cc cc cc cc cc cc cc cc 0x5edc4c10: 55 8b ec 8b 45 08 8d 50 01 8d a4 24 00 00 00 00 0x5edc4c20: 8a 08 40 84 c9 75 f9 53 56 2b c2 57 8b 7d 0c 8b 0x5edc4c30: f0 8b c7 8d 50 01 8a 08 40 84 c9 75 f9 2b c2 8b Register to memory mapping: EAX=0x is an unknown value EBX=0x is an unknown value ECX=0x is an unknown value EDX=0x0001 is an unknown value ESP=0x3cd9d6d0 is pointing into the stack for thread: 0x3e026400 EBP=0x3cd9d6d0 is pointing into the stack for thread: 0x3e026400 ESI=0x3e193138 is an unknown value EDI=0x is an unknown value Stack: [0x3cd5,0x3cda], sp=0x3cd9d6d0, free space=309k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libsvn_subr-1.dll+0xc4c20] C [libsvn_wc-1.dll+0x4e618] C [libsvn_wc-1.dll+0x518b0] C [libsvn_delta-1.dll+0x6fa8] C [libsvn_ra-1.dll+0x4ddd0] C [libsvn_ra-1.dll+0x4fbdd] C [libsvn_ra-1.dll+0x3e583] C [libsvn_ra-1.dll+0x123da] C [libsvn_ra-1.dll+0x128f2] C [libsvn_ra-1.dll+0x13ee6] C [libsvn_ra-1.dll+0xe030] C [libsvn_ra-1.dll+0xdacd] C [libsvn_ra-1.dll+0xf3ab] C [libsvn_ra-1.dll+0x3f427] C [libsvn_ra-1.dll+0x4e4d2] C [libsvn_ra-1.dll+0x4a610] C [libsvn_ra-1.dll+0x4a6bd] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.apache.subversion.javahl.SVNClient.update(Ljava/util/Set;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Depth;)[J+0 j smartsvn.SZ.a(Lorg/apache/subversion/javahl/ISVNClient;Lsmartsvn/axi;)Ljava/lang/Object;+29 j smartsvn.Sx.a(Lsmartsvn/Tz;Lsmartsvn/axi;)Ljava/lang/Object;+117 j smartsvn.Sx.a(Lsmartsvn/Tz;)Ljava/lang/Object;+31 j smartsvn.Sx.a(Ljava/util/Set;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Depth;)[J+24 j smartsvn.Sx.a(Ljava/util/Set;Lorg/apache/subversion/javahl/types/Revision;Lsmartsvn/te;)[J+46 j smartsvn.arh.a(Lsmartsvn/axk;Lsmartsvn/aAa;Lsmartsvn/avk;Lsmartsvn/ua;Lsmartsvn/tW;)Lsmartsvn/pO;+534 j smartsvn.TP.a(Lsmartsvn/axk;Lsmartsvn/ua;Lsmartsvn/tW;)Lsmartsvn/pO;+159 j smartsvn.aFY.a(Lsmartsvn/ua;Lsmartsvn/tW;)Lsmartsvn/pO;+70 j smartsvn.aFT.a(Lsmartsvn/ua;Lsmartsvn/tW;)Lsmartsvn/pO;+62 j smartsvn.qv.run()V+14 j smartsvn.aFS.run()V+34 j smartsvn.qb.run()V+81 v ~StubRoutines::call_stub --- P R O C E S S --- Java Threads: ( => current thread ) 0x3e120400 JavaThread "QThreadPoolThread-4" daemon [_thread_blocked, id=13008, stack(0x41ec,0x41f1)] 0x3e11f800 JavaThread "QThreadPoolThread-3" daemon [_thread_blocked, id=11568, stack(0x41d6,0x41db)] 0x3e11f000 JavaThread "QThreadPoolThread-2" daemon [_thread_blocked, id=10248, stack(0x4084,0x4089)] 0x3e103c00 JavaThread "Transaction-Refresher (srvptsvn--svn-rd)-5" daemon [_thread_blocked, id=15620, stack(0x404f,0x4054)] 0x3e0ab800 JavaThread "QThreadPoolThread-1" daemon [_thread_blocked, id=9172, stack(0x401d,0x4022)] 0x3e03d400 JavaThread "Transaction-4" [_thread_blocked, id=8736, stack(0x3d42,0x3d47)] =>0x3e026400 JavaThre
Re: JavaHL, 1.9: Bad file descriptor, Stream doesn't support thiscapability errors
The fix is alread on the 1.9.x branch and will be part of the 1.9.1 release Perfect, I can confirm that it is working now. Thanks. -- Tom On 25.08.2015 12:39, Branko Čibej wrote: On 25.08.2015 12:36, Thomas Singer wrote: Is this bug already reported in the issue tracker? I've searched but could not found. Should I report it? We don't need that. The fix is alread on the 1.9.x branch and will be part of the 1.9.1 release, which we'll probably expedite precisely because of this bug. -- Brane -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog On 20.08.2015 09:28, b...@qqmail.nl wrote: Hi Thomas, The Subversion version of the fix is nominated for 1.9.1 [[ + * r1696222, r1696225 + Implement polling on named pipes on Windows to resolve svn+ssh:// problems + Justification: + Without this patch operations like checkout just fail with an error. + This is a regression as older Subversion releases ignored the error. + Votes: ]] Apr just returns EBADF on any attempt to poll on a file or pipe on Windows. This workaround on the Subversion side makes us support polling on pipes. (In Subversion 1.8 we always assumed that there was no data waiting, because we never bothered to check for an error) The apr version of the patch is harder than I expected, because the poll function supports many flags of which we can really only implement one new variant, that can’t really be combined with any other flags. We need one more vote on this, before we can start the release process on 1.9.1. I would hope we can also get r1696695 in the release, as that problem appears to break Subversion for at least some Linux distributions. We might want to consider also fixing the polling in 1.8 (and 1.7?), as that would allow exiting much earlier when a commit fails. Currently Subversion (when using svn+ssh:// on Windows) just goes on trying to commit on Windows and only notices that svnserve returned an error when done. Bert Sent from Mail for Windows 10 From: Thomas Singer Sent: donderdag 20 augustus 2015 08:23 To: dev@subversion.apache.org Subject: Re: JavaHL, 1.9: Bad file descriptor, Stream doesn't support thiscapability errors Hi Bert, I'll see if I can properly fix this (preferably in both Subversion and Apr), without reverting to just ignoring errors. Did you have any success fixing it yet? Is there already a bug entered in the issue tracker? I'd rate it as blocker priority. -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog
Re: JavaHL, 1.9: Bad file descriptor, Stream doesn't support thiscapability errors
Is this bug already reported in the issue tracker? I've searched but could not found. Should I report it? -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog On 20.08.2015 09:28, b...@qqmail.nl wrote: Hi Thomas, The Subversion version of the fix is nominated for 1.9.1 [[ + * r1696222, r1696225 + Implement polling on named pipes on Windows to resolve svn+ssh:// problems + Justification: + Without this patch operations like checkout just fail with an error. + This is a regression as older Subversion releases ignored the error. + Votes: ]] Apr just returns EBADF on any attempt to poll on a file or pipe on Windows. This workaround on the Subversion side makes us support polling on pipes. (In Subversion 1.8 we always assumed that there was no data waiting, because we never bothered to check for an error) The apr version of the patch is harder than I expected, because the poll function supports many flags of which we can really only implement one new variant, that can’t really be combined with any other flags. We need one more vote on this, before we can start the release process on 1.9.1. I would hope we can also get r1696695 in the release, as that problem appears to break Subversion for at least some Linux distributions. We might want to consider also fixing the polling in 1.8 (and 1.7?), as that would allow exiting much earlier when a commit fails. Currently Subversion (when using svn+ssh:// on Windows) just goes on trying to commit on Windows and only notices that svnserve returned an error when done. Bert Sent from Mail for Windows 10 From: Thomas Singer Sent: donderdag 20 augustus 2015 08:23 To: dev@subversion.apache.org Subject: Re: JavaHL, 1.9: Bad file descriptor, Stream doesn't support thiscapability errors Hi Bert, I'll see if I can properly fix this (preferably in both Subversion and Apr), without reverting to just ignoring errors. Did you have any success fixing it yet? Is there already a bug entered in the issue tracker? I'd rate it as blocker priority. -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog
Re: JavaHL, 1.9: Bad file descriptor, Stream doesn't support this capability errors
Hi Bert, I'll see if I can properly fix this (preferably in both Subversion and Apr), without reverting to just ignoring errors. Did you have any success fixing it yet? Is there already a bug entered in the issue tracker? I'd rate it as blocker priority. -- Best regards, Thomas Singer = syntevo GmbH http://www.syntevo.com http://www.syntevo.com/blog
Re: JavaHL, 1.9: Bad file descriptor, Stream doesn't support this capability errors
Is *anybody* of the Windows users able to commit using svn+ssh:// and SVN 1.9? -- Thomas 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-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 descriptor at org.apache.subversion.javahl.SVNClient.copy(Native Method) at ... He hasn't encountered such problems with 1.8 versions. AFAIU, he is connecting using SSH. Is this an SSH-related problem? Could it be related to the underlying SSH client? Which platform is this? Can the user reproduce this problem with the command-line svn on the same machine? It's on Windows, in combination with SSH. I'm now able to reproduce this problem myself and it looks like a regression to me: It's reproducible with our own Windows binaries as well as with the WANdisco binaries. It's reproducible with Plink/Pageant as well as with Trilead SSH. The commit works fine with Subversion 1.8. Is there any additional information/debugging I can do on my side? I'd still want to know if the command-line client works. If not, a minimal Java program using JavaHL that demonstrates the problem would be a real help. -- Brane
Re: JavaHL, 1.9: Bad file descriptor, Stream doesn't support this capability errors
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-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 descriptor at org.apache.subversion.javahl.SVNClient.copy(Native Method) at ... He hasn't encountered such problems with 1.8 versions. AFAIU, he is connecting using SSH. Is this an SSH-related problem? Could it be related to the underlying SSH client? Which platform is this? Can the user reproduce this problem with the command-line svn on the same machine? It's on Windows, in combination with SSH. I'm now able to reproduce this problem myself and it looks like a regression to me: It's reproducible with our own Windows binaries as well as with the WANdisco binaries. It's reproducible with Plink/Pageant as well as with Trilead SSH. The commit works fine with Subversion 1.8. Is there any additional information/debugging I can do on my side? I'd still want to know if the command-line client works. No, it doesn't. That's what Marc meant with It's reproducible with our own Windows binaries as well as with the WANdisco binaries. The problem is reproducible independent of SmartSVN. -- Thomas
