When checking out one of the subsystems from our repository, the
check-out always fails for one of my colleagues with the following
error messages after about 2/3 of the files:
svn: E155009: Failed to run the WC DB work queue associated with
'$HOME/C8-32-C-serf/CCS/db/src', work item 9694 (file-in
On Tue, 09 Jul 2013 12:55:29 +, Michael Pruemm wrote:
...
> The difference is in the setting of the LANG environment variable.
> When set to "en_US.UTF-8", everything works as it should, but with
> LANG=C, the check-out always fails.
svn wants to convert file names in the repository to filenam
On Tue, Jul 9, 2013 at 3:24 PM, Andreas Krey wrote:
> svn wants to convert file names in the repository to filename
> on the local disk by using the locally set LANG. This is a
> rather stupid idea, but that is the way it is.
>
Yes, I know. The whole point is that with 1.7.10 it works, but with
On Tue, Jul 09, 2013 at 03:24:15PM +0200, Andreas Krey wrote:
> On Tue, 09 Jul 2013 12:55:29 +, Michael Pruemm wrote:
> ...
> > The difference is in the setting of the LANG environment variable.
> > When set to "en_US.UTF-8", everything works as it should, but with
> > LANG=C, the check-out alw
On Tue, Jul 9, 2013 at 3:44 PM, Stefan Sperling wrote:
> Michael, does this only happen with ra_serf? Can you please test
> with svn://, or svn+ssh://, or file:// access?
>
Here are the results with 32-bit 1.8.0 using svn+ssh:
LANG=$l1 time svn co svn+ssh://... -r244060 C8-32-$l1-svnssh
17.71us
On 09.07.2013 15:24, Andreas Krey wrote:
> On Tue, 09 Jul 2013 12:55:29 +, Michael Pruemm wrote:
> ...
>> The difference is in the setting of the LANG environment variable.
>> When set to "en_US.UTF-8", everything works as it should, but with
>> LANG=C, the check-out always fails.
> svn wants t
For file:// access I had to mount the repository via NFS, and access is
much slower.
LANG=$l1 time svn co file:///... -r244060 C8-32-$l1-file
C8-32-en_US.UTF-8-file
32.32user 21.51system 5:36.36elapsed 16%CPU (0avgtext+0avgdata
519408maxresident)k
1101632inputs+1799224outputs (4major+36982minor)p
On Tue, 09 Jul 2013 16:26:40 +, Branko ??ibej wrote:
...
> Since we're on the topic, would you care to explain why translating
> files to the native encoding is "a rather stupid idea"?
Because LANG isn't "the native encoding", but, for the file system
the "naive encoding".
What encoding is us
On Tue, Jul 09, 2013 at 04:34:02PM +0200, Michael Pruemm wrote:
> For file:// access I had to mount the repository via NFS, and access is
> much slower.
>
>
> LANG=$l1 time svn co file:///... -r244060 C8-32-$l1-file
> C8-32-en_US.UTF-8-file
> 32.32user 21.51system 5:36.36elapsed 16%CPU (0avgtext+
On Tue, Jul 9, 2013 at 7:11 PM, Stefan Sperling wrote:
> Can you please file a new issue pointing to this thread?
Done. Issue 4391.
- Michael
On 09.07.2013 17:01, Andreas Krey wrote:
> On Tue, 09 Jul 2013 16:26:40 +, Branko ??ibej wrote:
> ...
>> Since we're on the topic, would you care to explain why translating
>> files to the native encoding is "a rather stupid idea"?
> Because LANG isn't "the native encoding", but, for the file s
On Tue, 09 Jul 2013 20:21:33 +, Branko ??ibej wrote:
...
> I posit that if the "native encoding" is supposed to be UTF-8, then it
> is an error to use LANG=C at all. Instead, one should use LANG=C.UTF-8.
No, using LANG etc. for the interface between svn and the disk mixes up
the setup for the
On Tue, Jul 09, 2013 at 09:22:39PM +0200, Andreas Krey wrote:
> On Tue, 09 Jul 2013 20:21:33 +, Branko ??ibej wrote:
> ...
> > I posit that if the "native encoding" is supposed to be UTF-8, then it
> > is an error to use LANG=C at all. Instead, one should use LANG=C.UTF-8.
>
> No, using LANG e
On Tue, 09 Jul 2013 21:43:50 +, Stefan Sperling wrote:
...
> I think using UTF-8 by default would be a good choice today. But it
> certainly wasn't when the Subversion project was started years ago.
> And we cannot change the existing default behaviour now. That would
> create compatibility nig
On 09.07.2013 21:22, Andreas Krey wrote:
>> So indeed, this state of affairs puts the burden of setting up their
>> locale correctly on users, but that's simply the way Unix works.
> No, it ain't. It's almost like the mailer looks into LANG to see
> how to interpret the incoming mail, instead of us
On 09.07.2013 21:43, Stefan Sperling wrote:
> On Tue, Jul 09, 2013 at 09:22:39PM +0200, Andreas Krey wrote:
>> On Tue, 09 Jul 2013 20:21:33 +, Branko ??ibej wrote:
>> ...
>>> I posit that if the "native encoding" is supposed to be UTF-8, then it
>>> is an error to use LANG=C at all. Instead, on
On 09.07.2013 22:02, Andreas Krey wrote:
> On Tue, 09 Jul 2013 21:43:50 +, Stefan Sperling wrote:
> ...
>
>> I don't really understand what kind of answers you are hoping to get.
> 'You might have a point there'?
Why should anyone concede your point when all cited documentation says
otherwise?
On Tue, Jul 09, 2013 at 10:02:00PM +0200, Andreas Krey wrote:
> On Tue, 09 Jul 2013 21:43:50 +, Stefan Sperling wrote:
> ...
> > I think using UTF-8 by default would be a good choice today. But it
> > certainly wasn't when the Subversion project was started years ago.
> > And we cannot change t
On Tue, Jul 09, 2013 at 10:27:29PM +0200, Branko Čibej wrote:
> In any case, as I said before, Unix filesystems do not standardize a
> file name encoding. One has to assume that the locale is set correctly,
> or be incompatible with all other applications running on the system.
> This is not a new
On Jul 9, 2013, at 15:47, Stefan Sperling wrote:
> On Tue, Jul 09, 2013 at 10:02:00PM +0200, Andreas Krey wrote:
>> On Tue, 09 Jul 2013 21:43:50 +, Stefan Sperling wrote:
>> ...
>>> I think using UTF-8 by default would be a good choice today. But it
>>> certainly wasn't when the Subversion proj
On 09.07.2013 22:47, Stefan Sperling wrote:
> On Tue, Jul 09, 2013 at 10:02:00PM +0200, Andreas Krey wrote:
>> On Tue, 09 Jul 2013 21:43:50 +, Stefan Sperling wrote:
>> ...
>>> I think using UTF-8 by default would be a good choice today. But it
>>> certainly wasn't when the Subversion project w
On 09.07.2013 22:53, Ryan Schmidt wrote:
> On Jul 9, 2013, at 15:47, Stefan Sperling wrote:
>> On Tue, Jul 09, 2013 at 10:02:00PM +0200, Andreas Krey wrote:
>>> On Tue, 09 Jul 2013 21:43:50 +, Stefan Sperling wrote:
>>> ...
I think using UTF-8 by default would be a good choice today. But i
On 09.07.2013 22:50, Stefan Sperling wrote:
> On Tue, Jul 09, 2013 at 10:27:29PM +0200, Branko Čibej wrote:
>> In any case, as I said before, Unix filesystems do not standardize a
>> file name encoding. One has to assume that the locale is set correctly,
>> or be incompatible with all other applica
On Tue, Jul 09, 2013 at 10:53:41PM +0200, Branko Čibej wrote:
> Sorry, I have to ask, useful *how* exactly? There is already a perfectly
> valid workaround for the case that Andreas is talking about, namely,
> relieving scripts authors from the complexity of parsing multi-lingual
> responses. It's
On Jul 9, 2013, at 15:59, Branko Čibej wrote:
> On 09.07.2013 22:53, Ryan Schmidt wrote:
>> What happens if you copy a working copy between filesystems that have
>> different encodings?
>>
>> What happens if you copy a working copy from OS X or Windows (whose default
>> filesystems already know
On Tue, Jul 09, 2013 at 04:10:09PM -0500, Ryan Schmidt wrote:
> I just meant that if you record inside the working copy the encoding of the
> filesystem you're checking out on, that might not be the same as the encoding
> of the filesystem you might later copy that working copy to.
In case the c
On Tue, Jul 9, 2013 at 4:53 PM, Ryan Schmidt
wrote:
> On Jul 9, 2013, at 15:47, Stefan Sperling wrote:
>> On Tue, Jul 09, 2013 at 10:02:00PM +0200, Andreas Krey wrote:
>>> On Tue, 09 Jul 2013 21:43:50 +, Stefan Sperling wrote:
>>> ...
I think using UTF-8 by default would be a good choice
Michael Pruemm wrote on Tue, Jul 09, 2013 at 16:00:38 +0200:
> On Tue, Jul 9, 2013 at 3:44 PM, Stefan Sperling wrote:
>
> > Michael, does this only happen with ra_serf? Can you please test
> > with svn://, or svn+ssh://, or file:// access?
> >
>
> Here are the results with 32-bit 1.8.0 using svn
Daniel Shahaf wrote on Wed, Jul 17, 2013 at 08:05:41 +0300:
> Michael Pruemm wrote on Tue, Jul 09, 2013 at 16:00:38 +0200:
> > On Tue, Jul 9, 2013 at 3:44 PM, Stefan Sperling wrote:
> >
> > > Michael, does this only happen with ra_serf? Can you please test
> > > with svn://, or svn+ssh://, or fil
Daniel Shahaf wrote on Wed, Jul 17, 2013 at 08:05:41 +0300:
> Michael Pruemm wrote on Tue, Jul 09, 2013 at 16:00:38 +0200:
> > On Tue, Jul 9, 2013 at 3:44 PM, Stefan Sperling wrote:
> >
> > > Michael, does this only happen with ra_serf? Can you please test
> > > with svn://, or svn+ssh://, or fil
Daniel Shahaf daniel.shahaf.name> writes:
>
> Michael Pruemm wrote on Tue, Jul 09, 2013 at 16:00:38 +0200:
> > Note: instead of the error message I got a core dump. That happened before,
> > too. The check-out went about as far as in the other failing cases.
>
> I suspect the core dump is http:
On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> Unlike on Windows and Mac OS (the latter at least with HFS+), the is no
> notion of native filesystem encoding on other Unix-like platforms. The
> best we can do is look at the locale settings, specifically, LC_CTYPE.
No, the best you can do is t
On 2013-07-09 22:50:45 +0200, Stefan Sperling wrote:
> Now, I still wonder why anyone would want to mix and match encodings
> on their filesystems. But this isn't the first time this issue has
> been brought up, so it seems to be important to some of our users.
I don't think that users want to mix
On Fri, Jul 19, 2013 at 03:22:33PM +0200, Vincent Lefevre wrote:
> On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> > Unlike on Windows and Mac OS (the latter at least with HFS+), the is no
> > notion of native filesystem encoding on other Unix-like platforms. The
> > best we can do is look at t
On 2013-07-19 15:33:55 +0200, Stefan Sperling wrote:
> On Fri, Jul 19, 2013 at 03:22:33PM +0200, Vincent Lefevre wrote:
> > On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> > > Unlike on Windows and Mac OS (the latter at least with HFS+), the is no
> > > notion of native filesystem encoding on o
On Fri, Jul 19, 2013 at 03:41:00PM +0200, Vincent Lefevre wrote:
> On 2013-07-19 15:33:55 +0200, Stefan Sperling wrote:
> > On Fri, Jul 19, 2013 at 03:22:33PM +0200, Vincent Lefevre wrote:
> > > On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> > > > Unlike on Windows and Mac OS (the latter at le
On 2013-07-19 15:22:33 +0200, Vincent Lefevre wrote:
> On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> > In a context where, for example, most files were encoded in Big5
> > (http://en.wikipedia.org/wiki/Big5) — not a too far-fetched proposition
> > — it would be slightly insane, to put it mild
Guten Tag Vincent Lefevre,
am Freitag, 19. Juli 2013 um 16:32 schrieben Sie:
> Indeed it was said in the past that USB keys were supported. So, move
> a USB key to a different computer, where the encoding specified by the
> environment is different... and see what happens if you try to do an
> "sv
On 2013-07-19 17:14:02 +0200, Thorsten Schöning wrote:
> And how do other tools besides svn encode file names on this USB stick
> between two different computers with two different OSes? They surely
> don't look in the svn working copy. What does cp on my Ubuntu 12.04
> and the Windows Explorer on
On Fri, Jul 19, 2013 at 04:32:50PM +0200, Vincent Lefevre wrote:
> On 2013-07-19 15:22:33 +0200, Vincent Lefevre wrote:
> > On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> > > In a context where, for example, most files were encoded in Big5
> > > (http://en.wikipedia.org/wiki/Big5) — not a too
On 19.07.2013 15:22, Vincent Lefevre wrote:
> On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
>> Unlike on Windows and Mac OS (the latter at least with HFS+), the is no
>> notion of native filesystem encoding on other Unix-like platforms. The
>> best we can do is look at the locale settings, spec
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.
> >
> > x
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,
> p
On 2013-07-31 23:32:57 +0200, Branko Čibej wrote:
> 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"?
The output is the same, as without the "LC_ALL=en_US.UTF-8": still
in French. Except in
[Cc to the dev@ list]
On 2013-07-19 16:50:49 +0200, Stefan Sperling wrote:
> On Fri, Jul 19, 2013 at 04:32:50PM +0200, Vincent Lefevre wrote:
> > [...]
> >
> > Actually I think that the encoding needs to be stored somewhere in the
> > working copy. Otherwise even if the user never changes the enc
45 matches
Mail list logo
