[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svn_path_canonicalize() broken in 1.1.x on cygwin (was: SVN 1.1.1: Cannot find .subversion folder (CYGWIN) on users@)

From: Roland Schwingel <roland.schwingel_at_onevision.de>
Date: 2004-10-26 11:56:00 CEST


Yesterday I posted the attached observation to the users list...I did
some further investigations.
As of the fact that IMHO this is a bug in the implementation I am
switching to the developers list.

To summarize:
Subversion 1.1.x can not find the users .subversion folder in his/her
homeaccount on cygwin when
the homeaccount resides on an UNC share.

Subversion 1.0.9 is like 1.0.4 not showing the behaviour. Everything is
fine. So I was taking a look
in the code. apr is identical in 1.0.9 and 1.1.1. So it couldn't be the
failing instance here. So I looked further
and found that svn_path_canonicalize() in subversion/libsvn_subr/path.c
is broken in 1.1.x when running
on cygwin and getting an UNC path.

will result in
after svn_path_canonicalize()

The reason for it is that the leading / gots stripped here. There is an
#ifdef for win32
taking care of double leading seperators but not for cygwin.

So replacing the 2 occurencies of
#ifdef WIN32
in svn_path_canonicalize() with
#if defined(WIN32) || defined(CYGWIN)

fixed the problem for me. I attached a patch for this problem basing on
the current 1.1.1 release code

I haven't read the HACKING file so this is just a suggestion how it can
be fixed .Feel free to ignore
it and use another solution for this if you find it better suitable.

I also dared and filed an issue for this (#2108).


--- path.c 2004-10-26 11:16:27.000000000 +0200
+++ path.c.new 2004-10-26 11:16:49.000000000 +0200
@@ -1140,13 +1140,13 @@
       *(dst++) = *(src++);
-#ifdef WIN32
+#if defined(WIN32) || defined(CYGWIN)
       /* On Windows permit two leading separator characters which means an
        * UNC path. However, a double slash in a URI after the scheme is never
        * valid. */
       if (!uri && *src == '/')
         *(dst++) = *(src++);
-#endif /* WIN32 */
+#endif /* WIN32 || CYGWIN */
@@ -1185,12 +1185,12 @@
   *dst = '\0';
-#ifdef WIN32
+#if defined(WIN32) || defined(CYGWIN)
   /* Skip leading double slashes when there are less than 2
    * canon segments. UNC paths *MUST* have two segments. */
   if (canon_segments < 2 && canon[0] == '/' && canon[1] == '/')
     return canon + 1;
-#endif /* WIN32 */
+#endif /* WIN32 || CYGWIN */
   return canon;

attached mail follows:


Till a few hours ago I was happilly running svn 1.0.4 (self compiled) on
cywin (client) and Linux (server).
Now I updated to 1.1.1 and the svn commandline client can no longer find
my homeaccount where the .subversion folder is.

My scenario:
- WinXP pro SP2 (and Win2000 SP4)
- cygwin 1.3.22 (I know there is 1.5.x, but I have to stick with 1.3 for
a while)
  Installed in D:\path\cygwin\
- Linux Subversion 1.1.1 server (i think this does not matter here)
- My home account is on a samba 3 server in the network.
  $HOME and /etc/passwd is set to

When I now do a 'svn up' it first takes some ages then the I am asked
for my password to my svn repos.
When sniffing a bit around it appears that svn looks for the .subversion
folder in

It cannot find anything there... After entering my password manually it
updates my working copy, which
btw resides also in my homeaccount on the samba share.

This is a bit odd and at present prevents me from switching over to 1.1.x.
I just recompiled my 1.0.4 and here I am very fine it works good. So
this smells like a bad bug or a completely stupid Roland....

Any ideas?



PS: If the message appears twice, I just posted it on error from another
account which is not subscribed to the list... Sorry...

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 26 11:56:28 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.