Re: svnadmin crash
On 19.06.2013 02:04, Mat Berchtold wrote: svnadmin upgrade crash Divide by zero Noted. The issue is known and will be fixed in 1.8.1; it's caused by upgrading unsharded FSFS repositories that were created by moderately old versions of FSFS. For now, the best suggestion is to not run svnadmin upgrade; it is not required for the server to work. -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: vimdiff wrapper for diff-cmd not working with 1.8
On Jun 19, 2013, at 01:58 , Philip Martin wrote: [cc to dev] Michael Schlottke m.schlot...@aia.rwth-aachen.de writes: I just installed svn 1.8 on our cluster. Before, we used svn 1.7.9 and a little vimdiff wrapper (taken, with a few changes, from http://svnbook.red-bean.com/nightly/en/svn.advanced.externaldifftools.html#svn.advanced.externaldifftools.diff), which worked like a charm when called as svn diff --diff-cmd=diffwrap.py filename. However, with svn 1.8 something seems to have changed: The only lines I see after executing the command above are Index: filename === and the terminal hangs. When I enter :qa!, I get the following line Vim: Warning: Output is not to a terminal and I am back in the terminal. I have not changed anything in the wrapper script, and indeed, when I manually use it with our old svn version (1.7.9), it still works. Does anyone have an idea what has changed in the way the diff-cmd is invoked? And, more importantly, how I can change the vimdiff wrapper so it works again? I invoked vimdiff using a diff-cmd of: #!/bin/sh vimdiff $6 $7 That's the exact same command I used. this works with 1.7 but fails as you describe in 1.8. The cause is the conversion of diff to the stream API. The code in libsvn_client/diff.c:diff_content_changed now gets a Subversion stream rather than an APR file for output so it does: /* We deal in streams, but svn_io_run_diff2() deals in file handles, unfortunately, so we need to make these temporary files, and then copy the contents to our stream. */ SVN_ERR(svn_io_open_unique_file3(outfile, outfilename, NULL, svn_io_file_del_on_pool_cleanup, scratch_pool, scratch_pool)); and this use of a temporary file prevents the use of an external diff that expects a terminal. The only way I see to fix this is to stop using the stream API when the external diff command wants a terminal. I don't think it is possible to do this automatically, perhaps we need an --interactive-diff option? Do you have an idea of how hard this is to achieve, or how long it would take to create a patch? I'd be happy to volunteer as a tester… Or do you know of an interim hack that I could use until it is properly fixed? We'd really love to use svn 1.8 (especially with the new merging capabilities), but this is a major hindrance. Michael -- Michael Schlottke SimLab Highly Scalable Fluids Solids Engineering Jülich Aachen Research Alliance (JARA-HPC) RWTH Aachen University Wüllnerstraße 5a 52062 Aachen Germany Phone: +49 (241) 80 95188 Fax: +49 (241) 80 92257 Mail: m.schlot...@aia.rwth-aachen.de Web: http://www.jara.org/jara-hpc smime.p7s Description: S/MIME cryptographic signature
please unsubscribe me from the list
Please unsubscribe me from the list, unsubscribe-us...@subversion.apache.org seems not to work! Regards, Alexander Ivanenko
Automatic windows authentication using serf/svn 1.8
Hi. Our team is using subversion server hosted on windows machine by Apache and https protocol and is using SSPI authentication. With svn 1.7 everything works fine, including automatic authentication with currently logged in windows user. Today I upgraded to svn 1.8 and the automatic authentication does not work anymore. If I set http-library = serf then 1.7 client fails to perform automatic authentication as well. Is there some configuration setting I am missing or is it limitation of serf library? Gert
Re: vimdiff wrapper for diff-cmd not working with 1.8
On Wed, Jun 19, 2013 at 9:11 AM, Michael Schlottke m.schlot...@aia.rwth-aachen.de wrote: Do you have an idea of how hard this is to achieve, or how long it would take to create a patch? I'd be happy to volunteer as a tester… Or do you know of an interim hack that I could use until it is properly fixed? I don't imagine it'd take very long at all to implement but the problem of course is that we really should think carefully how we go about doing this. If we can detect this at runtime we probably should. I'm not sure what platform you're on but using the GUI version of vimdiff would get around this for you in the meantime. You'll end up with one vimdiff window per file. On the Mac for instance all I did was symlink mvimdiff to mvim (which is essentially equivalent to gvim on other platforms) and then change the wrapper to use that instead of vimdiff. I realize it's not ideal but it should give you almost the same functionality that you had before.
Re: vimdiff wrapper for diff-cmd not working with 1.8
Ben Reser b...@reser.org writes: I don't imagine it'd take very long at all to implement but the problem of course is that we really should think carefully how we go about doing this. If we can detect this at runtime we probably should. I don't see how Subversion can determine that one script needs a terminal while another can use a file, only the user knows that. It's also hard to fix 1.8, how do we pass the information into the client library without changing the API? Perhaps we could recognise a special part of the command name or a special external parameter, so --diff-cmd svn:interactive:myscript or --diff-cmd myscript -x svn:interactive gets a terminal while --diff-cmd myscript gets a file. -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data www.wandisco.com
Re: vimdiff wrapper for diff-cmd not working with 1.8
On Jun 19, 2013, at 09:56 , Ben Reser wrote: On Wed, Jun 19, 2013 at 9:11 AM, Michael Schlottke m.schlot...@aia.rwth-aachen.de wrote: Do you have an idea of how hard this is to achieve, or how long it would take to create a patch? I'd be happy to volunteer as a tester… Or do you know of an interim hack that I could use until it is properly fixed? I don't imagine it'd take very long at all to implement but the problem of course is that we really should think carefully how we go about doing this. If we can detect this at runtime we probably should. I fully agree that this should be done right, and preferably without adding complexity through additional flags. However, for now I'd prefer a quick-n-dirty solution rather than not being able to upgrade at all. I know this is asking for quite something, especially since I don't know how to do it myself :-/ I'm not sure what platform you're on but using the GUI version of vimdiff would get around this for you in the meantime. Thanks for the tip! Unfortunately, gvim is not an option unfortunately, since most of the machines do not have a proper version of gvim installed. Michael smime.p7s Description: S/MIME cryptographic signature
Re: vimdiff wrapper for diff-cmd not working with 1.8
Michael Schlottke m.schlot...@aia.rwth-aachen.de writes:
However, for now I'd prefer a quick-n-dirty solution rather than not
being able to upgrade at all. I know this is asking for quite
something, especially since I don't know how to do it myself :-/
Here's my really quick-n-dirty patch used during investigation. It's
not going to be committed. If it breaks you get to keep the pieces:
Index: subversion/libsvn_client/diff.c
===
--- subversion/libsvn_client/diff.c (revision 1494268)
+++ subversion/libsvn_client/diff.c (working copy)
@@ -816,13 +816,18 @@ diff_content_changed(svn_boolean_t *wrote_header,
svn_io_file_del_on_pool_cleanup,
scratch_pool, scratch_pool));
+ {
+apr_file_t *stdout_file;
+apr_file_open_stdout(stdout_file, scratch_pool);
+
SVN_ERR(svn_io_run_diff2(.,
diff_cmd_baton-options.for_external.argv,
diff_cmd_baton-options.for_external.argc,
label1, label2,
tmpfile1, tmpfile2,
- exitcode, outfile, errfile,
+ exitcode, stdout_file, errfile,
diff_cmd_baton-diff_cmd, scratch_pool));
+ }
SVN_ERR(svn_io_file_close(outfile, scratch_pool));
SVN_ERR(svn_io_file_close(errfile, scratch_pool));
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com
Crash in 1.8.0
Hi, I just downloaded the subversion 1.8.0 source, and built it for Windows (I am running XP. I can supply build info as well, if required, build script and output). When I upgraded my repositories, (just) one of them caused svnadmin to crash. I have included log- and dmp-file, let me know, if you need anything else. I will leave the repository untouched for now, in case we need to do some tests on it. Regards, -- Morten Due Jorgensen http://www.mdjnet.dk Process info: Cmd line: ..\svnadmin upgrade elite Working Dir: D:\subversion\repos Version: 1.8.0 (r1490375), compiled Jun 19 2013, 09:16:39 Platform: Windows OS version 5.1 build 2600 Service Pack 3 Exception: INT_DIVIDE_BY_ZERO Registers: eax= ebx=00bd9178 ecx= edx= esi=00b85110 edi=00b85138 eip=003772f5 esp=0012fcd8 ebp=0012fcfc efl=00010206 cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= Stacktrace: #1 0x003772f5 in (unknown function) #2 0x00378ca3 in (unknown function) #3 0x003793e8 in (unknown function) #4 0x003815e3 in (unknown function) #5 0x00383819 in svn_fs_upgrade() #6 0x003c77f4 in svn_repos_upgrade2() #7 0x0040303e in (unknown function) #8 0x00402c56 in (unknown function) #9 0x00404c87 in (unknown function) #10 0x004011a7 in (unknown function) #11 0x7c81776f in RegisterWaitForInputIdle() Loaded modules: 0x0040 D:\subversion\svnadmin.exe (1.8.0.48583, 77824 bytes) 0x7c90 C:\WINDOWS\system32\ntdll.dll (5.1.2600.6055, 729088 bytes) 0x7c80 C:\WINDOWS\system32\kernel32.dll (5.1.2600.6293, 1007616 bytes) 0x6eec D:\subversion\libapr-1.dll (1.4.6.0, 147456 bytes) 0x77dd C:\WINDOWS\system32\advapi32.dll (5.1.2600.5755, 634880 bytes) 0x77e7 C:\WINDOWS\system32\rpcrt4.dll (5.1.2600.6022, 602112 bytes) 0x77fe C:\WINDOWS\system32\secur32.dll (5.1.2600.5834, 69632 bytes) 0x71ab C:\WINDOWS\system32\ws2_32.dll (5.1.2600.5512, 94208 bytes) 0x77c1 C:\WINDOWS\system32\msvcrt.dll (7.0.2600.5512, 360448 bytes) 0x71aa C:\WINDOWS\system32\ws2help.dll (5.1.2600.5512, 32768 bytes) 0x71a5 C:\WINDOWS\system32\mswsock.dll (5.1.2600.5625, 258048 bytes) 0x7c9c C:\WINDOWS\system32\shell32.dll (6.0.2900.6242, 8482816 bytes) 0x77f1 C:\WINDOWS\system32\gdi32.dll (5.1.2600.5698, 299008 bytes) 0x7e41 C:\WINDOWS\system32\user32.dll (5.1.2600.5512, 593920 bytes) 0x77f6 C:\WINDOWS\system32\shlwapi.dll (6.0.2900.5912, 483328 bytes) 0x1000 D:\subversion\libsvn_delta-1.dll (1.8.0.48583, 122880 bytes) 0x78aa D:\subversion\msvcr100.dll (10.0.40219.325, 782336 bytes) 0x6ee6 D:\subversion\libaprutil-1.dll (1.5.2.0, 212992 bytes) 0x6ee5 D:\subversion\libapriconv-1.dll (1.2.1.0, 36864 bytes) 0x0042 D:\subversion\libsvn_subr-1.dll (1.8.0.48583, 1073152 bytes) 0x7678 C:\WINDOWS\system32\shfolder.dll (6.0.2900.5512, 36864 bytes) 0x774e C:\WINDOWS\system32\ole32.dll (5.1.2600.6168, 1302528 bytes) 0x77a8 C:\WINDOWS\system32\crypt32.dll (5.131.2600.6239, 610304 bytes) 0x77b2 C:\WINDOWS\system32\msasn1.dll (5.1.2600.5875, 73728 bytes) 0x77c0 C:\WINDOWS\system32\version.dll (5.1.2600.5512, 32768 bytes) 0x76bf C:\WINDOWS\system32\psapi.dll (5.1.2600.5512, 45056 bytes) 0x0036 D:\subversion\libsvn_fs-1.dll (1.8.0.48583, 221184 bytes) 0x003b D:\subversion\libsvn_repos-1.dll (1.8.0.48583, 180224 bytes) 0x7639 C:\WINDOWS\system32\imm32.dll (5.1.2600.5512, 118784 bytes) 0x773d C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll (6.0.2900.6028, 1060864 bytes) 0x5d09 C:\WINDOWS\system32\comctl32.dll (5.82.2900.6028, 630784 bytes) 0x59a6 C:\WINDOWS\system32\dbghelp.dll (5.1.2600.5512, 659456 bytes) svn-crash-log20130619092550.dmp Description: Binary data
Re: please unsubscribe me from the list
Alexander Ivanenko wrote: Please unsubscribe me from the list, unsubscribe-us...@subversion.apache.org seems not to work! you got the email adress wrong, look in the eMail headers for the correct spelling. -- Lorenz
Re: Crash in 1.8.0
Does %REPOS_DIR%\db\format contain 4 layout linear? If so, that's a known issue that will be fixed in 1.8.1. Daniel Morten Due Jorgensen wrote on Wed, Jun 19, 2013 at 10:28:09 +0200: Hi, I just downloaded the subversion 1.8.0 source, and built it for Windows (I am running XP. I can supply build info as well, if required, build script and output). When I upgraded my repositories, (just) one of them caused svnadmin to crash. I have included log- and dmp-file, let me know, if you need anything else. I will leave the repository untouched for now, in case we need to do some tests on it. Regards, -- Morten Due Jorgensen http://www.mdjnet.dk Process info: Cmd line: ..\svnadmin upgrade elite Working Dir: D:\subversion\repos Version: 1.8.0 (r1490375), compiled Jun 19 2013, 09:16:39 Platform: Windows OS version 5.1 build 2600 Service Pack 3 Exception: INT_DIVIDE_BY_ZERO Registers: eax= ebx=00bd9178 ecx= edx= esi=00b85110 edi=00b85138 eip=003772f5 esp=0012fcd8 ebp=0012fcfc efl=00010206 cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= Stacktrace: #1 0x003772f5 in (unknown function) #2 0x00378ca3 in (unknown function) #3 0x003793e8 in (unknown function) #4 0x003815e3 in (unknown function) #5 0x00383819 in svn_fs_upgrade() #6 0x003c77f4 in svn_repos_upgrade2() #7 0x0040303e in (unknown function) #8 0x00402c56 in (unknown function) #9 0x00404c87 in (unknown function) #10 0x004011a7 in (unknown function) #11 0x7c81776f in RegisterWaitForInputIdle() Loaded modules: 0x0040 D:\subversion\svnadmin.exe (1.8.0.48583, 77824 bytes) 0x7c90 C:\WINDOWS\system32\ntdll.dll (5.1.2600.6055, 729088 bytes) 0x7c80 C:\WINDOWS\system32\kernel32.dll (5.1.2600.6293, 1007616 bytes) 0x6eec D:\subversion\libapr-1.dll (1.4.6.0, 147456 bytes) 0x77dd C:\WINDOWS\system32\advapi32.dll (5.1.2600.5755, 634880 bytes) 0x77e7 C:\WINDOWS\system32\rpcrt4.dll (5.1.2600.6022, 602112 bytes) 0x77fe C:\WINDOWS\system32\secur32.dll (5.1.2600.5834, 69632 bytes) 0x71ab C:\WINDOWS\system32\ws2_32.dll (5.1.2600.5512, 94208 bytes) 0x77c1 C:\WINDOWS\system32\msvcrt.dll (7.0.2600.5512, 360448 bytes) 0x71aa C:\WINDOWS\system32\ws2help.dll (5.1.2600.5512, 32768 bytes) 0x71a5 C:\WINDOWS\system32\mswsock.dll (5.1.2600.5625, 258048 bytes) 0x7c9c C:\WINDOWS\system32\shell32.dll (6.0.2900.6242, 8482816 bytes) 0x77f1 C:\WINDOWS\system32\gdi32.dll (5.1.2600.5698, 299008 bytes) 0x7e41 C:\WINDOWS\system32\user32.dll (5.1.2600.5512, 593920 bytes) 0x77f6 C:\WINDOWS\system32\shlwapi.dll (6.0.2900.5912, 483328 bytes) 0x1000 D:\subversion\libsvn_delta-1.dll (1.8.0.48583, 122880 bytes) 0x78aa D:\subversion\msvcr100.dll (10.0.40219.325, 782336 bytes) 0x6ee6 D:\subversion\libaprutil-1.dll (1.5.2.0, 212992 bytes) 0x6ee5 D:\subversion\libapriconv-1.dll (1.2.1.0, 36864 bytes) 0x0042 D:\subversion\libsvn_subr-1.dll (1.8.0.48583, 1073152 bytes) 0x7678 C:\WINDOWS\system32\shfolder.dll (6.0.2900.5512, 36864 bytes) 0x774e C:\WINDOWS\system32\ole32.dll (5.1.2600.6168, 1302528 bytes) 0x77a8 C:\WINDOWS\system32\crypt32.dll (5.131.2600.6239, 610304 bytes) 0x77b2 C:\WINDOWS\system32\msasn1.dll (5.1.2600.5875, 73728 bytes) 0x77c0 C:\WINDOWS\system32\version.dll (5.1.2600.5512, 32768 bytes) 0x76bf C:\WINDOWS\system32\psapi.dll (5.1.2600.5512, 45056 bytes) 0x0036 D:\subversion\libsvn_fs-1.dll (1.8.0.48583, 221184 bytes) 0x003b D:\subversion\libsvn_repos-1.dll (1.8.0.48583, 180224 bytes) 0x7639 C:\WINDOWS\system32\imm32.dll (5.1.2600.5512, 118784 bytes) 0x773d C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll (6.0.2900.6028, 1060864 bytes) 0x5d09 C:\WINDOWS\system32\comctl32.dll (5.82.2900.6028, 630784 bytes) 0x59a6 C:\WINDOWS\system32\dbghelp.dll (5.1.2600.5512, 659456 bytes)
Re: Crash in 1.8.0
Morten Due Jorgensen wrote on Wed, Jun 19, 2013 at 11:42:32 +0200: In the meantime, should I clean up the repository before upgrading it to 1.8.1, or can I just upgrade it when 1.8.1 is released? The latter. Is the repository in a working order right now? For this particular failure mode, yes. Running 'svnadmin verify' won't hurt, though. Could I manually change the content of format, and re-upgrade? If you do that, your repository won't work (and you risk corrupting your data if you do it incorrectly). Daniel
Re: vimdiff wrapper for diff-cmd not working with 1.8
Philip Martin philip.mar...@wandisco.com writes:
Ben Reser b...@reser.org writes:
I don't imagine it'd take very long at all to implement but the
problem of course is that we really should think carefully how we go
about doing this. If we can detect this at runtime we probably
should.
I don't see how Subversion can determine that one script needs a
terminal while another can use a file, only the user knows that.
It's also hard to fix 1.8, how do we pass the information into the
client library without changing the API? Perhaps we could recognise a
special part of the command name or a special external parameter, so
--diff-cmd svn:interactive:myscript
or
--diff-cmd myscript -x svn:interactive
gets a terminal while
--diff-cmd myscript
gets a file.
Or we could extend the opaque svn_stream_t to make the underlying
apr_file_t available. Is mixing output to the file and output to
the stream acceptable or does it introduce output order problems?
Index: subversion/include/private/svn_io_private.h
===
--- subversion/include/private/svn_io_private.h (revision 1494268)
+++ subversion/include/private/svn_io_private.h (working copy)
@@ -90,7 +90,10 @@ svn_stream__set_is_buffered(svn_stream_t *stream,
svn_boolean_t
svn_stream__is_buffered(svn_stream_t *stream);
+apr_file_t *
+svn_stream__aprfile(svn_stream_t *stream);
+
#ifdef __cplusplus
}
#endif /* __cplusplus */
Index: subversion/libsvn_client/diff.c
===
--- subversion/libsvn_client/diff.c (revision 1494268)
+++ subversion/libsvn_client/diff.c (working copy)
@@ -51,6 +51,7 @@
#include private/svn_wc_private.h
#include private/svn_diff_private.h
#include private/svn_subr_private.h
+#include private/svn_io_private.h
#include svn_private_config.h
@@ -809,13 +810,22 @@ diff_content_changed(svn_boolean_t *wrote_header,
/* We deal in streams, but svn_io_run_diff2() deals in file handles,
unfortunately, so we need to make these temporary files, and then
copy the contents to our stream. */
- SVN_ERR(svn_io_open_unique_file3(outfile, outfilename, NULL,
- svn_io_file_del_on_pool_cleanup,
- scratch_pool, scratch_pool));
- SVN_ERR(svn_io_open_unique_file3(errfile, errfilename, NULL,
- svn_io_file_del_on_pool_cleanup,
- scratch_pool, scratch_pool));
+ outfile = svn_stream__aprfile(outstream);
+ if (!outfile)
+SVN_ERR(svn_io_open_unique_file3(outfile, outfilename, NULL,
+ svn_io_file_del_on_pool_cleanup,
+ scratch_pool, scratch_pool));
+ else
+outfilename = NULL;
+ errfile = svn_stream__aprfile(errstream);
+ if (!errfile)
+SVN_ERR(svn_io_open_unique_file3(errfile, errfilename, NULL,
+ svn_io_file_del_on_pool_cleanup,
+ scratch_pool, scratch_pool));
+ else
+errfilename = NULL;
+
SVN_ERR(svn_io_run_diff2(.,
diff_cmd_baton-options.for_external.argv,
diff_cmd_baton-options.for_external.argc,
@@ -824,20 +834,28 @@ diff_content_changed(svn_boolean_t *wrote_header,
exitcode, outfile, errfile,
diff_cmd_baton-diff_cmd, scratch_pool));
- SVN_ERR(svn_io_file_close(outfile, scratch_pool));
- SVN_ERR(svn_io_file_close(errfile, scratch_pool));
+ if (outfilename)
+SVN_ERR(svn_io_file_close(outfile, scratch_pool));
+ if (errfilename)
+SVN_ERR(svn_io_file_close(errfile, scratch_pool));
/* Now, open and copy our files to our output streams. */
- SVN_ERR(svn_stream_open_readonly(stream, outfilename,
- scratch_pool, scratch_pool));
- SVN_ERR(svn_stream_copy3(stream, svn_stream_disown(outstream,
- scratch_pool),
+ if (outfilename)
+{
+ SVN_ERR(svn_stream_open_readonly(stream, outfilename,
+ scratch_pool, scratch_pool));
+ SVN_ERR(svn_stream_copy3(stream, svn_stream_disown(outstream,
+ scratch_pool),
+ NULL, NULL, scratch_pool));
+}
+ if (errfilename)
+{
+ SVN_ERR(svn_stream_open_readonly(stream, errfilename,
+ scratch_pool, scratch_pool));
+ SVN_ERR(svn_stream_copy3(stream, svn_stream_disown(errstream,
+ scratch_pool),
Re: Links to Japanese version of the Subversion book dead?
On Wed, Jun 19, 2013 at 08:30:12AM +0900, Olaf Meeuwissen wrote: Hi, I'm looking for the Japanese translation of the Subversion book. The links to the single and multi-page versions on the cover page[1] appear to lead nowhere these days. [1] http://svnbook.red-bean.com/index.ja.html[1] I do see a page following that link. Perhaps it has already been fixed? If the link still has problems, please feel free to go ahead and file an issue in the book's issue tracker: http://code.google.com/p/svnbook/issues/list I'm not sure if there is an active translation effort for Japanese, though. Judging from recent commits made to the book, the only translation being currently worked on is German. You are of course welcome to fix that and help out with the Japanese version :) Googling a bit, what I've found so far are translations for 1.5 (final) and 1.7 (WIP) at what appears to be a personal site[2] but its maintenance state does not look very promising. Then there is also a version[3] at the University of Tokyo dated 2006-02-03. [2] http://www.caldron.jp/~nabetaro/svn/[2] [3] http://todo.issp.u-tokyo.ac.jp/archive/subversion/book.html[3] Is there any chance of getting the Japanese cover page[1] to point to up to date versions of the single and multi-page versions of the book? Should I submit a ticket for this?
Re: Automatic windows authentication using serf/svn 1.8
On Wed, Jun 19, 2013 at 10:48:35AM +0300, Gert Kello wrote: Hi. Our team is using subversion server hosted on windows machine by Apache and https protocol and is using SSPI authentication. With svn 1.7 everything works fine, including automatic authentication with currently logged in windows user. Today I upgraded to svn 1.8 and the automatic authentication does not work anymore. If I set http-library = serf then 1.7 client fails to perform automatic authentication as well. Is there some configuration setting I am missing or is it limitation of serf library? Gert I don't know anything about Windows authentication, but I could get some hints from Ivan Zhakov via IRC (he doesn't follow this mailing list). Perhaps this information helps: Apparently, if the server uses NTLM only, serf cannot authenticate to it, while neon could. serf supports SPNego though: http://en.wikipedia.org/wiki/SPNEGO Does this apply to your situation? Can you fix the problem by changing the server's configuration? The 1.8 release notes currently do not document the issue with NTLM-only servers. In my opinion they should mention it.
Problem, svn upgrade externals svn status (1.6 -- 1.7)
Hi! I have just started using the Subversion client 1.7.5 (I used 1.6.17 previously). To be able to use my old working copies I had to do a svnupgrade. But after the upgrade, the svn:externals are no longer fully recognized. The svn status command no longer recurses into sub-projects the way it used to. The difference can be seen by: - $ svn status proj1 X proj1/proj2-subdir $ $ svn status proj1-new X proj1-new/proj2-subdir Performing status on external item at 'proj1-new/proj2-subdir': - proj1 is the old working copy with svn upgrade applied. proj1-new is a fresh checkout of the project with the new client version. I have looked around in the .svn directory of the projects and found a difference that perhaps explains the difference i behaviour: - $ sqlite3 proj1/.svn/wc.db 'select * from EXTERNALS order by local_relpath' 1|proj2-subdir||1|normal|unknown $ $ sqlite3 proj1-new/.svn/wc.db 'select * from EXTERNALS order by local_relpath' 1|proj2-subdir||1|normal|dir||proj2|| - Note that the upgraded working copy has the externals entry marked unknown. Is what I describe here a known problem of the svn upgrade command? I also wonder if there is some way to get my existing working copies fully functional again without doing a new checkout. /Johan Holmberg
RE: Problem, svn upgrade externals svn status (1.6 -- 1.7)
Subversion 1.7.7 and later automatically upgrade all working copies referenced from svn:externals properties too. For older clients can use 'svn upgrade' on the externals itself. Bert From: Johan Holmberg [mailto:johan...@gmail.com] Sent: woensdag 19 juni 2013 13:12 To: users@subversion.apache.org Subject: Problem, svn upgrade externals svn status (1.6 -- 1.7) Hi! I have just started using the Subversion client 1.7.5 (I used 1.6.17 previously). To be able to use my old working copies I had to do a svn upgrade. But after the upgrade, the svn:externals are no longer fully recognized. The svn status command no longer recurses into sub-projects the way it used to. The difference can be seen by: - $ svn status proj1 X proj1/proj2-subdir $ $ svn status proj1-new X proj1-new/proj2-subdir Performing status on external item at 'proj1-new/proj2-subdir': - proj1 is the old working copy with svn upgrade applied. proj1-new is a fresh checkout of the project with the new client version. I have looked around in the .svn directory of the projects and found a difference that perhaps explains the difference i behaviour: - $ sqlite3 proj1/.svn/wc.db 'select * from EXTERNALS order by local_relpath' 1|proj2-subdir||1|normal|unknown $ $ sqlite3 proj1-new/.svn/wc.db 'select * from EXTERNALS order by local_relpath' 1|proj2-subdir||1|normal|dir||proj2|| - Note that the upgraded working copy has the externals entry marked unknown. Is what I describe here a known problem of the svn upgrade command? I also wonder if there is some way to get my existing working copies fully functional again without doing a new checkout. /Johan Holmberg
Re: Automatic windows authentication using serf/svn 1.8
Sorry, I did not mention it specifically: I can authenticate when I type in my domain user name/password when prompted. And, they are cached so they must be entered only once (per each domain password change I assume). But I would prefer if the authentication ticket is obtained from currently logged in windows user, not to type user name/password manually. That part is failing... Gert On 19 June 2013 14:02, Stefan Sperling s...@elego.de wrote: On Wed, Jun 19, 2013 at 10:48:35AM +0300, Gert Kello wrote: Hi. Our team is using subversion server hosted on windows machine by Apache and https protocol and is using SSPI authentication. With svn 1.7 everything works fine, including automatic authentication with currently logged in windows user. Today I upgraded to svn 1.8 and the automatic authentication does not work anymore. If I set http-library = serf then 1.7 client fails to perform automatic authentication as well. Is there some configuration setting I am missing or is it limitation of serf library? Gert I don't know anything about Windows authentication, but I could get some hints from Ivan Zhakov via IRC (he doesn't follow this mailing list). Perhaps this information helps: Apparently, if the server uses NTLM only, serf cannot authenticate to it, while neon could. serf supports SPNego though: http://en.wikipedia.org/wiki/SPNEGO Does this apply to your situation? Can you fix the problem by changing the server's configuration? The 1.8 release notes currently do not document the issue with NTLM-only servers. In my opinion they should mention it.
RE: Automatic windows authentication using serf/svn 1.8
Hi, I see the same problem on a setup which I setup years ago. The configuration used for years is: Location /svn AuthName My Subversion Repositories AuthType SSPI SSPIAuth On SSPIAuthoritative On SSPIDomain MyDomain SSPIOmitDomain On SSPIOfferBasic On SSPIUsernameCase lower #SSPIPackage Negotiate Require valid-user SSLRequireSSL DAV svn SVNListParentPath on SVNParentPath D:/Databases/Subversion/repos AuthzSVNAccessFile D:/Databases/Subversion/etc/subversion.xs /Location If I enable the 'SSPIPackage Negotiate' line (which I just added) then my Subversion 1.8 clients appear to authenticate correctly, but my neon based 1.7 clients fail with an even worse error that can't be resolved by just typing the password. Bert From: Gert Kello [mailto:gert.ke...@gmail.com] Sent: woensdag 19 juni 2013 14:01 To: users@subversion.apache.org Subject: Re: Automatic windows authentication using serf/svn 1.8 Sorry, I did not mention it specifically: I can authenticate when I type in my domain user name/password when prompted. And, they are cached so they must be entered only once (per each domain password change I assume). But I would prefer if the authentication ticket is obtained from currently logged in windows user, not to type user name/password manually. That part is failing... Gert On 19 June 2013 14:02, Stefan Sperling s...@elego.de mailto:s...@elego.de wrote: On Wed, Jun 19, 2013 at 10:48:35AM +0300, Gert Kello wrote: Hi. Our team is using subversion server hosted on windows machine by Apache and https protocol and is using SSPI authentication. With svn 1.7 everything works fine, including automatic authentication with currently logged in windows user. Today I upgraded to svn 1.8 and the automatic authentication does not work anymore. If I set http-library = serf then 1.7 client fails to perform automatic authentication as well. Is there some configuration setting I am missing or is it limitation of serf library? Gert I don't know anything about Windows authentication, but I could get some hints from Ivan Zhakov via IRC (he doesn't follow this mailing list). Perhaps this information helps: Apparently, if the server uses NTLM only, serf cannot authenticate to it, while neon could. serf supports SPNego though: http://en.wikipedia.org/wiki/SPNEGO Does this apply to your situation? Can you fix the problem by changing the server's configuration? The 1.8 release notes currently do not document the issue with NTLM-only servers. In my opinion they should mention it.
Re: user issues on svnrdump
On 06/19/2013 12:29 AM, Bo Chen wrote: It seens that the first dump will automatically strip-off trunk, but the second dump does not strip off dump. My subversion version is 1.7.5. What happen? Any suggestion for me to solve it? I believe you are describing issue #4101 http://subversion.tigris.org/issues/show_bug.cgi?id=4101 I fixed this bug some time ago, and the fix was released in Subversion 1.8.0. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Crash in 1.8.0 (db/format layout linear)
On 6/19/2013 5:30 AM, Daniel Shahaf wrote:
Does %REPOS_DIR%\db\format contain
4
layout linear?
If so, that's a known issue that will be fixed in 1.8.1.
Out of curiosity, which versions of SVN produced a layout linear? I'm
guessing that was from back in the SVN 1.4 days (repo format #2) as
layout sharded was added in SVN 1.5 (repo format #3)? At least,
that's the impression that I got from:
http://svn.apache.org/repos/asf/subversion/trunk/tools/server-side/fsfs-reshard.py
Checked our repositories with the following:
find /var/svn/ -maxdepth 3 -name format -exec grep -H 'layout' {} \;
Re: Automatic windows authentication using serf/svn 1.8
If I enable the ‘SSPIPackage Negotiate’ line (which I just added) then my Subversion 1.8 clients appear to authenticate correctly, but my neon based 1.7 clients fail with an even worse error that can’t be resolved by just typing the password. Seems like for me the SSPIPackage Negotiate is not working for 1.8 client. Did not try with 1.7 client. Gert
Re: Automatic windows authentication using serf/svn 1.8
Sorry, I did not mention it specifically: I can authenticate when I type in my domain user name/password when prompted. And, they are cached so they must be entered only once (per each domain password change I assume). But I would prefer if the authentication ticket is obtained from currently logged in windows user, not to type user name/password manually. That part is failing... Apparently, if the server uses NTLM only, serf cannot authenticate to it, while neon could. serf supports SPNego though: http://en.wikipedia.org/wiki/SPNEGO Does this apply to your situation? Can you fix the problem by changing the server's configuration? Well, I have SSPIOfferBasic ON in apache config (for mod_auth_sspi), so that's why authentication is working. If I set it to off then 1.8 client is not able to connect. Gert
Re: vimdiff wrapper for diff-cmd not working with 1.8
On Jun 19, 2013, at 12:08 , Philip Martin wrote: Philip Martin philip.mar...@wandisco.com writes: Ben Reser b...@reser.org writes: I don't imagine it'd take very long at all to implement but the problem of course is that we really should think carefully how we go about doing this. If we can detect this at runtime we probably should. I don't see how Subversion can determine that one script needs a terminal while another can use a file, only the user knows that. It's also hard to fix 1.8, how do we pass the information into the client library without changing the API? Perhaps we could recognise a special part of the command name or a special external parameter, so --diff-cmd svn:interactive:myscript or --diff-cmd myscript -x svn:interactive gets a terminal while --diff-cmd myscript gets a file. Or we could extend the opaque svn_stream_t to make the underlying apr_file_t available. Is mixing output to the file and output to the stream acceptable or does it introduce output order problems? I tried installed both your patches and both work just fine, thank you very much. Without giving it much thought, I now went for your second patch (it seemed to be the more sophisticated one). I think something like the -x svn:interactive option would be the best solution, since that way the diff-cmd really just remains a command. Thank you very much for your quick help! I'll definitely keep tabs on the development of this, I hope that one way or another it will make it into the svn code base. Michael smime.p7s Description: S/MIME cryptographic signature
RE: please unsubscribe me from the list
It’s users-unsubscribe … BOb From: Alexander Ivanenko [mailto:kito...@mail.ru] Sent: Wednesday, June 19, 2013 3:19 AM To: users@subversion.apache.org Subject: please unsubscribe me from the list Please unsubscribe me from the list, unsubscribe-us...@subversion.apache.orgmailto:unsubscribe-us...@subversion.apache.org seems not to work! Regards, Alexander Ivanenko
Re: Question about maximum size of svn repository (svn 1.6.1, backend as FSFS)
Just 7 Gigabytes? Our repository is 13 Gigabytes and I don't even think we have that big a project. Just FYI one of my repositories is now 130 Gigabytes big and is running just fine :) It has almost 94.5 thousand commits in it.
Re: Links to Japanese version of the Subversion book dead?
Stefan Sperling writes: On Wed, Jun 19, 2013 at 08:30:12AM +0900, Olaf Meeuwissen wrote: Hi, I'm looking for the Japanese translation of the Subversion book. The links to the single and multi-page versions on the cover page[1] appear to lead nowhere these days. [1] http://svnbook.red-bean.com/index.ja.html[1] I do see a page following that link. Perhaps it has already been fixed? Sorry, I guess I was not very clear. The Japanese cover page is there alright but the links on that page to the single[4] and multi-page[5] versions lead to pages that are *not* related to the book. In the past, these link did get you to the Japanese translation of the book. They no longer do. The original domain may have been taken over. [4] http://subversion.bluegate.com/doc/book.html [5] http://subversion.bluegate.com/doc/index.html If the link still has problems, please feel free to go ahead and file an issue in the book's issue tracker: http://code.google.com/p/svnbook/issues/list Thanks, I will. I'm not sure if there is an active translation effort for Japanese, though. Judging from recent commits made to the book, the only translation being currently worked on is German. You are of course welcome to fix that and help out with the Japanese version :) My Japanese skills are not up to such a task (besides me being too busy with other things). Perhaps that nabetaro, who did the (unfinished) translations at [2], can be nudged into working on this? # Just to be clear, I'm looking for a Japanese translation so that my # colleagues have something they can look at. I'm fine with the English # version. Googling a bit, what I've found so far are translations for 1.5 (final) and 1.7 (WIP) at what appears to be a personal site[2] but its maintenance state does not look very promising. Then there is also a version[3] at the University of Tokyo dated 2006-02-03. [2] http://www.caldron.jp/~nabetaro/svn/[2] [3] http://todo.issp.u-tokyo.ac.jp/archive/subversion/book.html[3] Is there any chance of getting the Japanese cover page[1] to point to up to date versions of the single and multi-page versions of the book? Should I submit a ticket for this? Sincerely, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
Apache Suvversion 1.8.x SRPM building
I'm working from my old github notes at: https://github.com/nkadel/subversion-1.7.9-srpm I do note the need for the seriously updated sqlite: that means that even RHEL 6 is going to need the relevant sqlite-amalgamation package, which is fine. I also note that libserf is not yet available for RHEL 6, even via the EPEL or Repoforge repositories, and I'll take another shot at getting that accepted at one of those repositories.
Subversion Failed - Not finding solution
Hello, Unfortunately, I cannot solve the problem, I'll have to uninstall, too bad because I have another PC where it works fine. I have no idea what's the problem. Repository Browser fails, no matter which repository I use (I tried with two different ones from XP-Dev, one of them was completely empty, just created). I'm using Windows 7 Home Premium 64 bits and I installed Tortoise SVN 1.8.0 for 64 bits. Regards, Veronica. --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.0\ext\subversion\subversion\libsvn_client\ra.c' line 647: assertion failed (peg_revnum != SVN_INVALID_REVNUM) --- Aceptar ---
