Re: svn diff -c does not accept HEAD

On 2020-12-09 21:15:08 +0100, Vincent Lefevre wrote: > On 2020-12-08 00:00:16 +, Daniel Shahaf wrote: > > Nathan Hartman wrote on Mon, 07 Dec 2020 20:50 +00:00: > > > When I want to see the diff of the most recent revision I use 'svn log > > > -l 1 --diff'. (Note

Re: svn diff -c does not accept HEAD

On 2020-12-08 00:00:16 +, Daniel Shahaf wrote: > Nathan Hartman wrote on Mon, 07 Dec 2020 20:50 +00:00: > > When I want to see the diff of the most recent revision I use 'svn log > > -l 1 --diff'. (Note, though, that will be from the BASE revision, not > > HEAD.) > > There's also «svn log

Re: svn log says text-mods="true" but there are no diffs

On 2020-12-04 20:41:27 +, Daniel Shahaf wrote: > Vincent Lefevre wrote on Fri, 04 Dec 2020 01:08 +00:00: > > I get the following: > > > > $ svn log --xml -v -r 1984 https://scm.gforge.inria.fr/anonscm/svn/mpfr > > >revision="1984"> &

svn log says text-mods="true" but there are no diffs

I get the following: $ svn log --xml -v -r 1984 https://scm.gforge.inria.fr/anonscm/svn/mpfr vlefevre 2002-07-23T16:22:08.00Z /trunk/mul.c Fixed permissions. I'm wondering why text-mods="true" while svn diff -c 1984 https://scm.gforge.inria.fr/anonscm/svn/mpfr shows no diffs. --

Re: forcing update of keyword expansions in a working copy

On 2020-09-30 22:27:47 -0400, Nathan Hartman wrote: > Searching through the issues database, I came across issue #4585 [1] > which you filed previously and this sounds related to the same issue. This was not this bug. What I did was to change svn:keywords from "Id Date" to "Id" on various files

forcing update of keyword expansions in a working copy

Hi, Is there a way to force the update of keyword expansions to their correct values in a working copy? "svn up" will not change anything if the file hasn't changed, but the file may have obsolete keyword values, probably due to some bug in Subversion. I noticed the issue while checking data

location of .svn and security issues (was: Subversion fails to checkout new working set when $HOME is automounted)

On 2020-01-23 18:40:56 +, Daniel Shahaf wrote: > Vincent Lefevre wrote on Thu, 23 Jan 2020 15:50 +0100: > > On 2020-01-23 12:44:02 +0100, Joerg Wunsch wrote: > > > If the automounter already yields ENOENT for the ../.svn directory > > > probe, everything is not goi

Re: Subversion fails to checkout new working set when $HOME is automounted

On 2020-01-23 12:44:02 +0100, Joerg Wunsch wrote: > If the automounter already yields ENOENT for the ../.svn directory > probe, everything is not going to be a problem. I think the point here > is the automounter (eventually, after "thinking" about it for about 1 > s) offers a successful stat()

Re: "svn diff -c" behavior on file copy from an old revision

On 2019-11-21 15:09:05 +0100, Vincent Lefevre wrote: > Exactly, but the reason is not that file1 was unchanged in r2. > It is because that file1@1 is the latest ancestor or file2@3. ^^ to be read: "the latest ancestor of file

Re: "svn diff -c" behavior on file copy from an old revision

On 2019-11-20 15:21:22 +0100, Johan Corveleyn wrote: > Vincent Lefevre also wrote: > >> Note: "svn cat -r... file2" or "svn cat -r... file2@3" also shows a > >> similar behavior: > >> -r1: one gets file1@1 > >> -r2: "Unable to fin

"svn diff -c" behavior on file copy from an old revision

I have the following issue with svn 1.10.6: Assume that I committed "file1" at revision 1, did some unrelated change at revision 2, and for revision 3, copied "file1@1" to "file2" with "svn copy"[*] and did some changes in file2 before the commit. [*] The revision older than the latest one is

[SOLVED] freezing "svn up"

On 2019-08-01 04:41:10 +0200, Vincent Lefevre wrote: > On some Debian/unstable machine with some Subversion working copy, > "svn up" is sometimes freezing. A "strace -p ..." shows that both > the client and the server are waiting on a "read": "read(6,

Re: freezing "svn up"

On 2019-08-01 04:41:10 +0200, Vincent Lefevre wrote: > I haven't noticed any network issue: interactive ssh works fine. > Checking out a new working copy from the same machine was fine > too. But later, a "svn up" on this working copy was freezing > too... well, it too

freezing "svn up"

On some Debian/unstable machine with some Subversion working copy, "svn up" is sometimes freezing. A "strace -p ..." shows that both the client and the server are waiting on a "read": "read(6," for the client, "read(0," for the server. On the client, after almost half an hour, I eventually got

Re: svn and svnserve hanging

On 2019-04-11 04:22:29 +0200, Branko Čibej wrote: > I think that svnserve would only use that function to find the current > user's home directory, to locate the config files. And that seems wrong > because svnserve has no business looking at the client's config area ... I think that it would be

Re: svn and svnserve hanging

On 2019-04-10 04:06:08 +0200, Branko Čibej wrote: > On 10.04.2019 03:29, Vincent Lefevre wrote: > > On 2019-04-09 20:09:26 +0200, Branko Čibej wrote: > >> The only problem with that idea is that svnseve doesn't use unscd at > >> all, or any kind of LDAP access

Re: svn and svnserve hanging

On 2019-04-09 20:09:26 +0200, Branko Čibej wrote: > The only problem with that idea is that svnseve doesn't use unscd at > all, or any kind of LDAP access. Are you so sure about that? A "strace svnserve -t"[*] shows it reads the /etc/nsswitch.conf file. With "ltrace", I can see that

Re: svn and svnserve hanging

I got interesting information from the sysadmin of the server: what the logs show is that a cron job reloads the unscd daemon every 10 minutes, a multiple of 10. So, the hanging svnserve was started at about the same time as the reload of the unscd daemon. This was also the case when I had the

Re: svn and svnserve hanging

On 2019-04-08 18:38:46 +0200, Stefan Sperling wrote: > On Mon, Apr 08, 2019 at 05:05:47PM +0200, Vincent Lefevre wrote: > > Well, I forgot, there's at least an issue with svnserve. I got that > > in the past, and could reproduce it: once I kill the svn client > > with Ct

Re: svn and svnserve hanging

On 2019-04-08 16:38:37 +0200, Stefan Sperling wrote: > Since you have a way to reproduce the problem, even if unreliably, > you're in a position to help. But it could take weeks... > If you don't try, we'll have to wait until someone else figures out where > the hang occurs or provides a clear

Re: svn and svnserve hanging

On 2019-04-08 15:26:15 +0200, Stefan Sperling wrote: > On Mon, Apr 08, 2019 at 02:38:15PM +0200, Vincent Lefevre wrote: > > On 2019-04-08 13:57:32 +0200, Stefan Sperling wrote: > > > There is insufficient information in your report for anyone to act upon. > > > Most

Re: svn and svnserve hanging

On 2019-04-08 13:57:32 +0200, Stefan Sperling wrote: > There is insufficient information in your report for anyone to act upon. > Most importantly, it is unclear which component in the chain is causing > the problem. Is it SVN? Is it SSH? Is it TCP? > Please try to find answers to these questions.

svn and svnserve hanging

I've run a "svn diff" with the -c option, and it is hanging. The corresponding "svnserve -t" on the server is hanging too. After one hour, on the client side, the svn command is still running, together with vinc17 19550 19549 0 12:40 pts/11 00:00:00 zsh /home/vinc17/scripts/ssh gforge

Re: Why does svn up give me a different file than in the repo

On 2019-03-07 17:50:26 +0100, Branko Čibej wrote: > On 07.03.2019 17:36, Vincent Lefevre wrote: > > On 2019-03-07 05:26:48 -0600, Ryan Schmidt wrote: > >> I had this problem once when I ran a recursive sed command over my > >> working copy, not considering that i

Re: Why does svn up give me a different file than in the repo

On 2019-03-07 05:26:48 -0600, Ryan Schmidt wrote: > I had this problem once when I ran a recursive sed command over my > working copy, not considering that it would modify the contents of > the .svn directory too. Would it be a good idea to protect the .svn directory by default? I mean that

Re: SVN keyword replacement

On 2019-02-19 20:37:01 +, Scott Bloom wrote: > Thanks.. That is exactly what Im looking for! Even if this is implemented, there's an issue with all these keywords with path/URL information in them: the expanded path is the one of the revision that last changed the file, not the current one!

Re: problem with viewvc

On 2017-12-27 17:46:17 -0600, Greg Stein wrote: > Hi Vincent, Daniel, > > The problem is that the "modified" link for branches/1.9.x/ produces a page > with a log of ALL the modifications EVER made in that branch. You're > talking about thousands of log entries from the past couple/three years. >

problem with viewvc

Hi, On http://svn.apache.org/viewvc?view=revision=1814248 when I click on the first "modified", I get either Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /viewvc/subversion/branches/1.9.x/. Reason: Error

Re: Error E160016 "... is not a directory in filesystem ..."

Also, this is not consistent, unless future commits have an influence on the following command: joooj:~> svn ls -r99809 file:///srv/d_joooj/home/svn/root/perso/tcl/fidelite@99808 svn: E160016: Failure opening '/perso/tcl/fidelite' svn: E160016: '/perso/tcl' is not a directory in filesystem

Re: Error E160016 "... is not a directory in filesystem ..."

On 2017-11-01 14:42:32 +, Daniel Shahaf wrote: > Vincent Lefevre wrote on Wed, 01 Nov 2017 01:06 +0100: > > Additional information: > > > > svn log -rHEAD:1 svn+ssh://mysvn/perso/tcl/fidelite@103183 > > > > works, but > > > > svn log -rHEA

Re: Error E160016 "... is not a directory in filesystem ..."

On 2017-11-01 09:38:43 +0100, Johan Corveleyn wrote: > Most likely, /perso/tcl@103182 is not the same node as > /perso/tcl@103183 and /perso/tcl@103181. I suppose you should be able > to see this in the history, with an 'svn log -v' of the root > directory: 103182 should show an 'R' for

Re: Error E160016 "... is not a directory in filesystem ..."

On 2017-11-01 01:06:40 +0100, Vincent Lefevre wrote: > Additional information: > > svn log -rHEAD:1 svn+ssh://mysvn/perso/tcl/fidelite@103183 > > works, but > > svn log -rHEAD:1 svn+ssh://mysvn/perso/tcl/fidelite@103182 > > yields the error. > > r103183

Re: Error E160016 "... is not a directory in filesystem ..."

Additional information: svn log -rHEAD:1 svn+ssh://mysvn/perso/tcl/fidelite@103183 works, but svn log -rHEAD:1 svn+ssh://mysvn/perso/tcl/fidelite@103182 yields the error. r103183 is just a change of the contents of this file (nothing else). -- Vincent Lefèvre - Web:

Re: Error E160016 "... is not a directory in filesystem ..."

On 2017-11-01 00:46:30 +0100, Vincent Lefevre wrote: > I got the following error several times with "svn log" on a file: > > svn: E160016: Failure opening '/perso/tcl/fidelite' > svn: E160016: '/perso/tcl' is not a directory in filesystem > '99759db8-4ec0-0310-8b

Error E160016 "... is not a directory in filesystem ..."

I got the following error several times with "svn log" on a file: svn: E160016: Failure opening '/perso/tcl/fidelite' svn: E160016: '/perso/tcl' is not a directory in filesystem '99759db8-4ec0-0310-8bf9-df86780d22d8' Why? A "svn up" (which actually updated nothing) solved the issue. --

Re: differences in dump/load/dump cycle

On 2016-08-03 16:10:16 +0200, Stefan Hett wrote: > On 8/3/2016 3:40 PM, Nico Kadel-Garcia wrote: > > [export/import instead of dump/load] [...] > In your export/import approach you would do: > export -> import -> export -> compare old vs. new export > And like with the dump/load/dump approach

Re: differences in dump/load/dump cycle

On 2016-08-03 09:40:59 -0400, Nico Kadel-Garcia wrote: > I don't insist on it: it's not always the correct answer. But it's not > the only time dump/load has suffered from bugs, and I'm sure it won't > be the last. Yes, there have been several issues in the past, but people care about these

Re: svnserve takes too much memory for "svn blame"

On 2016-07-28 14:06:10 +0200, Vincent Lefevre wrote: > On 2016-07-27 11:12:47 +0200, Stefan Hett wrote: > > Hi Vincent, > > On 7/27/2016 2:36 AM, Vincent Lefevre wrote: > > > When I do "svn blame" on some file (36972 lines), svnserve takes > > > more t

Re: svnserve takes too much memory for "svn blame"

On 2016-07-27 17:36:14 +0200, Bert Huijben wrote: > 'svn blame' downloads all versions of the file (via binary diffs between the > revisions that contain actual changes), so the number of lines in the file > is not a number that really relates to what the server has to do. > > The number of

Re: svnserve takes too much memory for "svn blame"

On 2016-07-27 11:12:47 +0200, Stefan Hett wrote: > Hi Vincent, > On 7/27/2016 2:36 AM, Vincent Lefevre wrote: > > When I do "svn blame" on some file (36972 lines), svnserve takes > > more than 800 MB on the server (and is killed due to lack of > > memory). So, it

svnserve takes too much memory for "svn blame"

When I do "svn blame" on some file (36972 lines), svnserve takes more than 800 MB on the server (and is killed due to lack of memory). So, it seems that svnserve is inefficient in terms of memory usage (that's at least 22 KB per line!). svnserve, version 1.8.8 (r1568071) compiled Aug 20 2015,

Re: Problem with svnsync when the auth directory has been removed

On 2015-08-20 16:29:40 +0200, Vincent Lefevre wrote: When the .config/auth directory has been removed (or has never I meant .subversion/auth directory. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog

Problem with svnsync when the auth directory has been removed

When the .config/auth directory has been removed (or has never existed, e.g. when the mirror repository is accessed from a different machine), I get an error: $ svnsync sync file://$PWD/svn-mpfr svnsync: E165001: Revprop change blocked by pre-revprop-change hook (exit code 1) with output: Only

Re: ssh+svn vs. bash security bug?

On 2014-09-27 00:45:19 +0100, Philip Martin wrote: Vincent Lefevre vincent-...@vinc17.net writes: How can this be possible? Do you mean that OpenSSH starts the command with bash instead of some exec* function or /bin/sh (which is dash on my machines)? OpenSSH uses the login shell

Re: ssh+svn vs. bash security bug?

On 2014-09-24 19:28:51 +0300, Stefan Sperling wrote: From what I understand after reading about the problem briefly: In an svn+ssh setup svn clients run 'svnserve -t' by default. But there is no reason this could not be changed to '/bin/bash' by an attacker. Note that forcing a command in

corrupt data with svn 1.7.14?

I've reported the following bug in the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734163 I first thought it could be due to some problem with the binNMU, but the problem still occurs after downgrading to the original 1.7.14. However I no longer get random behavior, just

Re: corrupt data with svn 1.7.14?

On 2014-01-04 14:46:54 +0100, Vincent Lefevre wrote: I've reported the following bug in the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734163 I first thought it could be due to some problem with the binNMU, but the problem still occurs after downgrading to the original

Re: size of .svn/pristine directory (svn 1.7.x)

On 2013-12-10 12:12:06 +0100, Stefan Sperling wrote: On Tue, Dec 10, 2013 at 01:28:52AM +0100, Vincent Lefevre wrote: First, svn help cleanup currently says: cleanup: Recursively clean up the working copy, removing locks, resuming unfinished operations, etc. I suggest to change

size of .svn/pristine directory (svn 1.7.x)

I noticed that the size of the .svn/pristine directory can get huge over time (several times the expected size). A svn cleanup solves the problem, but 1. this isn't documented (I'm wondering how many users know that); 2. this isn't automatic. About (2), svn could warn the user when a cleanup

Re: size of .svn/pristine directory (svn 1.7.x)

On 2013-12-09 19:55:54 +0200, Daniel Shahaf wrote: Vincent Lefevre wrote on Mon, Dec 09, 2013 at 17:30:21 +0100: I noticed that the size of the .svn/pristine directory can get huge over time (several times the expected size). A svn cleanup solves the problem, but 1. this isn't documented

Re: size of .svn/pristine directory (svn 1.7.x)

On 2013-12-09 17:37:28 +0100, Stefan Sperling wrote: On Mon, Dec 09, 2013 at 05:30:21PM +0100, Vincent Lefevre wrote: I noticed that the size of the .svn/pristine directory can get huge over time (several times the expected size). A svn cleanup solves the problem, but 1. this isn't

Re: size of .svn/pristine directory (svn 1.7.x)

On 2013-12-10 01:00:32 +0400, Ivan Zhakov wrote: On 9 December 2013 21:55, Daniel Shahaf d...@daniel.shahaf.name wrote: Vincent Lefevre wrote on Mon, Dec 09, 2013 at 17:30:21 +0100: I noticed that the size of the .svn/pristine directory can get huge over time (several times the expected

Re: Check-out fails with LANG=C

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 POSIX

Re: Check-out fails with LANG=C

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

Re: Check-out fails with LANG=C

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 to

Re: Check-out fails with LANG=C

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

Re: Check-out fails with LANG=C

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 other

Re: Check-out fails with LANG=C

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 mildly

Filename encoding in working copy (was: Check-out fails with LANG=C)

[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 encoding

Re: Check-out fails with LANG=C

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 my

Paths, base revision and symlinks

The svn behavior has changed with Subversion 1.7 (or at least 1.7.5) concernant the interpretation of paths. If might be seen as a fix to follow the description of peg revisions, and in particular the notion of default peg revision, which is BASE. But this is still poorly specified. For instance,

random order due to APR hash change (was: random sort of svn status and svn diff)

On 2012-03-21 00:51:53 +, Philip Martin wrote: Sérgio Basto ser...@serjux.com writes: On Tue, 2012-03-20 at 19:23 -0500, Ryan Schmidt wrote: On Mar 20, 2012, at 19:17, Sérgio Basto wrote: Hi, I am facing a problem I do a svn diff | lsdiff I got file in random order , also

Re: random order due to APR hash change (was: random sort of svn status and svn diff)

On 2012-03-29 10:07:02 -0400, Mark Phippard wrote: There is an issue filed for this: http://subversion.tigris.org/issues/show_bug.cgi?id=4134 Thanks. I've updated the Debian bug information. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated

Re: Evil UTF-8 Character in filename in repo causing issues on my wc

On 2011-06-22 16:28:31 +0200, Stefan Sperling wrote: On Wed, Jun 22, 2011 at 03:42:42PM +0200, Vincent Lefevre wrote: On 2011-06-15 12:29:37 +0200, Stefan Sperling wrote: Unicode, and it's quirk of allowing the *same* character to be encoded in *different* ways, came much later. I

Re: Evil UTF-8 Character in filename in repo causing issues on my wc

On 2011-06-22 19:34:08 +0200, Stefan Sperling wrote: On Wed, Jun 22, 2011 at 07:09:22PM +0200, Andreas Krey wrote: In my opinion it would be saner nowadays to assume file names to be in utf8 and warn if they are not, and use the setting in LANG for console I/O only. This strategy may

exit status of svn commands

The exit status of svn commands doesn't seem to be specified, at least not by svn help subcommand. In particular, svn update file and svn status file seem to always return with a 0 exit status on non-existing files. This may be normal for svn update in a working copy, because the command makes

SVN_SSH and arguments

Hi, It seems that arguments in SVN_SSH are ignored. I have tested with: Nokia-N900-02-8:~ echo $SVN_SSH /home/user/scripts/ssh -i /home/user/.ssh/id_rsa-svn but a ps -aef after a svn ls svn+ssh://mysvn gives: 19110 user 6228 Szsh /home/user/scripts/ssh mysvn svnserve -t I can add

Re: SVN_SSH and arguments

On 2011-05-25 02:45:39 +0300, Daniel Shahaf wrote: Works for me: % SVN_SSH='perl -e exec qw/ssh/, @ARGV' $svn info svn+ssh://`hostname`//tmp/svn/r1 | grep URL URL: svn+ssh://d3/tmp/svn/r1 OK, I've found the problem. I'm using a svn wrapper (as a workaround to a svn bug), which is a zsh

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-13 08:16:48 +0200, Alexander Skwar wrote: 2010/8/13 Vincent Lefevre vincent-...@vinc17.net On 2010-08-12 17:16:37 +0200, Stefan Sperling wrote: ~/bin/mysvn:  #!/bin/sh  env LC_CTYPE=en_US.preferred charset svn update Wrong, wrong, wrong! Security hole

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-13 09:47:37 +0200, Alexander Skwar wrote: Well, if you want or need to parse the output of a program, you'll need to make sure that it's in the correct locale. The way to do that, is by setting the locale variables to the expected values. Thus, it's totally correct to set LC_CTYPE

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-13 11:18:00 +0200, Stefan Sperling wrote: On Fri, Aug 13, 2010 at 09:37:57AM +0200, Vincent Lefevre wrote: On 2010-08-13 08:16:48 +0200, Alexander Skwar wrote: 2010/8/13 Vincent Lefevre vincent-...@vinc17.net On 2010-08-12 17:16:37 +0200, Stefan Sperling wrote

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-13 11:39:43 +0200, Stefan Sperling wrote: Yes, I see the difference. It's a question of where the primary configuration knob for the charset is located. Right now, the source of charset information is always the locale. You want it to be the locale at checkout time and some

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-12 09:59:30 +0200, Csaba Raduly wrote: On Wed, Aug 11, 2010 at 4:49 PM, Michael Pruemm wrote: Vincent Lefevre wrote: (snip) Under these conditions, the only possibility is to encode the filenames in UTF-8 anyway. So, why not enforcing that? But don't forget

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-12 17:16:37 +0200, Stefan Sperling wrote: On Thu, Aug 12, 2010 at 02:30:50AM +0200, Vincent Lefevre wrote: On 2010-08-11 19:56:28 +0200, Stefan Sperling wrote: On Wed, Aug 11, 2010 at 04:29:56PM +0200, Vincent Lefevre wrote: You're forcing the user to use a UTF-8 locale

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-11 11:11:25 +0200, Paul Ebermann wrote: The thing is, users are using other tools than SVN to work with the files, too. So if I look at my directory with a file manager, I want my filenames to be readable (and renameable). The idea is that usually the user uses for one working

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-11 13:42:35 +0200, Stefan Sperling wrote: On Wed, Aug 11, 2010 at 12:31:48AM +0200, Vincent Lefevre wrote: On 2010-08-10 20:59:00 +0200, Stefan Sperling wrote: Right now, if the filename cannot be represented in the current locale, you get this error: svn: Can't convert string

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-11 13:51:18 +0200, Stefan Sperling wrote: On Wed, Aug 11, 2010 at 12:35:59PM +0200, Vincent Lefevre wrote: On 2010-08-11 11:11:25 +0200, Paul Ebermann wrote: The thing is, users are using other tools than SVN to work with the files, too. So if I look at my directory

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-11 16:20:38 +0200, Alexander Skwar wrote: 2010/8/11 Vincent Lefevre vincent-...@vinc17.net Yes, and this is another reason why the solution chosen by Subversion doesn't work well. For instance, GNOME always uses UTF-8 for filename encoding. So, if the user uses ISO-8859-* locales

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-11 16:26:32 +0200, Vincent Lefevre wrote: On 2010-08-11 13:42:35 +0200, Stefan Sperling wrote: On Wed, Aug 11, 2010 at 12:31:48AM +0200, Vincent Lefevre wrote: On 2010-08-10 20:59:00 +0200, Stefan Sperling wrote: Right now, if the filename cannot be represented in the current

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-11 19:55:01 +0200, Stefan Sperling wrote: On Wed, Aug 11, 2010 at 05:23:31PM +0200, Vincent Lefevre wrote: On 2010-08-11 16:26:32 +0200, Vincent Lefevre wrote: Configuring a UTF-8 locale can yield non-portable behavior. Such as? Outputting messages in a different language

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-11 17:34:19 +0200, Paul Ebermann wrote: Vincent Lefevre wrote: That's wrong. GNOME let's me to use any locale in shell sessions. Subversion doesn't. Yes, but GNOME does not allow using any locale in a file manager session (or, it ignores the locale in the filemanager session

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-11 19:56:28 +0200, Stefan Sperling wrote: On Wed, Aug 11, 2010 at 04:29:56PM +0200, Vincent Lefevre wrote: You're forcing the user to use a UTF-8 locale. Unacceptable. No, we leave users a choice. The choice doesn't work. I consider your idea of forcing UTF-8 filenames

Error svn: Can't open file '/svn/mpfr/db/txn-current-lock': Permission denied

After a repository upgrade with svn version 1.5.1 (r32289) a few days ago, we now get the following error when committing: svn: Can't open file '/svn/mpfr/db/txn-current-lock': Permission denied No problems for read operations. The DB FS type is FSFS, and we have: vlefe...@ff-scm-prod:~$ ls -l

Re: Error svn: Can't open file '/svn/mpfr/db/txn-current-lock': Permission denied

On 2010-08-10 16:12:15 +0200, Vincent Lefevre wrote: After a repository upgrade with svn version 1.5.1 (r32289) a few days Note: the upgrade was done with: svnadmin upgrade /svnroot/mpfr svn-populate-node-origins-index /svnroot/mpfr ago, we now get the following error when committing

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-09 19:30:00 +0300, Daniel Shahaf wrote: In the repository filesystem, we use UTF-8 exclusively. APR handles translating that UTF-8 to whatever the local OS supports. Which is meaningless, since under Unix, the locale is not related to the OS, but to the process: one can have a shell

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-10 17:42:57 +0200, Stefan Sperling wrote: The locale only matters when data is presented to the user (by the svn client, or svnlook, or svnadmin, ...) in which case Subversion uses iconv to translate the UTF-8 data into the character set of the current locale. The svn client also

Re: Error svn: Can't open file '/svn/mpfr/db/txn-current-lock': Permission denied

On 2010-08-10 09:27:50 -0700, David Brodbeck wrote: On Aug 10, 2010, at 7:12 AM, Vincent Lefevre wrote: After a repository upgrade with svn version 1.5.1 (r32289) a few days ago, we now get the following error when committing: svn: Can't open file '/svn/mpfr/db/txn-current-lock

Re: svn checkout - special characters in file name are not encoding properly

On 2010-08-10 20:59:00 +0200, Stefan Sperling wrote: On Tue, Aug 10, 2010 at 07:44:35PM +0200, Vincent Lefevre wrote: This is easy (at least from the specification point of view): once the encoding has been determined[*], typically at checkout time, store the encoding in the WC metadata

Re: Support for filesystem snapshots (?)

On 2010-08-02 14:41:29 -0400, Vallon, Justin wrote: That is the situation I raised. If the network connection between the host that is modifying the repository and the filesystem that houses the repository is lost, will be repository be (a) corrupt, (b) require cleanup (locks, etc), (c)

Re: Support for filesystem snapshots (?)

On 2010-08-02 18:09:26 -0400, Vallon, Justin wrote: If the client or server filesystem buffers are dirty, then the application has not flushed the data. There can be a flush at the application level (e.g. fflush() function in C), but this doesn't mean that the flush is also done at the file

Re: Support for filesystem snapshots (?)

On 2010-08-03 12:56:28 +0200, Stefan Sperling wrote: On Tue, Aug 03, 2010 at 10:33:28AM +, Florian Weimer wrote: Kernel-level buffers are taken into account. Application buffers aren't, the application has to take care of that. But if the Subversion fails to do that, it cannot recover

Re: Support for filesystem snapshots (?)

On 2010-08-03 08:03:33 -0500, Les Mikesell wrote: A filesystem snapshot should present exactly the same scenario as a machine that lost power or crashed for some similar reason at that moment, so the question boils down to whether subversion can recover sensibly from a crash at any point. Not

Re: Support for filesystem snapshots (?)

On 2010-08-03 15:12:19 +0200, Stefan Sperling wrote: On Tue, Aug 03, 2010 at 02:36:41PM +0200, Vincent Lefevre wrote: On 2010-08-03 12:56:28 +0200, Stefan Sperling wrote: Subversion carefully flushes file buffers after writing revision files. What do you mean by flushes file buffers

Avoiding the svn: Write error: Broken pipe error messages

at the possible other error messages. # # Script written by Vincent Lefevre vinc...@vinc17.net in July 2010, # released in the public domain. filter() { unset brpipe while read err do case $err in *Write\ error:\ Broken\ pipe) brpipe=1 ;; *) printf %s\n $err ;; esac done

Re: Avoiding the svn: Write error: Broken pipe error messages

On 2010-07-30 16:52:23 +0200, Vincent Lefevre wrote: Since http://subversion.tigris.org/issues/show_bug.cgi?id=3014 (svn log | head should not print Write error: Broken pipe) isn't fixed yet, I've eventually written a simple wrapper. See attachment. It's not perfect, but better than nothing

Re: problem with peg revision

that was removed from the current directory (actually its ancestor), just by using its name and some revision. And in case you didn't see... On Thu, Mar 25, 2010 at 11:33 AM, Vincent Lefevre vincent-...@vinc17.net wrote: Hi, It seems that peg revisions do not work when a directory has been renamed

Re: Distributed Subversion Repositories

On 2010-02-17 11:10:12 +, Julian Phillips wrote: You might want to take a look at svk, specifically: http://svk.bestpractical.com/view/UsingSVKAsARepositoryMirroringSystem svk is no longer maintained. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible

Re: Distributed Subversion Repositories

On 2010-02-17 11:18:18 +, Julian Phillips wrote: If using a different tool is an option, then there are tools that let you interact directly with Subversion repositories from various other SCM tools, e.g. http://mercurial.selenic.com/wiki/WorkingWithSubversion