svn update consumes a lot of data on directory rename

I did a "svn update" (svn+ssh scheme) over a mobile connection, and this consumed several dozens of MB, while there were actually very little changes. There was a rename of a directory with large files, and I suspect that this was the cause. I thought that the system of "cheap copy" would avoid tha

Re: How do I determine if a directory is part of a Subversion working copy?

On 2024-09-25 22:30:40 +0900, Yasuhito FUTATSUKI wrote: > Then nothing is future-proof. We should check changes, > forever. So, shouldn't Subversion provide a command (e.g. svn subcommand) to tell whether some directory is a working copy? The command should either give the answer, with a zero exit

Re: How do I determine if a directory is part of a Subversion working copy?

Hi, On 2024-09-25 11:58:43 +0900, Yasuhito FUTATSUKI wrote: > On 2024/09/25 9:17, Vincent Lefevre wrote: > > > Checking the error message might not be future-proof. > > Then, check the error code instead. It might not be future-proof either. For instance, there has been a

How do I determine if a directory is part of a Subversion working copy?

How do I determine if a directory is part of a Subversion working copy? This is the same question as on https://stackoverflow.com/questions/7172334/how-do-i-determine-if-a-directory-is-part-of-a-subversion-working-copy but all the answers there except mine are incorrect. The issue is that on

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&#x

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 -r

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. -- V

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 (w

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 inte

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() res

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 file2@3"

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 wha

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

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 the

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 b

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 svn_user_get_n

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 pro

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 > > wi

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 an

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 svnse

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 it w

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 Subver

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! Fo

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&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:

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 '9975

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 /perso/tcl,

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 is

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 > '9975

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. -- Vincen

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 above

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 issues

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 than

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 releva

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, 1

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

On 2015-08-20 17:12:58 +0100, Philip Martin wrote: > Vincent Lefevre writes: > > There's no documentation at all about the way it is remembered, > > It is recorded the same way all other auth credentials are recorded. Except for svn+ssh (which is what I always use) because

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 th

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 - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>

Re: ssh+svn vs. bash security bug?

On 2014-09-27 00:45:19 +0100, Philip Martin wrote: > Vincent Lefevre 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 log

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 comm

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 a

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 consis

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 > > unfinishe

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

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 > &g

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

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 cou

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 &qu

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 «

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

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

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 sligh

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 na

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

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

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 - Web: 100% accessible validated (X)HTML - Blog:

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 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 ,

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

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 *

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

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 think it is unfortunate that Apple broke with the concept that a > filename is just a string of bytes. It's also unfortunate

exit status of svn commands

The exit status of svn commands doesn't seem to be specified, at least not by "svn help ". In particular, "svn update " and "svn status " 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 sense in case

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 z

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 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-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 > > > > > > > > On 2010-0

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_CT

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 > > > > On 2010-08-12 17:16:37 +0200, Stefan Sperling wrote: > > > > ~/bin/mysvn: > > >  #!/bin/sh > > >  env LC_CTYPE="en_US." svn update > > > >

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: 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 >

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 o

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, i

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

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 fil

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

On 2010-08-11 16:49:46 +0200, Michael Pruemm wrote: > But don't forget that different platforms may use different UTF-8 > encodings for the same filename. Mac OS X encodes accented > characters in filenames in a different way than Linux. Yes, but that's another problem, for which I think that the

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

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. >

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

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 worki

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 > &g

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 fil

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: 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 shel

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 comm

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: 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. > > > > Wha

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.

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 r

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 sy

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) pri

  1   2   >