Re: Changing the permission checks in libsvn_subr/io.c

On 2024-01-22 04:05:04 +0100, Branko Čibej wrote: > On 13.01.2024 09:58, Daniel Sahlberg wrote: > > Since there wasn't any replies to this and I think the code was working > > fine in all my tests, I comitted as r1915214. Although I finally decided > > to solve the spurious revert messages in a

Re: Changing the permission checks in libsvn_subr/io.c

On 2024-01-10 09:44:51 +0100, Johan Corveleyn wrote: > Interesting discussion. I agree it should at least be documented, and > perhaps be made a bit more clear from the output of 'revert' (but not > sure how far we can go without breaking compat). Changing the current > behavior is probably a more

Re: Changing the permission checks in libsvn_subr/io.c

On 2024-01-05 11:29:16 +0100, Daniel Sahlberg wrote: > Den fre 5 jan. 2024 kl 10:51 skrev Johan Corveleyn : > > > On Fri, Jan 5, 2024 at 8:46 AM Daniel Sahlberg > > wrote: > > ... > > > Since the file doesn't have svn:needs-lock it should be RW [and the > > Reverted message comes from Subversion

Re: "svn diff --diff-cmd" + script using /usr/bin/env broken with Android 14

Hi, This is a bit old, but this is apparently a Termux specific issue, which has just been fixed (but the fix isn't available yet, so that I couldn't test). On 2023-11-20 03:43:31 +0900, Yasuhito FUTATSUKI wrote: > Hello, > > On 2023/11/19 11:34, Vincent Lefevre wrote: > >

Re: Fix issue SVN-4622 (Was: Re: "svn revert -R ." outputs spurious Reverted messages)

On 2023-12-26 16:30:21 +0100, Daniel Sahlberg wrote: > TLDR; svn status is verifying read-only status for each file (based on > svn:needs-lock). I never use the svn:needs-lock property. So I don't see why svn tries to modify the read-only status in this case. -- Vincent Lefèvre - Web:

Re: "svn revert -R ." outputs spurious Reverted messages

On 2023-12-23 22:44:51 +0100, Daniel Sahlberg wrote: > Thank you for your report and also for finding the root cause. I can > confirm this is the same on my machine. I'd like to take a closer look but > I'm not quite sure when I will find the time. > > This has been reported before: >

Re: "svn revert -R ." outputs spurious Reverted messages

On 2023-12-23 03:49:04 +0100, Vincent Lefevre wrote: > In one of my working copies: > > qaa% svn st > qaa% svn revert -R . > Reverted 'etc/apache2/conf-available/javascript-common.conf' > Reverted 'etc/apache2/mods-available/dnssd.load' > Reverted 'etc/apache2/mods

"svn revert -R ." outputs spurious Reverted messages

In one of my working copies: qaa% svn st qaa% svn revert -R . Reverted 'etc/apache2/conf-available/javascript-common.conf' Reverted 'etc/apache2/mods-available/dnssd.load' Reverted 'etc/apache2/mods-available/dnssd.conf' qaa% svn revert -R . Reverted

"svn diff --diff-cmd" + script using /usr/bin/env broken with Android 14

I've reported the following bug on https://github.com/termux/termux-packages/issues/18537 Since this is specific to svn, I'm reporting it here too. In particular, I'm wondering what special thing svn does to trigger the failure compared to the shell. With "svn diff", I use the --diff-cmd

Re: [BUG] svn tries to read a directory on a different filesystem and hangs

On 2022-11-06 04:59:19 +0100, Vincent Lefevre wrote: > I'm also wondering of the consequence of symlinks .svn/entries to > /path-to-attacked-user/.svn/entries, etc. except for the pristine > subdirectory, which Mallory creates as world-writable. If the user > does a "svn up"

Re: [BUG] svn tries to read a directory on a different filesystem and hangs

On 2022-10-31 10:02:14 +, Daniel Shahaf wrote: > Vincent Lefevre wrote on Mon, 24 Oct 2022 13:57 +00:00: > > "svn" goes up in the directory hierarchy to look for a .svn directory. > > The issue is that it doesn't stop at filesystem and/or owner change. > > W

[BUG] svn tries to read a directory on a different filesystem and hangs

"svn" goes up in the directory hierarchy to look for a .svn directory. The issue is that it doesn't stop at filesystem and/or owner change. This has several consequences: * A potential security issue, because some .svn directory may be under control of another user. * On some machine at my lab

Re: [BUG] "svn propedit" loses changes in case of a network failure

On 2022-09-19 11:02:05 +0900, Yasuhito FUTATSUKI wrote: > I can't determine whether this behavior is a bug or not. > > As svn_cl__propedit() calls svn_cmdline__edit_string_externally()[1] > for editing revprop value string with the parameter tempfail_reft is > NULL[2], the temporary file is

Re: [BUG] "svn propedit" loses changes in case of a network failure

On 2022-09-18 01:59:35 +0200, Vincent Lefevre wrote: > On 2022-09-18 01:41:38 +0200, Vincent Lefevre wrote: > > With svn 1.14.2 under Debian/unstable, I wanted to edit a log message > > with > > > > svn pe --revprop svn:log -r 151946 > > > > (not ju

Re: [BUG] "svn propedit" loses changes in case of a network failure

On 2022-09-18 01:41:38 +0200, Vincent Lefevre wrote: > With svn 1.14.2 under Debian/unstable, I wanted to edit a log message > with > > svn pe --revprop svn:log -r 151946 > > (not just a minor change, I was replacing text by a much longer text), > but got an immediate

[BUG] "svn propedit" loses changes in case of a network failure

With svn 1.14.2 under Debian/unstable, I wanted to edit a log message with svn pe --revprop svn:log -r 151946 (not just a minor change, I was replacing text by a much longer text), but got an immediate error from SSH: kex_exchange_identification: read: Connection reset by peer Connection

Re: build/generator/templates/*.ezt and .bat files and svn:eol-style

On 2022-08-20 14:08:43 +0200, Branko Čibej wrote: > On 20.08.2022 00:57, Vincent Lefevre wrote: > > A minor issue I had found during my checks for the URL update: > [...] > > Shouldn't build/generator/templates/vcnet_vsprops.ezt have > > svn:eol-style set to native so

build/generator/templates/*.ezt and .bat files and svn:eol-style

A minor issue I had found during my checks for the URL update: for i in build/generator/templates/*.ezt do file $i; svn pg svn:eol-style $i; done gives build/generator/templates/build-outputs.mk.ezt: ASCII text, with very long lines (478) native build/generator/templates/build_locale.ezt: DOS

Re: [PATCH] URL update to https

On 2022-08-17 13:16:42 -0400, Nathan Hartman wrote: > Looks good to me. Thanks for doing that. I'll commit it shortly. > > Is there anything in particular you'd like the log message to say (other > than credit for writing this patch of course)? Nothing particular. Thanks. -- Vincent Lefèvre -

Re: [PATCH] URL update to https

On 2022-08-14 10:56:07 -0400, Nathan Hartman wrote: > I'm attaching an updated patch with the following changes: > > (1) Revert LICENSE > (2) Revert the license headers Your patch adds a trailing newline to 2 files: subversion/tests/cmdline/svneditor.bat

Re: [BUG] svn patch with svn:eol-style set to native

On 2022-08-15 10:06:48 -0400, Nathan Hartman wrote: > On Sun, Aug 14, 2022 at 8:08 PM Vincent Lefevre > wrote: > > printf %s "$(printf "%d\n" `seq 2 8`)" > file > > One thing I don't understand about the above is why does the outer > printf

[BUG] svn patch with svn:eol-style set to native

About this bug: On 2022-08-14 14:11:15 -0400, Nathan Hartman wrote: > But applying your original patch to a clean working copy and then > running 'svn diff' does show it -- note the - and + of and > "\ No newline at end of file" at the end of the output: [...] > That looks like a bug in SVN.

Re: [PATCH] URL update to https

On 2022-08-14 10:56:07 -0400, Nathan Hartman wrote: > Regarding LICENSE, I also think it should remain identical. OK (if a change is needed, perhaps Apache could do it first, like what the FSF did for GPLv3, in 2017 IIRC). However, I think that there would be no problems to update the license

[PATCH] URL update to https

Hi, Following the thread "http URLs should be updated to https", I've attached a patch that changes the http URLs to https for the following hostnames: subversion.apache.org www.apache.org svnbook.red-bean.com This has been done with perl -pi -e \

[PATCH] autogen.sh errors from autoheader when python doesn't exist

When python doesn't exist (as opposed to python3), running autogen.sh gives errors /usr/bin/env: ‘python’: Permission denied The autogen.sh script itself uses PYTHON="`./build/find_python.sh`" for the .py scripts it runs, but this is not sufficient for Python scripts run by

Re: missing --force option for "svn log" (useful with --diff)

On 2022-07-29 22:41:43 +0300, Pavel Lyalyakin via dev wrote: > On Fri, Jul 29, 2022 at 5:30 PM Branko Čibej wrote: > > > > On 16.07.2022 16:23, Vincent Lefevre wrote: > > > When using "svn log --diff", one may need diff options. > > > One has --di

missing --force option for "svn log" (useful with --diff)

When using "svn log --diff", one may need diff options. One has --diff-cmd, --internal-diff and -x, but --force is missing, though it would be useful too (in particular with --diff-cmd to textify diff inputs). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML

Re: http URLs should be updated to https

On 2022-05-08 17:51:30 +0200, Daniel Sahlberg wrote: > Den fre 11 mars 2022 kl 12:10 skrev Vincent Lefevre >: > > > On 2022-03-11 10:29:12 +, Julian Foad wrote: > > > Julian Foad wrote: > > > > +1. Can you send a patch? > > > > > > By the

Re: http URLs should be updated to https

On 2022-03-11 10:29:12 +, Julian Foad wrote: > Julian Foad wrote: > > +1. Can you send a patch? > > By the way, the reason I ask if you would be willing, rather than "just > quickly doing it" myself, is even a small "obvious" fix like this tends > to require more than it initially looks like:

Re: A two-part vision for Subversion and large binary objects.

On 2022-03-11 10:04:36 +, Julian Foad wrote: > Daniel Sahlberg wrote: > > I'm taking an opposite position with regards on where this should be > > administred. [...] I would prefer a multi-level approach where the > > repository (through svn:foo properties) could suggest pristine-less WC > >

http URLs should be updated to https

When running "svn --help", I get: [...] For additional information, see http://subversion.apache.org/ This URL should be updated to https, and probably other instances in the Subversion source. http://svnbook.red-bean.com is also concerned. Even though the websites automatically redirect to

Re: A two-part vision for Subversion and large binary objects.

On 2022-01-27 17:21:42 +, Julian Foad wrote: > This setting doesn't have to be persistent in the WC. It could be > configured in client run-time config instead (e.g. > ~/.subversion/config), as we previously mentioned. > > If it's stored in the WC then we need to create some new UI to control

Re: A two-part vision for Subversion and large binary objects.

On 2022-01-21 11:15:04 +, Julian Foad wrote: > Premature Hydrating > > The present implementation "hydrates" (fetches missing pristines) every > file within the whole subtree the operation targets. This is done by > every major client operation calling svn_client__textbase_sync() before > and

Re: A two-part vision for Subversion and large binary objects.

On 2022-01-13 22:38:34 -0600, Karl Fogel wrote: > So if we have client-side configuration that can specify "no pristine" based > on some combination of one or more of... > > - file size > - repository of origin > - path and/or basename > - svn:mime-type property (if present) > - some custom

Re: Broken pipe on the diff command with --diff-cmd

On 2021-08-25 19:18:49 -0400, Nathan Hartman wrote: > I don't see mention of it in the issue tracker. Please could you file > it there? Done: https://issues.apache.org/jira/browse/SVN-4879 > I started looking into it but ran out of time for now. Anyway, SIGPIPE > is ignored throughout the

Broken pipe on the diff command with --diff-cmd

Hi, I've found the following issue. When I pipe the output of "svn diff --diff-cmd diff" and a broken pipe occurs on the diff command, I get a "Broken pipe" error: diff: standard output: Broken pipe svn: E200012: 'diff' returned 2 Tested with svn, version 1.14.1 (r1886195) under Debian 11

Re: A two-part vision for Subversion and large binary objects.

On 2021-07-30 22:42:25 -0500, Karl Fogel wrote: > On 30 Jul 2021, Daniel Shahaf wrote: > > Increase the svndiff window size, so a single byte addition at the start > > of the file doesn't result in $filesize/100KB delta ops? > > Maybe? I *think* that's a rare case, and if it is then it's

Re: "svn list -v" column alignment issue

On 2020-01-16 10:37:05 +, Julian Foad wrote: > Branko Čibej wrote: > > > Why are we overthinking this? > > Indeed. There is a lot of energy going in to this thread. It's great to > see energy and enthusiasm, but... > > I know the current algorithm is sometimes annoying. > > I accept

Re: "svn list -v" column alignment issue

On 2020-01-13 16:51:25 +, Daniel Shahaf wrote: > Vincent Lefevre wrote on Mon, 13 Jan 2020 10:26 +00:00: > > Good point. I was about to say that in most cases, these commands are > > run from a working copy. But I now think that caching should be done > > under the u

Re: "svn list -v" column alignment issue

On 2020-01-10 16:58:26 +0100, Johan Corveleyn wrote: > Since both 'svn ls -v' and 'svn blame' can be called on a repository > URL, I don't really see the point in caching the max(length(author)) > of the working copy. > > The output from a URL would still be mis-aligned. It would make the >

Re: "svn list -v" column alignment issue

On 2020-01-08 13:12:21 +, Daniel Shahaf wrote: > Vincent Lefevre wrote on Wed, Jan 08, 2020 at 10:28:01 +0100: > > On 2020-01-07 16:10:52 +, Daniel Shahaf wrote: > > > Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100: > > > > On 2019-12-23 06:35

Re: "svn list -v" column alignment issue

On 2020-01-07 16:10:52 +, Daniel Shahaf wrote: > Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100: > > On 2019-12-23 06:35:08 +, Daniel Shahaf wrote: > > > Two things are not immediately clear to me: > > > > > > - This info is only needed

Re: "svn list -v" column alignment issue

On 2019-12-23 06:35:08 +, Daniel Shahaf wrote: > Vincent Lefevre wrote on Mon, 23 Dec 2019 02:21 +00:00: > > On 2019-12-21 08:09:46 +, Daniel Shahaf wrote: > > > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100: > > > > There's something w

Re: "svn list -v" column alignment issue

On 2019-12-23 03:21:09 +0100, Vincent Lefevre wrote: > On 2019-12-21 08:09:46 +, Daniel Shahaf wrote: > > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100: > > > There's something wrong with "svn list -v" column alignment when > > > th

Re: "svn list -v" column alignment issue

On 2019-12-21 08:09:46 +, Daniel Shahaf wrote: > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100: > > There's something wrong with "svn list -v" column alignment when > > there are author names with more than 8 characters. For instance, &g

"svn list -v" column alignment issue

Hi, There's something wrong with "svn list -v" column alignment when there are author names with more than 8 characters. For instance, with the gcc repository: [...] 279442 jozeflDec 16 12:02 libgcc/ 278886 jvdelisle Dec 01 23:29 libgfortran/ [...] -- Vincent

Re: truncated author names in 'svn ls -v' output

On 2018-12-07 15:10:39 +0100, Branko Čibej wrote: > >> Did you have some specific change you wanted to propose? (Other than > >> making the 'author' column's width configurable) > > I just wanted to have more than 8 characters for the authors names > > (without changing the "file size" column). >

Re: truncated author names in 'svn ls -v' output

On 2018-12-07 12:06:08 +, Daniel Shahaf wrote: > Vincent Lefevre wrote on Fri, Dec 07, 2018 at 12:43:42 +0100: > > the issue with the suffix solution (B/K/M/G) is that it is actually > > less readable when one has many files in the list. I mean that with > > the ful

Re: truncated author names in 'svn ls -v' output

On 2018-11-26 18:19:59 +0100, Stefan Sperling wrote: > On Mon, Nov 26, 2018 at 04:30:27PM +0100, Vincent Lefevre wrote: > > On 2018-11-26 15:18:47 +0100, Branko Čibej wrote: > > > Do please read the rest of the thread. A solution has already been > > > implemente

Re: truncated author names in 'svn ls -v' output

On 2018-11-26 15:18:47 +0100, Branko Čibej wrote: > Do please read the rest of the thread. A solution has already been > implemented on trunk. Except that this solution is not satisfactory for me. I guess that the ultimate solution is to use --xml + a wrapper (thus one could add things like

Re: truncated author names in 'svn ls -v' output

On 2018-11-23 09:10:50 +0100, Stefan Sperling wrote: > At 16 columns, name collisions become far less likely. In our own project, > the output would now look like this: [...] Yes, but this makes less space for long filenames. Why not make this size user-configurable, so that each user may choose

Re: Checkpointing v1 design

On 2017-11-03 19:39:51 +0100, Branko Čibej wrote: > On 03.11.2017 15:54, Julian Foad wrote: > > After playing with two pre-prototypes and discussing a wide variety of > > ideas on this list, I have given detailed thought to a v1 > > checkpointing design with the following properties: > > > >   *

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

On 2017-11-03 10:53:07 +0100, Vincent Lefevre wrote: > Unfortunately, currently I can't. A few days ago, I tried to reproduce > it with similar changes in a sample repository, but this didn't trigger > the bug. I'll try again from information based on strace, i.e. on the > fact

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

On 2017-11-03 10:01:26 +0100, Stefan Sperling wrote: > I agree this looks like a bug. However, it is unclear how to reproduce it. > > Can you provide a sample repository (or shell script) which triggers the bug? Unfortunately, currently I can't. A few days ago, I tried to reproduce it with

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

On 2017-11-03 00:18:59 +0100, Vincent Lefevre wrote: > cventin:~> svn ls -r99809 > file:///home/vlefevre/private/svn-tmp/perso/tcl/fidelite@99808 > svn: E160016: Failure opening '/perso/tcl/fidelite' > svn: E160016: '/perso/tcl' is not a directory in filesystem > '99759

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

[Moving to dev] On 2017-11-01 17:05:24 +0100, Vincent Lefevre wrote: > 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: E16

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

On 2016-09-26 10:04:50 +0100, Julian Foad wrote: > Daniel Shahaf wrote: > > What would content hashes provide that comparing node-rev id's would not? > 1. A node-rev id only exists for a tree that has been committed to > the repository: there is no way to generate a node-rev id for an > external

svn does not react to Ctrl-C when a background process has an unredirected stdout

I've finally found a way to reproduce the following old bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=50 (it still occurs with svn 1.9.4). Make SVN_SSH point to the following script: #!/bin/sh sleep 10 & while true; do :; done

Re: random, unpredictable sort of svn diff

On 2016-05-08 17:56:00 +0200, Branko Čibej wrote: > On 08.05.2016 15:55, Vincent Lefevre wrote: > > I haven't found a bug on this subject on Jira. > > This is hardly a bug, right. I should have said issue (this includes improvements). -- Vincent Lefèvre <vinc...@vinc17.

random, unpredictable sort of svn diff

Hi, The output of "svn diff" is still in random order (not even pseudo-random, completely unpredictable). There had been discussions in the past to fix this, e.g. https://mail-archives.apache.org/mod_mbox/subversion-users/201203.mbox/%3C1332298973.3028.17.camel@segulix%3E What's the status?

Re: Incomplete xml output when using --xml to non-existent server

On 2016-03-03 10:31:52 +0100, Johan Corveleyn wrote: > No, of course not :-). I just gave an example where the output was > broken (host not found), as opposed to another error condition (server > reponds "URL 'X' non-existent in revision Y") where the xml response > is still valid. Ignoring

Re: Unversioned files with invalid UTF-8 sequence in name confuse svn

On 2016-03-01 17:12:05 +0100, Branko Čibej wrote: > On 01.03.2016 16:58, Markus Schaber wrote: > > Hi, Bert, > > > > From: Bert Huijben [mailto:b...@qqmail.nl] > >> From: Markus Schaber [mailto:m.scha...@codesys.com] > >>> Hi, Brane and Vincent, > >>> > >>> From: Branko Čibej

Re: Unversioned files with invalid UTF-8 sequence in name confuse svn

On 2016-02-29 17:00:01 +0100, Bert Huijben wrote: > The problem is most likely not that they have an invalid utf-8 sequence in > their name, but that your settings report that filenames are encoded in one > way, while there is a file which name can't be expressed by that format. > > You get this

Unversioned files with invalid UTF-8 sequence in name confuse svn

With: svn, version 1.9.3 (r1718519) compiled Jan 16 2016, 04:46:46 on x86_64-pc-linux-gnu I have a working copy where "make check" has created files whose name contain invalid UTF-8 sequences. The consequence is that such files confuse svn: $ =svn st svn: E22: Error converting entry in

Perl interface: SVN::Core::dirent_canonicalize segfaults on undef

I have reported the following Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812318 With Subversion 1.9.3: $ perl -MSVN::Core -e 'SVN::Core::dirent_canonicalize(undef)' zsh: segmentation fault (core dumped) perl -MSVN::Core -e 'SVN::Core::dirent_canonicalize(undef)' In case

Perl module SVN::Client and undefined behavior

With the Perl module SVN::Client from Subversion 1.9.3, if one does: #!/usr/bin/env perl use strict; use SVN::Client; my $svnc = SVN::Client->new; $svnc->info('.', undef, undef, sub { }, 0);

dump-load of a repository modifies verbose log output: M line lost

On a Debian/unstable machine with Subversion 1.9.2 and the MPFR repository: I currently have: zira:~> TZ=UTC svn log -r 1984 -v file:///home/vinc17/private/svn-mpfr r1984 | vlefevre | 2002-07-23 16:22:08 + (Tue, 23 Jul

Re: URL's of revisions on http://svn.apache.org/viewvc/

On 2015-08-19 23:36:15 +, Daniel Shahaf wrote: Stefan Sperling wrote on Wed, Aug 19, 2015 at 18:35:55 +0200: On Wed, Aug 19, 2015 at 05:36:16PM +0200, Vincent Lefevre wrote: Hi, It seems that in the past, URL's of the following form were used: http://svn.apache.org/viewvc

URL's of revisions on http://svn.apache.org/viewvc/

Hi, It seems that in the past, URL's of the following form were used: http://svn.apache.org/viewvc?view=revisionrevision=r1686988 This now gives an Invalid revision error / 404 Not Found. The URL's now have the following form: http://svn.apache.org/viewvc?view=revisionrevision=1686988

Re: keywords not updated after an update that doesn't change the file due to local changes

On 2015-06-23 11:04:24 +0200, Julian Foad wrote: On 23 June 2015 at 10:45, Julian Foad julianf...@btopenworld.com wrote: Vincent Lefevre wrote: I have the following problem under Debian with the subversion 1.8.13-1 Debian package, but I don't think that this is Debian specific. It seems

keywords not updated after an update that doesn't change the file due to local changes

I have the following problem under Debian with the subversion 1.8.13-1 Debian package, but I don't think that this is Debian specific. It seems that svn update doesn't update keywords when the local modifications on the concerned file are the same as in the repository. The problem occurs on

Re: Copyright year displayed by command-line tools

On 2015-03-20 03:58:24 -0500, Greg Stein wrote: Daniel Berlin stated many years ago that the years associated with copyright lines are meaningless. There are lots of particular cases, depending on the country of publication, the year of publication, and so on. According to

commit-email.pl generates a wrong Date: header in some locales

Hi, The commit-email.pl script generates a wrong Date: header in some locales, e.g. Date: Tue, 20 May 2014 04:21:21 PM +0200 AFAIK, the reason is that in the strftime line, it uses %X instead of %T. Actually there may also be problems with %a and %b, and for these ones, the only possibility

Re: E175013 svn diff failure (access forbidden) with 1.8.5 (regression)

On 2014-02-17 16:39:56 +, Philip Martin wrote: You might be able to use socat to debug the traffic. Run a socat relay on the client machine, something like: socat -v TCP-LISTEN:9630,reuseaddr,fork OPENSSL:svn.apache.org:443,verify=0 then run the client command, something like:

Re: E175013 svn diff failure (access forbidden) with 1.8.5 (regression)

On 2014-02-14 18:34:52 +, Philip Martin wrote: Vincent Lefevre vincent-...@vinc17.net writes: With svn 1.8.5 under GNU/Linux (Debian unstable), I get an error svn: E175013: Access to '/svn/' forbidden when I do svn diff -r118:119 https://host//subdir;, but svn diff -r118

Re: E175013 svn diff failure (access forbidden) with 1.8.5 (regression)

On 2014-02-14 18:34:52 +, Philip Martin wrote: Vincent Lefevre vincent-...@vinc17.net writes: With svn 1.8.5 under GNU/Linux (Debian unstable), I get an error svn: E175013: Access to '/svn/' forbidden when I do svn diff -r118:119 https://host//subdir;, but svn diff -r118

E175013 svn diff failure (access forbidden) with 1.8.5 (regression)

With svn 1.8.5 under GNU/Linux (Debian unstable), I get an error svn: E175013: Access to '/svn/' forbidden when I do svn diff -r118:119 https://host//subdir;, but svn diff -r118:119 https://host//subdir/file; is OK. There's no such problem with svn 1.6.12 (r955767) on some other

Re: AW: svn cleanup and unreferenced pristines

On 2014-01-13 08:27:34 +, Markus Schaber wrote: On 2014-01-13 03:51:08 +0100, Branko Čibej wrote: On 13.01.2014 03:43, Vincent Lefevre wrote: I meant deltas like in the repository (but see below). When you say delta you have to also define against what. Otherwise it's just

Re: svn cleanup and unreferenced pristines

On 2014-01-10 14:11:08 -0500, C. Michael Pilato wrote: Just a reminder that there can be performance benefits to not being too aggressive in our pristine purging, since update-style operations will consult the pristine cache before slurping file contents from the server. If the working copy

filename encoding in the working copy and symbolic links

The fact that Subversion can choose different encodings, depending on the context, for filenames in the working copy can break symbolic links. But the Book seems to be silent on these encoding issues with symbolic links. And I wonder whether there should be a specific flag for each symbolic link

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

Memory leak in svn log (1.7.5) with svn+ssh?

On Debian and Ubuntu GNU/Linux machines, when I run svn log in some working copy or on some repository URL using the svn+ssh scheme, such as with svn log | tail or, if this is too fast, svn log | less (and searching for a pattern near the end of the output), I notice that the RES memory of

Re: FSFS format7 and compressed XML bundles

On 2013-03-05 16:52:30 +, Julian Foad wrote: Vincent Lefevre wrote: [about server-side vs client-side] But even if there would be no problems with the construction/reconstruction, it would be a bad solution, IMHO. Indeed, for a commit, it is the client that is supposed to expand

Re: FSFS format7 and compressed XML bundles

On 2013-03-06 18:55:55 +, Julian Foad wrote: I don't know if anything like that would be feasible.  It may be possible in theory but too complex in practice.  The parameters we need to extract would include such things as the Huffman coding tables used and also parameters that influence

Re: FSFS format7 and compressed XML bundles

On 2013-03-01 14:58:10 +, Philip Martin wrote: A server-side solution is difficult. Suppose the client has some uncompressed content U which it compresses to C and sends to the server. The server can uncompress C to get U but unless the compression scheme has a canonical compressed form,

Re: FSFS format7 and compressed XML bundles

Hi Julian, On 2013-03-05 13:30:28 +, Julian Foad wrote: Vincent Lefevre wrote: On 2013-03-01 14:58:10 +, Philip Martin wrote: A server-side solution is difficult.  Suppose the client has some uncompressed content U which it compresses to C and sends to the server. The server

Re: FSFS format7 and compressed XML bundles

On 2013-02-28 08:37:51 -0800, Ben Reser wrote: 3) You'd be saving storage at the expense of using time (read: CPU) on every client that's working with those files when checking out. So the end result may be worse than the current problem. But storage is permanent, while a checkout may occur

Re: FSFS format7 and compressed XML bundles

On 2013-02-28 10:58:07 -0800, Ben Reser wrote: Speaking with Julian here at ApacheCon he mentioned that gzip has a rsyncable option. Looking into this turns out that there is a patch applied to Debian's gzip that provides this option. I can't see such an option in Debian's gzip (from

Re: FSFS format7 and compressed XML bundles

On 2013-03-01 14:24:07 +, Philip Martin wrote: $ gzip --help | grep rsync --rsyncable Make rsync-friendly archive $ dpkg -s gzip | grep Version Version: 1.5-1.1 OK, then it seems that its man page is out-of-date. -- Vincent Lefèvre vinc...@vinc17.net - Web:

Re: [RFC] Deprecate Berkelety DB filesystem backend

On 2013-01-05 10:35:52 +, Philip Martin wrote: Branko Čibej br...@wandisco.com writes: * The BDB backend is an order of magnitude slower on trunk than FSFS o timing parallel make check on my 4x4-core i7+ssd mac: + FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s

Re: Bigger --deltas dump with 1.7.5 than with 1.6.17

On 2012-06-20 02:48:23 +0200, Vincent Lefevre wrote: On 2012-06-19 19:41:51 +0300, Daniel Shahaf wrote: I assume that the binary svndiff chunks are different, right? Yes, the binary svndiff chunks are different and have the declared size. But why is 1.6.17 better than 1.7.5? In fact, after

Working copy corruption with svn 1.6.17 (r1128011) under Ubuntu

A few weeks ago, I got a working copy corruption (Checksum mismatch) with svn 1.6.17 (r1128011) under Ubuntu. I tried to reproduce it with similar commands on a test repository, without success. I don't know whether this is a known bug that has been fixed, but just in case, I give the list of

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-07-03 23:31:55 +0200, Johan Corveleyn wrote: So I believe that 1.6's behavior in the working copy is indeed incorrect, and that the LCR of a child was always intended to be unaffected by the move/copy of a parent dir. That's the behavior of the repository, in both 1.6 and 1.7. What you

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-07-04 12:51:13 +0100, Philip Martin wrote: If you are saying that a move should update the LastChangedRev of every file (and dir?) in the destination then that would break the cheap copy feature of Subversion's copy-on-write filesystem. Anyway the URL of every file should be updated,

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-07-04 13:58:50 +0200, Johan Corveleyn wrote: I don't understand. It's pretty clear that 1.6 is incorrect, because it puts a different LCR value in the originating working copy than in the repository. Yes, 1.6 is incorrect, but 1.6 might have a regression compared to 1.4 and/or 1.5. Or

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-07-04 13:28:21 +0100, Philip Martin wrote: Vincent Lefevre vincent-...@vinc17.net writes: The output ends with: + cat dir2/file $Header: file:///tmp/my-test-svn/svn/dir1/file 2 2012-07-04 11:57:43Z vlefevre $ + svn cat file:///tmp/my-test-svn/svn/dir2/file@3 $Header: file

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-07-04 14:26:07 +0200, Johan Corveleyn wrote: We now have two clearly separate discussions: - Inconsistencies in LCR between originating WC and repository. That's my main interest right now. I think those are clearly bugs (1.6 had one, and now 1.7 has another one it seems). -

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-07-04 14:01:36 +0100, Philip Martin wrote: Vincent Lefevre vincent-...@vinc17.net writes: On 2012-07-04 13:28:21 +0100, Philip Martin wrote: Where would the revision 3 come from? LastChangedRev is 2. That's what Subversion's cheap copy means. Yes, but I meant

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-06-27 16:33:23 +0200, Johan Corveleyn wrote: I noticed this while investigating (other) problems with incorrect LastChangedRev's (subtle form of working copy corruption): It seems to be the same thing I had reported here:

Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 2012-07-03 13:15:33 +0200, Johan Corveleyn wrote: No, it's not the same issue (the issue you reported is, let's say, open for discussion, and I don't think the 1.7 behavior is wrong ... it's just different from 1.6). OK, I actually focused on svn info .../subdir, where you get Last Changed

  1   2   >