Open MS Office Document results in numereous password requests on IE 8.0
We have the following problem in using Subversion (currently version 1.6.15): * I open the Windows Internet Explorer 8.0 * I enter there the URL to our Subversion repository: https://our.company.com/svn/REPO/trunk/docs * I have to login with my credentials (user ID and password). * I am able to navigate up and down the hierarchy of directories. The credentials are stored in the session, and are not asked again. * Every time I try to open an Office document (PPT, XLS, DOC), I see the following happening: o The windows download / open dialog is opened o When I press open, there comes a popup that asks for my credentials again. It is not the one of the browser, but of the application that the document belongs to. The icon of that popup is also the one of the application. o I see in the background a window that shows the whole URL in a dialog. The dialog is named "Open" (German: Öffnen), and has only the button "Cancel". o I then enter my credentials or approve the cached ones and press then "OK". o This popup comes then 3 times, with the same contents. o After the last one, the Office document is opened. * I have asked our admins and they told me that they think that the IE8 tries to establish a WebDAV connection, which fails 3 times. Then the office document is downloaded as normally. * This does not happen with any other browser: Firefox, Chrome, Opera, Sarari are all ok, even Internet Explorer 6.0 is. This happens only with Windows 7 (not sure about 64 bit only), and Internet Explorer 8. It has nothing to do with the client version of Subversion. I have 2 questions: 1. What is the reason for this behavior? 2. Is there anything we can do (server or client side) to fix that behavior? Thank you a lot Bye Markus Liebelt -- mailto:markus.lieb...@t-systems.com
Re: AuthzSVNAccessFile size issues
On Thu, Mar 22, 2012 at 01:49:44PM -0700, Joel Eidsath wrote: > For a longer term solution, I am looking at contributing some code to > mod_authz_svn to 1. allow rule caching, or 2. provide some sort of db > support. I would be interested in reviewing patches that add some sort of multi-backend support to our authz system. This problem comes up quite often especially among enterprise users of Subversion. Some would prefer to store authz rules directly in databases like LDAP, for example. A multi-backend mechanism for authz, of which the plaintext file is one possible backend, would certainly make sense.
Re: Open MS Office Document results in numereous password requests on IE 8.0
> We have the following problem in using Subversion (currently version
1.6.15):
> I open the Windows Internet Explorer 8.0
> I enter there the URL to our Subversion repository: https://
> our.company.com/svn/REPO/trunk/docs
> I have to login with my credentials (user ID and password).
> I am able to navigate up and down the hierarchy of directories. The
> credentials are stored in the session, and are not asked again.
> Every time I try to open an Office document (PPT, XLS, DOC), I see
> the following happening:
> The windows download / open dialog is opened
> When I press open, there comes a popup that asks for my credentials
> again. It is not the one of the browser, but of the application that
> the document belongs to. The icon of that popup is also the one of
> the application.
> I see in the background a window that shows the whole URL in a
> dialog. The dialog is named ?Open? (German: Öffnen), and has only
> the button ?Cancel?.
> I then enter my credentials or approve the cached ones and press then
?OK?.
> This popup comes then 3 times, with the same contents.
> After the last one, the Office document is opened.
> I have asked our admins and they told me that they think that the
> IE8 tries to establish a WebDAV connection, which fails 3 times.
> Then the office document is downloaded as normally.
> This does not happen with any other browser: Firefox, Chrome, Opera,
> Sarari are all ok, even Internet Explorer 6.0 is.
>
> This happens only with Windows 7 (not sure about 64 bit only), and
> Internet Explorer 8. It has nothing to do with the client version of
> Subversion.
>
> I have 2 questions:
> 1. What is the reason for this behavior?
> 2. Is there anything we can do (server or client side) to fix that
behavior?
Office (2010 especially) tries VERY hard to believe anything that responds
to WebDAV is a sharepoint server. It then heavily relies on sharepoint
specific behavior and doesn't understand when things don't work.
I don't remember if this fixes this particular problem, but using some
httpd.conf magic, you can try and force 405 errors when office
requests WebDAV:
RewriteEngine on
# Disallow Office 2010 WebDAV options request
RewriteCond %{REQUEST_METHOD} ^OPTIONS [OR]
RewriteCond %{REQUEST_METHOD} ^HEAD [OR]
RewriteCond %{REQUEST_METHOD} ^PROPFIND
RewriteCond %{HTTP_USER_AGENT} "^Microsoft Office"
RewriteRule .* - [R=405,L]
This obviously requires mod_rewrite being enabled and is a
server change. I don't promise this won't affect other things
negatively.
Kevin R.
Re: #4129 is reproducible Re: predecessor count for the root node-revision is wrong message
Philip Martin writes:
> Moving update_ancestry from tree.c to dag.c is one way to fix the
> problem.
This was applied in r1302613. I believe this also fixes the minfo-cnt
corruption that has been observed. To reproduce apply the following
patch to the old client to allow commit to be paused:
Index: ../src/subversion/libsvn_fs_fs/tree.c
===
--- ../src/subversion/libsvn_fs_fs/tree.c (revision 1302612)
+++ ../src/subversion/libsvn_fs_fs/tree.c (working copy)
@@ -1694,6 +1694,7 @@
any future merges will only be between that node and whatever
the root node of the youngest rev is by then. */
err = merge_changes(NULL, youngish_root_node, txn, conflict, iterpool);
+ { char buf[256]; fputs("waiting...", stdout);fgets(buf, 255, stdin); }
if (err)
{
if ((err->apr_err == SVN_ERR_FS_CONFLICT) && conflict_p)
Now the scenario:
svnadmin create repo
svn mkdir -mm file://`pwd`/repo/{A,B,C}
svn co file://`pwd`/repo wc1
svn co file://`pwd`/repo wc2
svn co file://`pwd`/repo wc3
svn ps svn:mergeinfo /P:2 wc1/A
svn ps svn:mergeinfo /Q:2 wc2/B
svn ps svn:mergeinfo /R:2 wc3/C
Now commit wc1 using the patched client running under valgrind. At the
first "waiting..." prompt commit wc2 using a standard client. Continue
the first commit to get a second "waiting..." prompt and commit wc3
using a standard client. Continue the first commit and valgrind reports
errors such as:
==23311== Conditional jump or move depends on uninitialised value(s)
==23311==at 0x98E0E5A: svn_fs_fs__dag_increment_mergeinfo_count (dag.c:544)
==23311==by 0x9906847: merge (tree.c:1551)
==23311==by 0x9906A18: merge_changes (tree.c:1599)
==23311==by 0x9906C06: svn_fs_fs__commit_txn (tree.c:1696)
==23311==by 0x6C8C6D9: svn_fs_commit_txn (fs-loader.c:646)
==23311==by 0x6A5B12C: svn_repos_fs_commit_txn (fs-wrap.c:59)
==23311==by 0x6A51D0E: close_edit (commit.c:693)
==23311==by 0x4E4A34F: svn_client__do_commit (commit_util.c:1898)
==23311==by 0x4E45723: svn_client_commit6 (commit.c:1689)
==23311==by 0x4097D6: svn_cl__commit (commit-cmd.c:169)
==23311==by 0x416FA1: main (main.c:2699)
==23311== Syscall param write(buf) points to uninitialised byte(s)
==23311==at 0x62CC0D0: __write_nocancel (syscall-template.S:82)
==23311==by 0x5E7D4FC: apr_file_flush_locked (readwrite.c:317)
==23311==by 0x5E7D7AF: apr_file_flush (readwrite.c:340)
==23311==by 0x5E7CFA4: apr_unix_file_cleanup (open.c:77)
==23311==by 0x59FADAF: svn_io_file_close (io.c:3092)
==23311==by 0x98E9083: svn_fs_fs__put_node_revision (fs_fs.c:2318)
==23311==by 0x98E1039: svn_fs_fs__dag_increment_mergeinfo_count (dag.c:575)
==23311==by 0x9906847: merge (tree.c:1551)
==23311==by 0x9906A18: merge_changes (tree.c:1599)
==23311==by 0x9906C06: svn_fs_fs__commit_txn (tree.c:1696)
==23311==by 0x6C8C6D9: svn_fs_commit_txn (fs-loader.c:646)
==23311==by 0x6A5B12C: svn_repos_fs_commit_txn (fs-wrap.c:59)
==23311== Address 0xb2ee1dc is 92 bytes inside a block of size 4,096 alloc'd
==23311==at 0x4C244E8: malloc (vg_replace_malloc.c:236)
==23311==by 0x5E806D0: pool_alloc (apr_pools.c:1463)
==23311==by 0x5E7CDFB: apr_file_open (open.c:211)
==23311==by 0x59F5194: file_open (io.c:280)
==23311==by 0x59FABF6: svn_io_file_open (io.c:3049)
==23311==by 0x98E8FC4: svn_fs_fs__put_node_revision (fs_fs.c:2308)
==23311==by 0x98E1039: svn_fs_fs__dag_increment_mergeinfo_count (dag.c:575)
==23311==by 0x9906847: merge (tree.c:1551)
==23311==by 0x9906A18: merge_changes (tree.c:1599)
==23311==by 0x9906C06: svn_fs_fs__commit_txn (tree.c:1696)
==23311==by 0x6C8C6D9: svn_fs_commit_txn (fs-loader.c:646)
==23311==by 0x6A5B12C: svn_repos_fs_commit_txn (fs-wrap.c:59)
The commit fails because the count: is wrong, but if I disable that
check to allow the commit to complete then I see a bogus minfo-cnt such
as:
id: 0.0.r7/322
type: dir
pred: 0.0.r4/180
count: 5
text: 7 198 111 0 242bff40060f22bcf85959dcf552851a
cpath: /
copyroot: 0 /
minfo-cnt: 43
Using the current trunk with the issue 4129 fix applied this no longer
happens: I don't get the valgrind warnings and the minfo-cnt is correct.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Unexpected behavior during mergeinfo elision scenario
I have a mergeinfo elision scenario that is behaving in a manner I do not understand. I have a clean checkout of a branch (to eliminate any mixed revision working copy behavior): $ svn co [URL redacted]/myproject/branches/X $ cd X The difference in the mergeinfo, between subdir and subdir/A, is revision 1489-2779 (inclusive) $ svn pg 'svn:mergeinfo' subdir /myproject/branches/W/subdir:1488-2675 /myproject/branches/Y/subdir:5925-7118 /myproject/trunk/subdir:2780-7532 $ $ svn pg 'svn:mergeinfo' subdir/A /myproject/branches/W/subdir/A:1488-2675 /myproject/branches/Y/subdir/A:5925-7118 /myproject/trunk/subdir/A:1489-7532 The only difference in the merge info is "subdir/A" contains the merge range between 1489 and 2779 (inclusive), where "subdir" does not contain that same merge range. So, based on the information at this url: http://www.collab.net/community/subversion/articles/merge-info.html ...I would expect that merging revisions 1489-2779 (inclusive) into "subdir", would cause the mergeinfo on "subdir/A" to elide. This does not appear to be the case. In fact, the merge changed nothing. svn merge -r 1488:2779 ^/myproject/trunk/subdir subdir --- Recording mergeinfo for merge of r1489 through r2675 into 'subdir': U subdir svn diff [No output] Perhaps this behavior is somehow related to natural history / implicit mergeinfo? In revision 1488 ^/myproject/branches/W was created via a copy from ^/myproject/trunk@1487 In revision 2768 ^/myproject/branches/X was created via a copy from ^/myproject/trunk@1487 In revision 2780 ^/myproject/trunk was replaced via a copy from ^/myproject/branches/W@2675 svn --version svn, version 1.7.3 (r1242825) svnserve --version svnserve, version 1.7.3 (r1242825) Any clarification would be greatly appreciated! Thanks, John
Which is the most used/best Windows Subversion distribution?
When I go to the download page for the Subversion binaries for WindowsOS: http://subversion.apache.org/packages.html Then there are 5 different packages: CollabNet (supported and certified by CollabNet; requires registration) SlikSVN (32- and 64-bit client MSI; maintained by Bert Huijben, SharpSvn project) VisualSVN (client and server; supported and maintained by VisualSVN) WANdisco (32- and 64-bit client and server; supported and certified by WANdisco) Win32Svn (32-bit client, server and bindings, MSI and ZIPs; maintained by David Darj) What are the differences between them? Which one is the "best supported"/most compatible? Which one is the most widely used in WinOS world? Thank you Ben
Re: Which is the most used/best Windows Subversion distribution?
On Fri, Mar 23, 2012 at 10:56 PM, Ben Stover wrote: > When I go to the download page for the Subversion binaries for WindowsOS: > > http://subversion.apache.org/packages.html > > Then there are 5 different packages: > > CollabNet (supported and certified by CollabNet; requires registration) > SlikSVN (32- and 64-bit client MSI; maintained by Bert Huijben, SharpSvn > project) > VisualSVN (client and server; supported and maintained by VisualSVN) > WANdisco (32- and 64-bit client and server; supported and certified by > WANdisco) > Win32Svn (32-bit client, server and bindings, MSI and ZIPs; maintained by > David Darj) > > > What are the differences between them? > > It Depends(tm). Some are supposed to be IDE's, such as SlikSVN and VisualSVN. But the most commonly used, and probably best, Subversion for Windows is TortoiseSVN. The very good GUI and the well integrated behavior with Windows interfaces make it very easy to use, Another popular Windows command line tool suite is in CygWin, which is the compiltion envionment for many Windows tools. > Which one is the "best supported"/most compatible? > > Which one is the most widely used in WinOS world? > In my obvservatoin, TortoiseSVN, which is GUI based. > Thank you > Ben > > >
