Re: bash_completion - subversion add: svn ls/merge ^/remote path
On 12 August 2015, Christian Ferbar wrote:
with this patch
svn ls ^/tabtab and svn merge ^/tabtab
will list the remote directories.
to get svn ls ^/ to autocomplete the path export SVN_BASH_COMPL_EXT=urls
has to be set, I don't know why this check is only in ls ...
Thank you, Chris. This is nice, but it could be much better...
Please can URL completion work on full URLs as well as on relative URLs?
Please can URL completion work for all relevant subcommands, not just
ls and merge?
Please can you declare the variables as local so they do not pollute
the user's environment when it executes:
-url=${BASH_REMATCH[2]}
+local url=${BASH_REMATCH[2]}
etc.
I notice the script already guesses a full URL for a merge, in the
following way: in a WC with 'branches' in its URL, it returns a full
URL ending in 'trunk', and in a WC with 'trunk' in its URL, it returns
a full URL ending in 'branches/' [1]. It would be nice if your new
completion would be able to continue completing the path after
'branches/'.
[1] It currently adds a space after 'branches/', which we should
suppress like this:
@@ -440,6 +450,7 @@ _svn()
elif [[ $here == */trunk* ]] ; then
# we guess that it is a merge from a branch
COMPREPLY=( $(compgen -W ${here/\/trunk*/\/branches\/} -- $cur ) )
+ compopt -o nospace
return 0
else
# no se, let us suggest the repository root...
- Julian
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
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. If not, a minimal Java program using JavaHL that demonstrates the problem would be a real help. No, the command-line client does not work: neither the binaries we are building nor WANdisco's binaries. 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. -Marc
Re: JavaHL, 1.9: Bad file descriptor, Stream doesn't support this capability errors
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? Breakpoint 2, data_available_handler_apr (baton=0x669500, data_available=0x7fffdccc) at ../src/subversion/libsvn_subr/stream.c:955 955 status = apr_poll(pfd, 1, n, 0); (gdb) p pfd.desc.f[0].filedes $6 = 6 On Linux I can check that 6 a valid file descriptor for this process: $ ls -l /proc/28574/fd/6 lr-x-- 1 pm pm 64 Aug 14 10:18 /proc/28574/fd/6 - pipe:[612259] -- Philip Martin WANdisco
Re: Review of sizeof usage
On 14.08.2015 01:25, Daniel Shahaf wrote: Branko Čibej wrote on Wed, Aug 12, 2015 at 10:07:49 +0200: On 12.08.2015 00:31, Daniel Shahaf wrote: We have had problems with both styles in the past, so neither is immune to bugs. I prefer the explicit type as it is easier to grep. The explicit type form is more accident-prone than the variable form because any change requires two modifications in the same statement instead of one. Why doesn't the compiler or buildbot catch accidents? I can't imagine a way for the compiler to emit warnings for such constructs without getting a far too large percentage of false positives. It's perfectly valid, and in many cases required by some object-like architecture, to allocate a buffer that has a different size than the one implied by the pointer that stores the return value. This is C, after all. Okay, so from the compiler authors' perspective, allocation size mismatches pointed-to-object size warnings should not be on by default. Fair enough. But from our perspective as Subversion maintainers, we never *intentionally* allocate a buffer smaller than the pointed-to object, so the warnings would be useful to us. We should therefore opt-in to them. Smaller buffer, probably not. Larger, definitely. -- Brane
Re: JavaHL, 1.9: Bad file descriptor, Stream doesn't support this capability errors
Philip Martin philip.mar...@wandisco.com writes: That's the apr_poll() call in data_available_handler_apr() failing, and E09 could be EBADF. Perhaps E09 is not EBADF on Windows? Looking on Google I find Error Code 9: The storage control block address is invalid. [ERROR_INVALID_BLOCK (0x9)] I don't know what that means. -- Philip Martin WANdisco
