Re: detach.py script isn't updated for 1.8/1.9
Hi, Stefan Sperling s...@elego.de writes: On Mon, Aug 17, 2015 at 11:03:12AM +0100, Philip Martin wrote: The script was an experiment that was never finished. I was wrong, the script does handle SQLite indices as it copies the entire schema. The main problem is we don't really know how well it works or exactly what has to change to update it. Why don't we just remove it? It was an experiment and it got forgotten. Thanks for the insight, Philip. So I guess the question remains, whether it should be removed or not and if it is removed whether it should also be removed from 1.8 and 1.9. I can just provide some thoughts from the users point of view here, in case u want to take that into account for ur decision: The script as it stands right now is not usable with any of the three versions (1.8, 1.9, 1.10). It simply doesn't work without modification on the WC. Therefore to a user it looks like it's bugged. That leaves it with the single usage of acting as some means of documentation for someone to approach the use-case to detach part of a WC. Given that there is no other way to do this with the core SVN version, it would not be unreasonable to keep that script for this purpose. So guess there would be three options to go: 1. make the detach-script compatible with 1.8/1.9 and provide this in a bugfix release 2. add some documentation to the script to point out it's an experiment and can be used as a starting point, if someone needs the functionality and cannot use a different approach 3. drop the script Regards, Stefan
Re: svn commit: r1696225 - in /subversion/trunk/subversion: libsvn_subr/stream.c tests/libsvn_ra/ra-test.c
On 17.08.2015 11:40, rhuij...@apache.org wrote:
Author: rhuijben
Date: Mon Aug 17 09:40:04 2015
New Revision: 1696225
URL: http://svn.apache.org/r1696225
Log:
Following up on r1696222, implement polling on pipes on Windows.
Note that PeekNamedPipe() also works on unnamed pipes, such as those created
by apr to hook stdin and stdout of subprocesses.
* subversion/libsvn_subr/stream.c
(data_available_handler_apr): Implement polling on pipes for Win32.
* subversion/tests/libsvn_ra/ra-test.c
(test_funcs): Remove Windows specific XFail marking.
Modified:
subversion/trunk/subversion/libsvn_subr/stream.c
subversion/trunk/subversion/tests/libsvn_ra/ra-test.c
Modified: subversion/trunk/subversion/libsvn_subr/stream.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/stream.c?rev=1696225r1=1696224r2=1696225view=diff
==
--- subversion/trunk/subversion/libsvn_subr/stream.c (original)
+++ subversion/trunk/subversion/libsvn_subr/stream.c Mon Aug 17 09:40:04 2015
@@ -942,8 +942,9 @@ static svn_error_t *
data_available_handler_apr(void *baton, svn_boolean_t *data_available)
{
struct baton_apr *btn = baton;
- apr_pollfd_t pfd;
apr_status_t status;
+#if !defined(WIN32) || APR_FILES_AS_SOCKETS
+ apr_pollfd_t pfd;
int n;
pfd.desc_type = APR_POLL_FILE;
@@ -973,6 +974,24 @@ data_available_handler_apr(void *baton,
failed)),
NULL);
}
+#else
+ HANDLE h;
+ DWORD dwAvail;
+ status = apr_os_file_get(h, btn-file);
+
+ if (status)
+return svn_error_wrap_apr(status, NULL);
+
+ if (PeekNamedPipe(h, NULL, 0, NULL, dwAvail, NULL))
+{
+ *data_available = (dwAvail 0);
+ return SVN_NO_ERROR;
+}
+
+ return svn_error_create(SVN_ERR_STREAM_NOT_SUPPORTED,
+ svn_error_wrap_apr(apr_get_os_error(), NULL),
+ _(Windows doesn't support polling on files));
+#endif
}
Interesting solution ... should be in APR, I guess? I'm wondering it's
really safe to expect that the socked we got from APR is really an
(un)named pipe?
-- Brane
RE: JavaHL, 1.9: Bad file descriptor, Stream doesn't support this capability errors
-Original Message-
From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
Sent: maandag 17 augustus 2015 08:58
To: Philip Martin philip.mar...@wandisco.com
Cc: Branko Čibej br...@wandisco.com; dev@subversion.apache.org
Subject: Re: JavaHL, 1.9: Bad file descriptor, Stream doesn't support this
capability errors
On 14.08.2015 11:21, Philip Martin wrote:
Marc Strapetz marc.strap...@syntevo.com 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
00 ? .
A- ? ? dir
A- ? ? dir\subfile
A- ? ? file
C:\temp\svn svn commit -m initial import
svn: E140004: Commit failed (details follow):
svn: E140004: Stream doesn't support this capability
svn: E09: Polling for available data on filestream failed: Bad
file descriptor
On the server, we are running SVN 1.6.17.
That's the apr_poll() call in data_available_handler_apr() failing, and
E09 could be EBADF. I suppose the file could have been closed, or
the file descriptor could have been overwritten. What do you see in the
debugger?
Philip, is there any input you are expecting from my side? Because I
don't have an idea how I should debug this on the server side.
Do you think the problem can be caused by the rather old version SVN
1.6.17 on the server? Either way, there must have happened something in
the SVN 1.9 release as well, breaking this.
The problem is caused by apr not implementing file polling on Windows.
[[
else if (aprset[i].desc_type == APR_POLL_FILE) {
#if !APR_FILES_AS_SOCKETS
return APR_EBADF;
#else
fd = aprset[i].desc.f-filedes;
#endif
}
]]
Before Subversion 1.9 the code around the polling ignored errors and just
checked for success.
I'll see if I can properly fix this (preferably in both Subversion and Apr),
without reverting to just ignoring errors.
Bert
RE: svn commit: r1696225 - in /subversion/trunk/subversion: libsvn_subr/stream.c tests/libsvn_ra/ra-test.c
-Original Message-
From: Branko Čibej [mailto:br...@wandisco.com]
Sent: maandag 17 augustus 2015 11:44
To: dev@subversion.apache.org
Subject: Re: svn commit: r1696225 - in /subversion/trunk/subversion:
libsvn_subr/stream.c tests/libsvn_ra/ra-test.c
On 17.08.2015 11:40, rhuij...@apache.org wrote:
Author: rhuijben
Date: Mon Aug 17 09:40:04 2015
New Revision: 1696225
URL: http://svn.apache.org/r1696225
Log:
Following up on r1696222, implement polling on pipes on Windows.
Note that PeekNamedPipe() also works on unnamed pipes, such as those
created
by apr to hook stdin and stdout of subprocesses.
* subversion/libsvn_subr/stream.c
(data_available_handler_apr): Implement polling on pipes for Win32.
* subversion/tests/libsvn_ra/ra-test.c
(test_funcs): Remove Windows specific XFail marking.
Modified:
subversion/trunk/subversion/libsvn_subr/stream.c
subversion/trunk/subversion/tests/libsvn_ra/ra-test.c
Modified: subversion/trunk/subversion/libsvn_subr/stream.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/stream.
c?rev=1696225r1=1696224r2=1696225view=diff
==
--- subversion/trunk/subversion/libsvn_subr/stream.c (original)
+++ subversion/trunk/subversion/libsvn_subr/stream.c Mon Aug 17 09:40:04
2015
@@ -942,8 +942,9 @@ static svn_error_t *
data_available_handler_apr(void *baton, svn_boolean_t *data_available)
{
struct baton_apr *btn = baton;
- apr_pollfd_t pfd;
apr_status_t status;
+#if !defined(WIN32) || APR_FILES_AS_SOCKETS
+ apr_pollfd_t pfd;
int n;
pfd.desc_type = APR_POLL_FILE;
@@ -973,6 +974,24 @@ data_available_handler_apr(void *baton,
failed)),
NULL);
}
+#else
+ HANDLE h;
+ DWORD dwAvail;
+ status = apr_os_file_get(h, btn-file);
+
+ if (status)
+return svn_error_wrap_apr(status, NULL);
+
+ if (PeekNamedPipe(h, NULL, 0, NULL, dwAvail, NULL))
+{
+ *data_available = (dwAvail 0);
+ return SVN_NO_ERROR;
+}
+
+ return svn_error_create(SVN_ERR_STREAM_NOT_SUPPORTED,
+ svn_error_wrap_apr(apr_get_os_error(), NULL),
+ _(Windows doesn't support polling on files));
+#endif
}
Interesting solution ... should be in APR, I guess? I'm wondering it's
really safe to expect that the socked we got from APR is really an
(un)named pipe?
The only other case would be a normal file, which would just return an error.
Apr should be able to tell the difference between pipes and files for the
handles it created itself... Working on a patch for apr now.
(I think it is possible to ask apr to wrap an existing os handle...)
Bert
Re: bash_completion - subversion add: svn ls/merge ^/remote path
Christian Ferbar ch...@qnipp.com writes:
--- /etc/bash_completion.d/subversion 2015-08-11 22:17:11.80800 +0200
+++ subversion2015-08-12 11:13:42.135616669 +0200
@@ -420,6 +420,16 @@
COMPREPLY=( $(compgen -W $choices -- $suffix ) )
return
+elif [[ $cmd == @(ls|list) $cur == ^/* ]] ; then
+ # autocomplete für svn ls ^/bla
+ if [[ $cur =~ ((.*/)([^/]*)) ]] ; then
+url=${BASH_REMATCH[2]}
+ path=${BASH_REMATCH[3]}
+remote_files=$(svn ls $url)
What about error messages from the command? Should they be dropped or
displayed? What about authentication prompts? Is --non-interactive
needed?
--
Philip Martin
WANdisco
Re: detach.py script isn't updated for 1.8/1.9
Stefan luke1...@gmx.de writes: Would it be possible to fix/update that script so it will also be usable with 1.8/1.9 WCs? Unlikely. Getting the script to handle the client-size move tracking that is recorded in 1.8 would be complicated. The script will only run if you remove the This script is unfinished message and it is true that support for 1.7 is not complete, e.g. no support for SQLite indices. The script was an experiment that was never finished. -- Philip Martin WANdisco
Re: detach.py script isn't updated for 1.8/1.9
On Mon, Aug 17, 2015 at 11:03:12AM +0100, Philip Martin wrote: The script was an experiment that was never finished. Why don't we just remove it?
Re: detach.py script isn't updated for 1.8/1.9
Stefan luke1...@gmx.de writes: 2. add some documentation to the script to point out it's an experiment and can be used as a starting point, if someone needs the functionality and cannot use a different approach When run the only thing the script does is print: Exception: This script is unfinished and not ready to be used on live data. Trust us. I don't really see how we could make it clearer. -- Philip Martin WANdisco
upcoming MaxSVN Subversion distribution (for review)
Hi, as mentioned on IRC already a few weeks ago, I'm about to release a Windows distribution of Subversion named 'MaxSVN'. I'm looking here for feedback/concerns/requests/requirements from any of the Subversion developers for publishing this distribution. Especially with regards (but not limited) to the readme-file contained in the distribution and the introduction of the product on the webpage. Please note that none of your concerns/requests need to be seconded by any legal statement. Just name whatever you think should be added/removed/changed and I'll make sure it gets done. I've put together a sample package of the distribution here: http://www.luke1410.de/raw/maxsvn/maxsvn_1.10.0.1.zip (Win 64-bit binaries of the current trunk) http://www.luke1410.de/raw/maxsvn/maxsvn_1.10.0.1_symbols.zip (corresponding symbol files) http://www.luke1410.de/raw/maxsvn/readme.txt (the readme.txt-file as it is contained in maxsvn_1.10.0.1.zip) Also the product overview page is set-up with the current draft for your review: http://www.luke1410.de/typo3/index.php?id=97 A word on MaxSVN: It's purpose and aim is significantly different from usual distributions out there and while originally it was just done for my own purposes (as a sideeffect of building the svn-mergeinfo-normalizer tool), I hope that the distribution will end-up being useful for the Subversion project as well as for others out there. That said, the main purpose of the distribution is: - to provide others (mainly developers and early adopter enthusiasts) with the ready to use subversion command line tools - use the distribution as a test-ground to test Subversion with the latest build tools and dependencies - debugable versions (by providing symbol files alongside the releases) It's important to understand that this distribution is not aiming for productive use. The features of the distribution will be: - using the latest dependencies - built with the latest build tools - based on the latest development branches before these are being put together in a real release The main gain for the Subversion project I see lies in the automated build process which will test the latest development sources against the latest dependencies/build tools so that issues are being identified as soon as possible and won't make it (unnoticed) into real product releases. Thanks for your time. Regards, Stefan
Re: detach.py script isn't updated for 1.8/1.9
Stefan Sperling s...@elego.de writes: On Mon, Aug 17, 2015 at 11:03:12AM +0100, Philip Martin wrote: The script was an experiment that was never finished. I was wrong, the script does handle SQLite indices as it copies the entire schema. The main problem is we don't really know how well it works or exactly what has to change to update it. Why don't we just remove it? It was an experiment and it got forgotten. -- Philip Martin WANdisco
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 11:21, Philip Martin wrote: Marc Strapetz marc.strap...@syntevo.com 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 00 ? . A- ? ? dir A- ? ? dir\subfile A- ? ? file C:\temp\svn svn commit -m initial import svn: E140004: Commit failed (details follow): svn: E140004: Stream doesn't support this capability svn: E09: Polling for available data on filestream failed: Bad file descriptor On the server, we are running SVN 1.6.17. That's the apr_poll() call in data_available_handler_apr() failing, and E09 could be EBADF. I suppose the file could have been closed, or the file descriptor could have been overwritten. What do you see in the debugger? Philip, is there any input you are expecting from my side? Because I don't have an idea how I should debug this on the server side. Do you think the problem can be caused by the rather old version SVN 1.6.17 on the server? Either way, there must have happened something in the SVN 1.9 release as well, breaking this. -Marc
