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
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-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 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 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 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
[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
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 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
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: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: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-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 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
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:
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
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
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
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 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 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 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 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: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 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 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 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 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 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 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 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 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 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 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, 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 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, 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
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 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
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 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: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, 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
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
45 matches
Mail list logo
