Re: Check-out fails with LANG=C

[Branko Čibej]

On 31.07.2013 15:49, Vincent Lefevre wrote:
> No, even "LC_ALL=en_US.UTF-8 cp" doesn't have any effect.

What do you mean by "doesn't have any effect"?

> FYI, some other VCS such as git or Mercurial don't have such problems
> of broken working copies if the locale changes, at least under Unix,
> probably because they regard a filename just as a sequence of bytes.
> The byte-sequence interpretation under Unix is a problem introduced by
> Subversion, currently out of the scope of the POSIX API.

Those version control systems have a massive problem with
interoperability across platforms where file name encodings differ and
file names are anything but the ASCII subset. Subversion has mostly
avoided that problem for the last 10+ years.

If you want to propose a different way of solving it, please stop
telling me that we should change everything about file name translation
and instead post to the dev@ list and propose a solution that will work,
backward-compatibly, without breaking current working copies. And note
that "store the encoding in the working copy metadata" is not such a
solution (see above under "works" and "backward-compatibly").

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

svnmucc assertion failure

[Alexey Neyman]

Hi,

I've hit the following assertion in svnmucc:

svnmucc: subversion/libsvn_subr/dirent_uri.c:1373: 
svn_uri_get_longest_ancestor: Assertion `svn_uri_is_canonical(uri1, ((void 
*)0))' failed.
Aborted (core dumped)

The assertion was triggered when svnmucc was supplied with a script file that 
had inconsistent URL specifications (it was cut-and-pasted from two different 
scripts, one of which referred to SVN server by IP and the other by its domain 
name). It can be easily reproduced with the following script, for example (no 
repository setup is needed, as this assertion is triggered even before svnmucc 
contacts the repository):

mkdir
svn://localhost/svn/branches/try
cp
1234
svn://127.0.0.1/svn/trunk/foo
svn://localhost/svn/branches/try/foo

I am not sure if it is a valid use case, but at the very least, the error 
message should probably be me a bit more user-friendly than an assertion. 
Patch erring out gracefully attached.

Regards,
Alexey.
Index: subversion/svnmucc/svnmucc.c
===
--- subversion/svnmucc/svnmucc.c	(revision 1508998)
+++ subversion/svnmucc/svnmucc.c	(working copy)
@@ -1433,7 +1433,14 @@
   if (! anchor)
 anchor = url;
   else
-anchor = svn_uri_get_longest_ancestor(anchor, url, pool);
+{
+  anchor = svn_uri_get_longest_ancestor(anchor, url, pool);
+  if (!anchor[0])
+handle_error(svn_error_createf(SVN_ERR_INCORRECT_PARAMS, NULL,
+   "URLs in the action list do not "
+   "share a common ancestor\n"),
+ pool);
+}
 
   if ((++i == action_args->nelts) && (j + 1 < num_url_args))
 insufficient(pool);

WG: [Subclipse-users] Server 1.6 checkout problem

[Wolfgang Pinitsch]

@mark thx for the hint with the other list!

 

FYI here to this users@subversion.apache.org list  ... i used the
Eclipse standard svn checkout UI (new svn project wizard) to select the
branch, so i would assume the URL is not the real problem ;-)

 

Server: Subversion 1.6.11 (r934486)

 

Here are some strange logentries from the apache error.log:

 

[Wed Jul 31 09:39:51 2013] [error] [client x.x.x.x] Could not fetch
resource information.  [301, #0] [Wed Jul 31 09:39:51 2013] [error]
[client x.x.x.x] (17)File exists: Requests for a collection must have a
trailing slash on the URI.  [301, #0] [Wed Jul 31 09:52:38 2013] [error]
[client x.x.x.x] request failed: error reading the headers [Wed Jul 31
09:52:49 2013] [error] [client x.x.x.x] Invalid URI in request
\xff\xfb\x1f\xff\xfb
\xff\xfb\x18\xff\xfb'\xff\xfd\x01\xff\xfb\x03\xff\xfd\x03 GET / HTTP/1.0

 

... any suggestions?

 

Regards,

Wolfgang

 

 

Von: Mark Phippard [mailto:markp...@gmail.com] 
Gesendet: Mittwoch, 31. Juli 2013 15:51
An: us...@subclipse.tigris.org
Betreff: Re: [Subclipse-users] Server 1.6 checkout problem

 

On Wed, Jul 31, 2013 at 4:08 AM, Wolfgang Pinitsch
 wrote:

 

We are still running an older svn server (1.6)  and i was trying
to do a simple fresh checkout of my branch. All i get is this message: 

 

Console output:

 

checkout http://svn/xxx/test -r HEAD --depth=infinity --force

APR does not understand this error code

svn: Unable to connect to a repository at URL
'http://svn/xxx/test'

svn: Error running context: The server sent an improper HTTP
response

 

 

I would first triple check that you are entering the right URL.  Other
than that, I would guess this is a bug in Subversion 1.8.  It uses a new
library for HTTP communication and there have been a lot of bugs
surfacing due to less common configurations such as proxy servers that
advertise support for HTTP/1.1 but then do not fully support it.  The
old library apparently new how to deal with those issues better.  Many
of the known bugs were fixed in SVN 1.8.1, but I have not seen this on
the mailing list.

 

I can say that it is not a general problem with an older server.
Subclipse is hosted on a SVN 1.6 server and we are able to checkout and
use it OK.

 

It would be great to have you gather more information that could be
reported on users@subversion.apache.org so that they could fix the
problem.  Failing that, I would say to just uinstall this Subclipse
version and install the latest Subclipse 1.8.x version instead of 1.10.x
and you should be all set.

 

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/ 

Re: Check-out fails with LANG=C

[Vincent Lefevre]

On 2013-07-24 05:57:41 +0200, Branko Čibej wrote:
> On 19.07.2013 15:22, Vincent Lefevre wrote:
> > LANG=C.UTF-8 is completely non-portable for scripts. For instance:
> >
> > xvii:~> LANG=C.UTF-8 cp
> > cp: opérande de fichier manquant
> > Saisissez « cp --help » pour plus d'informations.
> >
> > xvii:~> LANG=C cp
> > cp: missing file operand
> > Try 'cp --help' for more information.
> >
> > A script that needs to work in some well-defined way, in particular
> > with English messages (if they need to be parsed), must use the C
> > (or POSIX) locale. With most tools, this is fine as they don't need
> > to know how filenames are encoded.
> 
> Frankly I'm not interested in portable scripts.

You may not be interested, but there are users who are.

> All you're showing above is that on your particular system, setting
> LANG=C.UTF-8 doesn't do anything. So perhaps you'll have to use
> LC_CTYPE=UTF-8, LANG=en_US.UTF-8,

No, even "LC_ALL=en_US.UTF-8 cp" doesn't have any effect.

> or whatever happens to work on your particular flavour of Unix-like
> OS.

What is needed: LANG=C or LC_ALL=C, but that's not UTF-8, hence
problems with Subversion.

A workaround that can work: LANG=C, LC_CTYPE=C.UTF-8, and unset
all the other LC_* environment variables. And make sure that if
the program has output to a terminal, then either the charmap
was UTF-8 at the beginning or redirect all output so that the
terminal won't get UTF-8 (otherwise some output bytes can trash
the terminal). It's still a problem for interactive use of the
"svn" command from a shell (unless wrappers are used to convert
stdout and stderr... with known synchronization problems due to
different buffering behavior though svn may not be affected).

> All this is beside the point. The point is that it it not up to
> Subversion to invent a new way of dealing with file-name encodings.

Well, Subversion did invent one. Most programs don't have to deal with
filename encodings; in particular, using LC_ALL=C isn't much a problem
to deal with filenames with top-bit-set bytes. For instance, doing a
"mv dir1/* dir2" will work in any locale, even if dir1 has filenames
with top-bit-set bytes. Then you have GNOME applications that assume
that every filename is encoded in UTF-8, whatever the default locale
for the user. Then you have Subversion that assumes that filenames are
encoded in the current locale, breaking simple things like "svn up" if
the user has changed the locale.

> We use setlocale(LC_ALL, ""), this is the API that POSIX gives us
> and there is no other that I'm aware of.

But POSIX does not say that filenames should be considered to be
encoded with the corresponding charmap on the disk. For POSIX, a
filename remains a sequence of bytes. Any interpretation of these
bytes is unspecified.

> And we're certainly not going to break every working copy in
> existence by changing the way we transcode file names on Unix
> (except Mac OS, which is always UTF-8 anyway).

I'm certainly not asking to break every working copy in existence.
I'm just asking for an *option* to allow Subversion to remember the
encoding that was used at the creation of the working copy, and use
this information in subsequent operations. Or something similar.

Note that:

* Users who always use the same locale (at least the same charmap)
  wouldn't be affected at all, whether they use such an option or
  not.

* For users affected by locale change (either explicitly by the user
  or in more hidden ways, e.g. because the user has logged in from a
  different machine, whose terminal uses a different charmap):

  - With the current behavior of Subversion (or if the user doesn't
use the proposed option), the working copy is regarded as broken
by Subversion if some filenames have non-ASCII characters.
A write operation such as "svn up" will break it even more.

  - With the proposed option, the working copy wouldn't break, e.g.
"svn st" and "svn up" would be fine.

FYI, some other VCS such as git or Mercurial don't have such problems
of broken working copies if the locale changes, at least under Unix,
probably because they regard a filename just as a sequence of bytes.
The byte-sequence interpretation under Unix is a problem introduced
by Subversion, currently out of the scope of the POSIX API.

> I'll also point out that if you /need/ consistent, parseable output in
> scripts, the command-line client already provides an --xml flag.

Not all svn commands have a --xml flag. For instance:

$ svn up --xml
Subcommand 'update' doesn't accept option '--xml'
Type 'svn help update' for usage.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

RE: Python error in 1.8.1 test suite - authz_tests.py

[BIRD Neil - UNSECURED]

From: Philip Martin [mailto:philip.mar...@wandisco.com], Sent: Tuesday, July 
30, 2013 4:19 PM
> The value that matters is HTTP_PROXY, i.e. uppercase.  The code
> expects
> a value like 'host:port' and breaks on 'http://host:port'.
> However you
> don't need to set a proxy to run the tests, so unset HTTP_PROXY.

  Ah, thanks for that.

  Now, I wonder where I've set that as well as the lower-case version ...

-- 
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

Re: Proxy error on SVN 1.8.1

[Guillaume Lasnier]

Hi Lieven,
Please find attached the tcpdump that dumps traffic between my laptop and
the proxy. The only information I could get about the proxy is that it's
an ISA server.

Regards

--
Guillaume Lasnier 



On 7/29/13 7:01 PM, "Lieven Govaerts"  wrote:

>Hi,
>
>On Mon, Jul 29, 2013 at 6:28 PM, Guillaume Lasnier
> wrote:
>> Hi all,
>> When issuing the following command, I get the following error:
>>
>> $ svn -v log
>> svn: E120107: Unable to connect to a repository at URL
>> 'https://svncvs.myhost.mydomain/repos/myrepo/trunk/hybris/bin/platform'
>> svn: E120107: Error running context: The proxy server returned an error
>> while setting up the SSL tunnel.
>
>That error indicates the proxy returned an error to the CONNECT
>request that svn uses to initiate the ssl tunnel.
>What proxy server do you use? KeepAlive off? Specific authentication?
>
>I think the easiest way to find out what's going on is to trace the
>network traffic. Can you make a trace with fiddler or wireshark?
>
>>
>> I am using subversion 1.8.1 on Mac OS X installed with homebrew.
>> I have configured the proxy the following way in ~/.subversion/servers :
>>
>> [groups]
>> # group1 = *.collab.net
>> # othergroup = repository.blarggitywhoomph.com
>> # thirdgroup = *.example.com
>> mygroup = *.myhost.mydomain
>>
>> # Information for my group:
>> [mygroup]
>> http-proxy-host = 192.168.xxx.xxx
>> http-proxy-port = 1234
>> http-proxy-username = john
>> http-proxy-password = doe
>>
>>
>> This configuration used to work with subversion 1.7.
>>
>Configuration looks ok, and if it has worked before then we should be
>able to make it work in 1.8.1 too.
>
>Lieven
>
>
>> Do have any idea?
>>
>> --
>>
>> Guillaume Lasnier
>>
>>
>>
>>



tcpdump-filter.pcap
Description: tcpdump-filter.pcap