Re: svn diff -c does not accept HEAD

[Vincent Lefevre]

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, though, that will be from the BASE revision, not 
> > > HEAD.)
> > 
> > There's also «svn log -r HEAD:0 -l 1 --diff».
> 
> Why not just "svn log -r HEAD --diff"?

Hmm... After thinking about it, this is in case the latest commit
occurred under another directory, so that "svn log -r HEAD" would
be empty.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svn diff -c does not accept HEAD

[Vincent Lefevre]

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 HEAD:0 -l 1 --diff».

Why not just "svn log -r HEAD --diff"?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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">
> > vlefevre
> > 2002-07-23T16:22:08.00Z
> > 
> >  >prop-mods="false"
> >text-mods="true"
> >kind="file"
> >action="M">/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.
> 
> You may be running into this (quoting from svn_fs_contents_changed()'s 
> docstring):
> 
>  * @note svn_fs_contents_changed() was not designed to be used to detect
>  * when two files have different content, but really to detect when the
>  * contents of a given file have changed across two points in its history.
>  * For the purposes of preserving accurate history, certain bits of code
>  * (such as the repository dump code) need to care about this distinction.
>  * For example, it's not an error from the FS API point of view to call
>  * svn_fs_apply_textdelta() and explicitly set a file's contents to exactly
>  * what they were before the edit was made.  We have a pair of functions
>  * that can answer both of these questions, svn_fs_contents_changed() and
>  * svn_fs_contents_different().  See issue 4598 for more details.
> 
> Or maybe that revision was created by a pre-1.0 version of Subversion
> that had some bug or another.

That was in 2002, so at that time we were using CVS, and we converted
the repository to Subversion with cvs2svn on 2005-10-24.

But when I detected this issue, this was with a local mirror, thus
with a repository that has been rebuilt a few weeks ago on a machine
with Subversion 1.14.0.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: forcing update of keyword expansions in a working copy

[Vincent Lefevre]

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 (which used only the Id keyword),
and the commit did only that. But for some of these files (those
that did not have any additional commits later), the expansion of
the Id keyword was still the one from the previous commit. In #4585,
the svn:keywords does not change, which triggers a bug. But here,
svn:keywords had changed.

The commit was done in December 2017 on a Debian/stable machine.
The svn version was 1.9.5 (Debian package 1.9.5-1+deb9u1), and
the working copy was on the same machine.

Now the machine has svn 1.10.4, but for files that didn't had new
commits, "svn up" on the working copy doesn't change anything, so
that these files were still affected by the old issue.

I've just tried to reproduce the bug with the following script:


#!/bin/sh

set -e

mkdir my-test-svn
cd my-test-svn

svnadmin create svn
svn co file://`pwd`/svn wc1
svn co file://`pwd`/svn wc2

cd wc1
mkdir dir
printf '# \044Id\044\n' > dir/file
svn add dir
svn propset svn:keywords "Id Date" dir/file
svn ci -m "add dir/file"
svn update
cat dir/file

cd ../wc2
svn update
cat dir/file
svn propset svn:keywords "Id" dir/file
svn ci -m "new keywords"
cat dir/file
svn update
cat dir/file

cd ../wc1
svn update
cat dir/file


on a machine that has svn 1.9.4 (gcc119.fsffrance.org), but
I haven't noticed any issue (I expected the 3rd and 4th cat
output to be incorrect).

> If the file timestamp changes, but not the file contents ('touch' the
> file and then run 'svn update'), does keyword re-expansion occur?

No, this is never done. You can try by changing the Id keyword
expansion of a file. A "svn update" never fixes it to the correct
value.

> If the file contents change (e.g., add 1 character to the file
> contents then run 'svn update') does the expected keyword expansion
> take place?

Ditto.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

forcing update of keyword expansions in a working copy

[Vincent Lefevre]

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 integrity by
comparing an up-to-date working copy with the result of "svn export"
(some keyword expansions were different, and it appears that the
expansions of the Id keyword were not updated after a commit that
only changed the svn:keywords property from "Id Date" to "Id").

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 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() result for ../.svn (probably because
> > > that directory *might be* a possible mount point for the automounter)
> > > but then yields EIO when trying to access anything within that
> > > ficticous directory (because nothing is actually mounted there).  
> > 
> > Do you mean that Subversion tries to go higher in the hierarchy
> > without checking the owner of the directory? If it does, this is
> > a security issue.
> 
> How so?  What's the attacker model?  What can someone leverage this
> feature of Subversion to do that they couldn't do without it?

I don't know all the various possibilities, but there's at least a
denial of service:

zira:/tmp> mkdir vinc17
zira:/tmp> cd vinc17
zira:/tmp/vinc17> svn co file:///home/vinc17/repos wc
svn: E200030: sqlite[S1]: no such table: wcroot
zira:/tmp/vinc17[1]>

That's with an attacker who creates a .svn directory in /tmp and
an empty wc.db file in it.

On systems without symlink restriction in world-writable directories,
I was wondering whether there could be a way to create files in the
user's home directory. My attempt yielded a sqlite error because
O_NOFOLLOW was used, which is a good thing.

But I'm also wondering whether there could be some leak in wc.db
in case the user does a "svn up" from a wrong directory (such as
/tmp/vinc17 above, with an attacker creating a .svn directory in
/tmp with a URL of a private repository belonging to the user).
A small error like this should never become a security issue.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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() result for ../.svn (probably because
> that directory *might be* a possible mount point for the automounter)
> but then yields EIO when trying to access anything within that
> ficticous directory (because nothing is actually mounted there).

Do you mean that Subversion tries to go higher in the hierarchy
without checking the owner of the directory? If it does, this is
a security issue.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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". Sorry for the typo.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 find repository location for..." error
> >>   -r3: one gets file2@3
> 
> Hm, it might be related, but I don't see this as exactly the same
> problem. IMHO this is normal and correct behavior.

I think that, as -c is documented, this is the same issue: "-c M" is a
shorthand for "-r N:M" with N = M−1. Thus

  svn diff -c3 file2

is equivalent to

  svn diff -r2:3 file2@BASE

Here, BASE is assumed to be 3 (or equivalent). Thus one should get the
difference between the contents corresponding to

  svn cat -r2 file2@3

and

  svn cat -r3 file2@3

> Indeed, in r2 there was no file2.

This is not really what is described here:

  http://svnbook.red-bean.com/en/1.6/svn.advanced.pegrevs.html

OPERATIVE-REV is older than PEG-REV. Thus

1. Locate item in the revision identified by PEG-REV. There can be
   only one such object.

→ This is file2.

2. Trace the object's history backwards (through any possible renames)
   to its ancestor in the revision OPERATIVE-REV.

→ As I understand it, the history is as followed.

There is file2 at revision 3, which is a copy of file1 from revision 1.
At revision 1, this is file1. The renamed (and modification) occurred
at revision 3, thus I would say that revision 2 did not introduce a
change of the file, i.e. this is like file1@1. If the file is assumed
to be nonexistent, then this would mean that in the history line, it
has been removed, then re-added; this does not make sense to me, as
there was no such operation in the history.

> In r1 there was a predecessor of file2@3, namely file1@1. You could
> argue that in r2 it should show the contents of file1@1 (which were
> incidentally unchanged in r2).

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.

> But what if file1 would have been changed in r2 (yet file2@3 was a
> copy of file1@1), what would you expect svn to show?

Obviously file1@1, as file1@2 is *not* an ancestor of file2@3.
Just like file1@3 will not affect file2@3.

Remember, we are looking at the (backward) *history* of file2@3.

> Or what if file1 was deleted in r2?

Ditto, file1@1.

> I guess the same questions can be asked for 'svn diff -c 3' (what if
> file1 had a different content in r2, or was deleted in r2?). Yet in
> that case I intuitively expect "diff -c3" to take the copy-source into
> account, no matter if it has made a jump through history. As I argued
> in [3] above, it seems 'svnlook' can do this with its --diff-copy-from
> option ... (which I happen to like for generating diffs in post-commit
> emails).

My above interpretation of the history would have the advantage to
make it consistent with the current specification of "diff -c".

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 what happens when one
does a "svn copy" directly from the working copy without an update
first.

If I do "svn diff -r 1:3 file2", then I get the changes that have been
introduced between file1 and file2. But if I do "svn diff -c 3 file2",
which is equivalent to "svn diff -r 2:3 file2", then I get the whole
file2 content, as if file2 were an entirely new file.

I'm wondering whether this is the expected behavior. In any case,
this behavior is rather unintuitive and rather useless. I think there
should be an easy way to get the changes introduced by a commit.

Note: "svn cat -r... file2" or "svn cat -r... file2@3" also shows a
similar behavior:
  -r1: one gets file1@1
  -r2: "Unable to find repository location for..." error
  -r3: one gets file2@3

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[SOLVED] freezing "svn up"

[Vincent Lefevre]

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," for
> the client, "read(0," for the server.
> 
> On the client, after almost half an hour, I eventually got the
> error:
> 
> client_loop: send disconnect: Broken pipe
> svn: E210002: Network connection closed unexpectedly
[...]

Since the problem was still occurring (in general without an error,
just the fact that "svn up" was abnormally slow), I eventually
rebooted the client machine. Since then I could not reproduce the
problem.

Note: SSH connection sharing was not used.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: freezing "svn up"

[Vincent Lefevre]

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 3:49. But in general, this seems fine from
> this second copy, while problems are much more common from the
> first one.

The reason was that I was testing the second working copy
while a "svn up" was freezing on the first one. So, to
reproduce the freeze, there must not be a running "svn up"
on another working copy.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

freezing "svn up"

[Vincent Lefevre]

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

client_loop: send disconnect: Broken pipe
svn: E210002: Network connection closed unexpectedly

and several dozens of seconds later, the svnserve was killed by
a SIGPIPE (according to strace).

Earlier, it took 17 minutes for "svn up" to complete (instead of
less that one second usually up to a few seconds), without any
error, but the corresponding svnserve was still running for a few
more minutes.

The last one took:
  0.34s user 0.09s system 0% cpu 19:32.19 total

Again, after a few minutes, the svnserve is still running, but
there's still the sshd:

root │ └─> 16718  sshd: svn [priv]
 svn │   └─> 16725  sshd: svn@notty
 svn │ └─> 16766  sh -c svnserve -t -r d_joooj/home/svn/root 
--tunnel-user=vinc17/cventin
 svn │   └─> 16767  svnserve -t -r d_joooj/home/svn/root 
--tunnel-user=vinc17/cventin

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 3:49. But in general, this seems fine from
this second copy, while problems are much more common from the
first one.

Client:

svn, version 1.10.4 (r1850624)
   compiled Jan 23 2019, 03:41:34 on x86_64-pc-linux-gnu

Server:

svnserve, version 1.9.5 (r1770682)
   compiled Jul 30 2019, 02:45:42 on x86_64-pc-linux-gnu

journalctl does not show any issue (except the usual message
"DIGEST-MD5 common mech free" for the svn client).

With another Debian/unstable machine as the client, which is
in the same room as the other one (thus similar conditions),
I haven't noticed any issue.

Any idea?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svn and svnserve hanging

[Vincent Lefevre]

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 better to honor the value of $HOME
for that purpose.

> Still, I don't see from the code how it could hang. The homedir is
> either found or not, and if it's not, it's ignored.

So it would mean that it is at the glibc level that it blocks.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svn and svnserve hanging

[Vincent Lefevre]

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.
> > 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_name is called, and I'm wondering whether this is
> > the cause.
> 
> 
> That just calls apr_uid_name_get(), so the call chain is
> svnserve->APR->glibc. The latter's implementation would look at
> nsswitch.conf. That suggests that is is related to user configuration
> somehow. But I don't know much about that topic.
> 
> The name caching daemon is something glibc would use directly, most likely.

Yes, what happens to get the user name depends on the nsswitch.conf.
The user name is not stored on this machine, so I assume that the
glibc function yields a connection to this daemon. Then I don't know
whether the hang occurs there or an error is reported but somewhere
the error makes the process hang.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svn and svnserve hanging

[Vincent Lefevre]

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_name is called, and I'm wondering whether this is
the cause.

[*] on a different machine, where strace is installed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svn and svnserve hanging

[Vincent Lefevre]

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
problem in the past. And when I looked at the other "svnserve -t"
processes that were started a long time ago on the machine, except
for 2 users (which seemed to be particular as having many svnserve
processes), the start times were also multiples of 10 minutes.

Thus it seems to be a bug in svnserve (or a library it uses to connect
to this daemon), which doesn't seem to handle failures correctly.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svn and svnserve hanging

[Vincent Lefevre]

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 Ctrl-C and kill the SSH master too, the sshd terminates, but
> > svnserve is still running, and now has 1 as its PPID:
> > 
> > UIDPID  PPID  C STIME TTY  TIME CMD
> > vlefevre 48724 1  0 12:40 ?00:00:00 svnserve -t
> 
> Hmm... that looks like the svnserve process was in zombie state
> and is not being terminated. It is the init system's job to call
> waitpid() for such processes.

No, it is not in zombie state. It is still running.

> > If svnserve was waiting for something from sshd, it should at least
> > have noticed that the connection is no longer there.
> 
> There is no connection as far as svnserve is concered.
> In tunnel mode, svnserve reads from stdin and write to stdout, and
> it is done when these get closed or the process is terminated for
> some reason.

Yes, but that's how it is connected to sshd. The parent process
(sshd) has died. So, if svnserve was reading from the pipe, it
would have got an error.

> I suspect the problem is caused either in SSH or somewhere else on
> your server.

It cannot be SSH, since SSH has terminated but svnserve was still
running.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svn and svnserve hanging

[Vincent Lefevre]

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 and working reproduction recipe.
> 
> Sorry, but bugs don't get fixed by magic ;)

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 Ctrl-C and kill the SSH master too, the sshd terminates, but
svnserve is still running, and now has 1 as its PPID:

UIDPID  PPID  C STIME TTY  TIME CMD
vlefevre 48724 1  0 12:40 ?00:00:00 svnserve -t

If svnserve was waiting for something from sshd, it should at least
have noticed that the connection is no longer there.

lsof still shows:

svnserve  48724  vlefevre  cwd   DIR   0,32 4096 110673531 
/home/users/vlefevre (...:/forge_home)
svnserve  48724  vlefevre  rtd   DIR  254,0 4096 2 /
svnserve  48724  vlefevre  txt   REG  254,086256  9413 
/usr/bin/svnserve
svnserve  48724  vlefevre0r FIFO0,8  0t0 957950313 
pipe
svnserve  48724  vlefevre1w FIFO0,8  0t0 957950314 
pipe
svnserve  48724  vlefevre2w FIFO0,8  0t0 957950315 
pipe
svnserve  48724  vlefevre3r  CHR1,9  0t0  7109 
/dev/urandom

BTW, is the permanent open of /dev/urandom normal?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svn and svnserve hanging

[Vincent Lefevre]

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 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.
> > 
> > I'm using SSH connection sharing and the master (started at 12:39,
> > i.e. the same master as with the hanging svn) is still working.
> 
> Interesting. Does the problem also occur if you disable SSH
> connection sharing completely? Perhaps it is related?

This problem occurs not often enough to know (except by doing
background tests in a loop).

> > > You could try to get some information out of SSH? Perhaps the sshd
> > > server logs contain clues?
> > 
> > I've asked the sysadmin, but since the SSH master still works,
> > I doubt that this would be related.
> 
> How can you know that? My and your guesses are only as good as any
> other guesses. Until more information is surfaced which pins things
> down further we simply don't know anything at all about this problem.

If sshd would have detected an issue on its side, I would have
got some information on the client side, unless there is a bug
in the error reporting of openssh. On the client side, svn is
still hanging with no output, and no errors on the master ssh
debug output.

Still no answer for the sysadmin.

I can have lsof information on the server, in case this can provide
useful information:

* for sshd:
COMMAND PID   TIDUSER   FD  TYPE DEVICE SIZE/OFF  NODE 
NAME
sshd  48655  vlefevre  cwd   unknown   
/proc/48655/cwd (readlink: Permission denied)
sshd  48655  vlefevre  rtd   unknown   
/proc/48655/root (readlink: Permission denied)
sshd  48655  vlefevre  txt   unknown   
/proc/48655/exe (readlink: Permission denied)
sshd  48655  vlefevre NOFD 
/proc/48655/fd (opendir: Permission denied)

* for svnserve:
COMMAND PID   TIDUSER   FD  TYPE DEVICE SIZE/OFF  NODE 
NAME
svnserve  48724  vlefevre  cwd   DIR   0,32 4096 110673531 
/home/users/vlefevre (...:/forge_home)
svnserve  48724  vlefevre  rtd   DIR  254,0 4096 2 /
svnserve  48724  vlefevre  txt   REG  254,086256  9413 
/usr/bin/svnserve
svnserve  48724  vlefevre0r FIFO0,8  0t0 957950313 
pipe
svnserve  48724  vlefevre1w FIFO0,8  0t0 957950314 
pipe
svnserve  48724  vlefevre2w FIFO0,8  0t0 957950315 
pipe
svnserve  48724  vlefevre3r  CHR1,9  0t0  7109 
/dev/urandom

(I've excluded the library files).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svn and svnserve hanging

[Vincent Lefevre]

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.

I'm using SSH connection sharing and the master (started at 12:39,
i.e. the same master as with the hanging svn) is still working.

> You could use strace to figure out which system call programs are
> sleeping in, e.g.: strace -p 48724

Unfortunately strace is not installed on the server.

Concerning the svn client, that's

strace: Process 19549 attached
read(6,

and for the SSH client:

strace: Process 19565 attached
restart_syscall(<... resuming interrupted restart_syscall ...>

> You could try to get some information out of SSH? Perhaps the sshd
> server logs contain clues?

I've asked the sysadmin, but since the SSH master still works,
I doubt that this would be related.

> On the client side you can do this: export SVN_SSH='ssh -q -vvv --'
> and try to reproduce the problem. Maybe the SSH client will print
> something useful when the problem occurs?

I don't know how to reproduce the problem. The master is already
started with -vvv, but there are no dates. However, I don't see
anything suspicious.

After doing a SSH connection via the master and quitting, I get
concerning the status:

debug3: channel 3: status: The following connections are open:
  #1 mux-control (t16 r2 i0/0 o0/0 e[closed]/0 fd 6/6/-1 sock 6 cc -1)
  #2 client-session (t4 r0 i0/0 o0/0 e[write]/0 fd 7/8/9 sock -1 cc 1)
  #3 mux-control (t16 nr0 i3/0 o3/0 e[closed]/0 fd 10/10/-1 sock 10 cc -1)

#2 can only be the session of the hanging svn.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

svn and svnserve hanging

[Vincent Lefevre]

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 svnserve -t
vinc17   19565 19550  0 12:40 pts/11   00:00:00 ssh -F /home/vinc17/.ssh/config 
-C gforge svnserve -t

and on the server side:

root 48651   878  0 12:39 ?00:00:00 sshd: vlefevre [priv]
vlefevre 48655 48651  0 12:39 ?00:00:00 sshd: vlefevre@notty
vlefevre 48724 48655  0 12:40 ?00:00:00 svnserve -t

Such an issue occurs from time to time.

Version on the client side:

svn, version 1.10.4 (r1850624)
   compiled Jan 23 2019, 03:41:34 on x86_64-pc-linux-gnu

Version on the server side:

svnserve, version 1.8.10 (r1615264)
   compiled May 21 2018, 00:10:07 on x86_64-pc-linux-gnu

A search on the web shows many reports about hanging svn.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 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 Subversion would unprotect it before an operation and
> > protect it again just after.
> 
> How would you do that, realistically? I can't think of any way other
> than changing permissions on all files within that directory.

Unsetting the 'r' permission on the .svn directory should be
sufficient: recursive operations would not be able to open this
directory for reading.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 Subversion would unprotect it before an operation and
protect it again just after.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: SVN keyword replacement

[Vincent Lefevre]

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! For instance,
if the file is in a directory that has been renamed and the file hasn't
changed since, then the expanded path will become obsolete (mentioning
the old directory name).

For instance, after a "svn mv dir newdir" and commit:

$ cat newdir/file
$PathRev: dir/file, r2 $
$ svn pl -v newdir/file
Properties on 'newdir/file':
  svn:keywords
PathRev=%P,%_r%r
$ svn info newdir/file
Path: newdir/file
Name: file
Working Copy Root Path: /home/vlefevre/tmp/svntest/wc
URL: file:///home/vlefevre/tmp/svntest/foo/newdir/file
Relative URL: ^/newdir/file
Repository Root: file:///home/vlefevre/tmp/svntest/foo
Repository UUID: c461bb2a-7775-4e63-8d8c-e8e280081214
Revision: 3
Node Kind: file
Schedule: normal
Last Changed Author: vlefevre
Last Changed Rev: 2
[...]

BTW, the documentation in
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html
is incorrect:

  %P
The file's path, relative to the repository root.

should be

  %P
The file's path of the revision given by %r, relative to the
repository root.

AFAIK, "of the revision given by %r" applies to all format codes.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: problem with viewvc

[Vincent Lefevre]

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.
> The page simply takes way too long to generate, so the proxy (gunicorn)
> times out.
> 
> Stick to the "modified" links for individual files or subdirectories, and
> ignore the one for the main branch :-)

OK, but I think that a clearer error message, such as "Page too large",
would be better. Alternatively, make ViewVC suppress links yielding
such issues, if possible.

FYI, I hoped to see there a "Diff to previous" link to the patch
corresponding to the changeset r1814248, instead of having to look
at every diff for individual files. Otherwise I cannot find such a
link. This is rather annoying.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

problem with viewvc

[Vincent Lefevre]

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 reading from remote server

or

HTTP/1.1 NoneServer: gunicorn/19.7.1
Date: Wed, 27 Dec 2017 13:23:12 GMT
Connection: close

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 
'99759db8-4ec0-0310-8bf9-df86780d22d8'

ioooi:~> svn ls -r99809 
file:///srv/d_ioooi/home/svn/root/perso/tcl/fidelite@99808
fidelite

FYI, ioooi is the old server, which I migrated with dump+load to
joooj at revision r102683. So, I should have obtained the same
result; the one given by ioooi is the expected one.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 -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).
> 
> How did you determine this?

svn log -v on the root and on perso/tcl.

Note also that this is my personal repository, and I know what I did.

> Please show the output of 'svn log -qvr103183 ^/'.

joooj:~/wd> svn log -qvr103183 '^/'

r103183 | vinc17/zira | 2017-11-01 00:35:54 +0100 (Wed, 01 Nov 2017)
Changed paths:
   M /perso/tcl/fidelite


> Are there any authz read restrictions in effect?

No restrictions.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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, meaning it was
> Replaced by another node, not historically related to /perso/tcl
> before. And 103183 replaced it again with a copy of the original node.

No, there's no such thing. This directory was created in r99807,
and the only changes were on the file "fidelite".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 just a change of the contents of this file (nothing else).

Even simpler:

joooj% svn ls -r103182 
file:///srv/d_joooj/home/svn/root/perso/tcl/fidelite@103182
fidelite
joooj% svn ls -r103183 
file:///srv/d_joooj/home/svn/root/perso/tcl/fidelite@103183
fidelite
joooj% svn ls -r103183 
file:///srv/d_joooj/home/svn/root/perso/tcl/fidelite@103182
svn: E160016: Failure opening '/perso/tcl/fidelite'
svn: E160016: '/perso/tcl' is not a directory in filesystem 
'99759db8-4ec0-0310-8bf9-df86780d22d8'
joooj% svn ls -r103182 
file:///srv/d_joooj/home/svn/root/perso/tcl/fidelite@103183
svn: E160016: Failure opening '/perso/tcl/fidelite'
svn: E160016: '/perso/tcl' is not a directory in filesystem 
'99759db8-4ec0-0310-8bf9-df86780d22d8'

Ditto between r103181 and r103182, while the commit r103182 occurred on
an unrelated path.

So, it seems that for this file, if the operative revision is different
from the peg revision, this doesn't work. This is not what is described
at http://svnbook.red-bean.com/en/1.6/svn.advanced.pegrevs.html and not
the behavior I can observe on the other files, even in the same
directory. So, this seems to be a bug.

Note: "svnadmin verify /srv/d_joooj/home/svn/root" did not find any
issue.

FYI, this is a Debian/stable (stretch) machine, with:

svn, version 1.9.5 (r1770682)
   compiled Aug  9 2017, 03:04:58 on x86_64-pc-linux-gnu

Copyright (C) 2016 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - using serf 1.3.9 (compiled with 1.3.9)
  - handles 'http' scheme
  - handles 'https' scheme

The following authentication credential caches are available:

* Plaintext cache in /srv/d_joooj/home/vinc17/.subversion
* Gnome Keyring
* GPG-Agent
* KWallet (KDE)

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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-8bf9-df86780d22d8'
> 
> Why?
> 
> A "svn up" (which actually updated nothing) solved the issue.

Actually this was via a wrapper script, and I forgot that there was
the argument -rHEAD:1, but I still don't understand. I can reproduce
the problem on another machine (Debian/stable), without the script:

joooj:~p/tcl> svn info
Path: .
Working Copy Root Path: /srv/d_joooj/home/vinc17/wd
URL: svn+ssh://mysvn/perso/tcl
Relative URL: ^/perso/tcl
Repository Root: svn+ssh://mysvn
Repository UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
Revision: 103179
Node Kind: directory
Schedule: normal
Last Changed Author: vinc17/zira
Last Changed Rev: 103087
Last Changed Date: 2017-10-28 02:20:25 +0200 (Sat, 28 Oct 2017)

joooj:~p/tcl> svn info fidelite
Path: fidelite
Name: fidelite
Working Copy Root Path: /srv/d_joooj/home/vinc17/wd
URL: svn+ssh://mysvn/perso/tcl/fidelite
Relative URL: ^/perso/tcl/fidelite
Repository Root: svn+ssh://mysvn
Repository UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
Revision: 103179
Node Kind: file
Schedule: normal
Last Changed Author: vinc17/zira
Last Changed Rev: 103087
Last Changed Date: 2017-10-28 02:20:25 +0200 (Sat, 28 Oct 2017)
Text Last Updated: 2017-10-28 02:20:43 +0200 (Sat, 28 Oct 2017)
Checksum: 342e6a9d9e633495bf788cf38d9a536eb975ff1d

joooj:~p/tcl> =svn log -rHEAD:1 fidelite
svn: E160016: Failure opening '/perso/tcl/fidelite'
svn: E160016: '/perso/tcl' is not a directory in filesystem 
'99759db8-4ec0-0310-8bf9-df86780d22d8'

joooj:~p/tcl> svnversion
103179

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: differences in dump/load/dump cycle

[Vincent Lefevre]

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, if you see a difference
> between the two exports you would then investigate their cause.

export -> import -> export is less safe: how do you know that what
has been exported is "correct"? Note that with old repositories (and
perhaps this is still possible with some external tools), starting
with revision R1 and successively upgrading to R2 may give a different
result from just getting R2 without intermediate revisions. If the
problem is unnoticed, information may definitively be lost in the
repository started from the export.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: differences in dump/load/dump cycle

[Vincent Lefevre]

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 mainly because they care about the history.
Even if one occasionally wants to start a new repository, this
should not be dictated by an upgrade of Subversion. And what about
the old repository? I think that in such a case, one wants to
archive it, but one also needs to make sure that it is still
correctly readable with new Subversion versions and not be affected
by new bugs.

FYI, I regularly do partial or full dumps of my repositories (always
a full dump after a major Subversion upgrade), and compare the result
with the old dump. If I need a dump/load cycle, then I also always do
a full dump after that to compare.

I've found differences many times after a major upgrade, and I've
reported potential issues in the dev list. Sometimes, these were
non-significant changes: reordering of data (the most annoying one
was the random order after some APR upgrade because it broke the
comparisons, but then a new fixed order was chosen in Subversion),
blank lines, redundant information dropped, additional hashes...
Sometimes, these were bugs. But as long as one keeps the old dumps
until the problem is solved, one doesn't lose anything.

BTW, I would say that if there is a difference between dumps that
is not a bug, then do a load/dump again to make sure that the dump
is loadable and identical to the dump obtained after this operation.

There are sometimes differences in the compressed deltas, but I
suppose that if the hashes are the same, then everything is OK.
I suppose that Subversion always checks all the hashes when doing
a load.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 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, 12:51:30 on x86_64-pc-linux-gnu
> > > 
> > Can you try to bump your svnserve version to at least 1.8.15?
> 
> The machine is an Ubuntu 14.04 LTS, and 1.8.8 is the latest version
> in this distribution. But I plan to upgrade it to 16.04 LTS in a few
> days.

I forgot that I had kept a very recent copy of the repository
(obtained with dump + load) on a Debian/unstable machine (the goal
was to do some tests before the server upgrade). So, I could test
with it, still using svn+ssh (but here, localhost). An "svn blame"
on the same file takes a small memory footprint for both the svn
client and svnserve (around 16 - 30 MB for resident memory, around
250 MB for virtual memory).

So, I suppose that the memory problem was a bug in 1.8.8.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 relevant revisions is far more interesting... as is how much
> really changed in the file.

There are 1831 revisions. But once a diff has been sent, I suppose
that it doesn't need to be in the server's memory any longer.

For each new revision, not much is changed in the file: just some
added lines (20 in average), and 1 or 2 modified lines in general
(always the same ones).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 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, 12:51:30 on x86_64-pc-linux-gnu
> > 
> Can you try to bump your svnserve version to at least 1.8.15?

The machine is an Ubuntu 14.04 LTS, and 1.8.8 is the latest version
in this distribution. But I plan to upgrade it to 16.04 LTS in a few
days.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

svnserve takes too much memory for "svn blame"

[Vincent Lefevre]

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, 12:51:30 on x86_64-pc-linux-gnu

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Problem with svnsync when the auth directory has been removed

[Vincent Lefevre]

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 the svnsync user can change revprops

with the pre-revprop-change hook mentioned on:

  http://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt

I would have expected the username svnsync to be remembered.

There's no documentation at all about the way it is remembered, and
the relation to the .config/auth directory was not obvious: there's
nothing related to authentication here.

It seems that the fix is to provide the --sync-username svnsync
option to svnsync, and then this option is no longer needed. Again,
this is not documented.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: ssh+svn vs. bash security bug?

[Vincent Lefevre]

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 for the user, from session.c:
 
 /*
  * Execute the command using the user's shell.  This uses the -c
  * option to execute the command.
  */
 argv[0] = (char *) shell0;
 argv[1] = -c;
 argv[2] = (char *) command;
 argv[3] = NULL;
 execve(shell, argv, env);
 perror(shell);
 exit(1);
 
 
 So an svn+ssh installation can be secured by ensuring that the command
 svnserve -t is forced and the corresponding login shell is not bash.

which is the case on my server: the login shell of the svn user is
/bin/sh (which is a symlink to dash).

 Subversion cleans the environment before invoking hooks so any hooks
 invoked by svnserve are safe even if those hooks use bash.

I also use /bin/sh for hooks anyway.

 A patch to add a no-user-shell option to OpenSSH has been suggested:
 
 http://www.openwall.com/lists/oss-security/2014/09/25/41
 
 However if there is no shell then OpenSSH either has to parse the
 command itself, which is non-trivial, or there is a restriction that no
 parameters are passed to the executable, or there has to be a way of
 specifying executable and parameters separately.

There could be a restriction that no special characters are used
in the command (which would generally be sufficient for Subversion,
AFAIK), so that splitting on spaces would be sufficient.

 There is a similar driver in Subversion: a shell is used when invoking
 the arbitrary, used-defined, --editor-cmd/SVN_EDITOR string so that
 Subversion does not have to parse it.  This is different from hooks
 where a direct exec is used.

It there were an option to do an exec, you would be OK for me,
because I've set SVN_EDITOR to a full pathname (to a Perl script
that is a wrapper to the editor).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: ssh+svn vs. bash security bug?

[Vincent Lefevre]

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 the authorized_keys file will *not*
 work around the problem: http://seclists.org/oss-sec/2014/q3/651

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

 It should be possible to mitigate this attack vector by having
 svnserve run in an environment that doesn't have bash available,
 either with no bash binary at all on the system, or within a chroot.

The main bug would be that OpenSSH might be able to start bash while
the user has never allowed it.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

corrupt data with svn 1.7.14?

[Vincent Lefevre]

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 consistent
broken behavior. I don't know whether this is Debian-specific or
not.

With my private repository:

xvii:...www/contents/cine =svn diff -r 51990 index.fr.xml
Index: index.fr.xml
===
Cannot display: file marked as a binary type.
svn: E22: Valid UTF-8 data
(hex: 73 76 6e 3a 6d 69 6d 65 2d 74 79 70 65 20 3d 20 28)
followed by invalid UTF-8 sequence
(hex: a8 a5 93 55)

with:

svn, version 1.7.14 (r1542130)
   compiled Dec 27 2013, 15:24:53

This problem is reproducible on a second Debian/unstable machine,
but not on a 3rd machine, with svn 1.6.12.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: corrupt data with svn 1.7.14?

[Vincent Lefevre]

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
 1.7.14. However I no longer get random behavior, just consistent
 broken behavior. I don't know whether this is Debian-specific or
 not.

To reproduce it with a public repository:

ypig:~ svn co svn://scm.gforge.inria.fr/svn/mpfr/misc/vl-tests
Avl-tests/mpfrtests.data
Avl-tests/mpfrtests.sh
Avl-tests/release-3.1.2-p4
Avl-tests/release-3.1.0-p8
Avl-tests/vfy-data
Avl-tests/ReadMe
Checked out revision 8727.
ypig:~ cd ./vl-tests
ypig:~/vl-tests svn diff -r8726 ReadMe
Index: ReadMe
===
Cannot display: file marked as a binary type.
) H(mime-type = (H(
Index: ReadMe
===
--- ReadMe  (revision 8726)
+++ ReadMe  (working copy)

Property changes on: ReadMe
___
ypig:~/vl-tests svn diff -r8726 ReadMe
Index: ReadMe
===
Cannot display: file marked as a binary type.
svn: E22: Valid UTF-8 data
(hex: 73 76 6e 3a 6d 69 6d 65 2d 74 79 70 65 20 3d 20 28 48)
followed by invalid UTF-8 sequence
(hex: 87 bb 01 d5)

Downgrading to 1.7.13 solves the problem.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 it to something like:
  
  cleanup: Recursively clean up the working copy, removing locks, resuming
  unfinished operations, removing unreferenced pristines, etc.
  In 1.7, we recommend to run svn cleanup periodically to reduce the size
  of the working copy.
 
 Perhaps saying to remove unferenced pristine copies of files or
 something similar is clearer than reduce the size of the wording copy?

Or to claim back the disk space of unreferenced pristines like in
the release notes?

Though remove unreferenced pristine copies of files implies more
disk space, saying it explicitly makes it clear that the goal of
this operation is to free some disk space (in addition to rare
security reasons, in case a file with sensitive information was
added by mistake in the past).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 could be needed.
I don't know what is the best solution.

I've reported a bug on the Debian BTS about that:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731769

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 (I'm wondering how many users know that);
 
 It's documented in the 1.7 release notes.
 
 http://subversion.apache.org/docs/release-notes/1.7#wc-pristines

Unfortunately there are lots of things in the release notes, and it
is difficult to know what is important or not. svn cleanup doesn't
say much about what it does.

There are also Debian specific problems: in a huge upgrade, the user
doesn't necessary notice that a new major version (with significant
changes and regressions) of some software is installed, unless this
is announced in NEWS.Debian (it usually is, but it wasn't for 1.7).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 documented (I'm wondering how many users know that);
  2. this isn't automatic.
  
  About (2), svn could warn the user when a cleanup could be needed.
  I don't know what is the best solution.
  
  I've reported a bug on the Debian BTS about that:
  
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731769
 
 Where is the point in filing bugs with Debian about that?
 Are they going to do anything else than tracking related
 bug entries upstream?

Yes, sometimes they do. For instance, the change (which is some kind
of regression) could be announced in NEWS.Debian to make the user
aware of it (for new features, pointing to the release notes should
be sufficient). An optional cron script to check the working copies
could be useful too.

 There already is http://subversion.tigris.org/issues/show_bug.cgi?id=4071
 
 Would you like to submit a documentation patch, for example to
 the svnbook? See http://svnbook.red-bean.com/

First, svn help cleanup currently says:

cleanup: Recursively clean up the working copy, removing locks, resuming
unfinished operations, etc.

I suggest to change it to something like:

cleanup: Recursively clean up the working copy, removing locks, resuming
unfinished operations, removing unreferenced pristines, etc.
In 1.7, we recommend to run svn cleanup periodically to reduce the size
of the working copy.

I've attached a patch for the svnbook (not tested).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Index: ch02-basic-usage.xml
===
--- ch02-basic-usage.xml(revision 4563)
+++ ch02-basic-usage.xml(working copy)
@@ -2892,6 +2892,21 @@
 
 /sect2
 
+!-- === --
+sect2 id=svn.tour.cleanup.size
+  titleReducing the Size of a Working Copy/title
+
+  paraSubversion 1.7 does not automatically remove pristines
+that are no longer referenced. As a consequence, a working
+copy can grow up to several times the size that is really
+needed. We recommend to run commandsvn cleanup/command
+periodically in order to claim back the disk space of
+unreferenced pristinesfootnoteparaSee ulink
+url=http://subversion.tigris.org/issues/show_bug.cgi?id=4071;
+/ for details./para/footnote./para
+
+/sect2
+
   /sect1
 
   !-- = --

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

[Vincent Lefevre]

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 size). A svn cleanup solves
  the problem, but
  1. this isn't documented (I'm wondering how many users know that);
 
  It's documented in the 1.7 release notes.
 
  http://subversion.apache.org/docs/release-notes/1.7#wc-pristines
 
  2. this isn't automatic.
 
  Yes, that's a known bug that we need to fix someday.
 Btw it's not a bug for some use cases: Subversion doesn't download
 files if user switches to branch and then back to trunk. Which is very
 useful in some scenarios.

On machines with sufficient disk space, I agree that this can be
useful.

I suppose it is also the case when doing svn up -rsome_rev if the
pristines of some_rev have been kept.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Vincent Lefevre]

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 locales, the language is not controlled
by the LC_* environment variables with the glibc (at the top level).

  FYI, some other VCS such as git or Mercurial don't have such problems
  of broken working copies if the locale changes, at least under Unix,
  probably because they regard a filename just as a sequence of bytes.
  The byte-sequence interpretation under Unix is a problem introduced by
  Subversion, currently out of the scope of the POSIX API.
 
 Those version control systems have a massive problem with
 interoperability across platforms where file name encodings differ and
 file names are anything but the ASCII subset. Subversion has mostly
 avoided that problem for the last 10+ years.

Such problems are avoided with some drawbacks. But under Unix, there
are no problems at all.

 If you want to propose a different way of solving it, please stop
 telling me that we should change everything about file name translation
 and instead post to the dev@ list and propose a solution that will work,
 backward-compatibly, without breaking current working copies. And note
 that store the encoding in the working copy metadata is not such a
 solution (see above under works and backward-compatibly).

There's absolutely no reasons why it wouldn't work. And it's backward
compatible with existing working copies because the encoding would be
stored only on new checkouts (optionally) or when the user explicitly
requests it.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Vincent Lefevre]

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
  cp: missing file operand
  Try 'cp --help' for more information.
 
  A script that needs to work in some well-defined way, in particular
  with English messages (if they need to be parsed), must use the C
  (or POSIX) locale. With most tools, this is fine as they don't need
  to know how filenames are encoded.
 
 Frankly I'm not interested in portable scripts.

You may not be interested, but there are users who are.

 All you're showing above is that on your particular system, setting
 LANG=C.UTF-8 doesn't do anything. So perhaps you'll have to use
 LC_CTYPE=UTF-8, LANG=en_US.UTF-8,

No, even LC_ALL=en_US.UTF-8 cp doesn't have any effect.

 or whatever happens to work on your particular flavour of Unix-like
 OS.

What is needed: LANG=C or LC_ALL=C, but that's not UTF-8, hence
problems with Subversion.

A workaround that can work: LANG=C, LC_CTYPE=C.UTF-8, and unset
all the other LC_* environment variables. And make sure that if
the program has output to a terminal, then either the charmap
was UTF-8 at the beginning or redirect all output so that the
terminal won't get UTF-8 (otherwise some output bytes can trash
the terminal). It's still a problem for interactive use of the
svn command from a shell (unless wrappers are used to convert
stdout and stderr... with known synchronization problems due to
different buffering behavior though svn may not be affected).

 All this is beside the point. The point is that it it not up to
 Subversion to invent a new way of dealing with file-name encodings.

Well, Subversion did invent one. Most programs don't have to deal with
filename encodings; in particular, using LC_ALL=C isn't much a problem
to deal with filenames with top-bit-set bytes. For instance, doing a
mv dir1/* dir2 will work in any locale, even if dir1 has filenames
with top-bit-set bytes. Then you have GNOME applications that assume
that every filename is encoded in UTF-8, whatever the default locale
for the user. Then you have Subversion that assumes that filenames are
encoded in the current locale, breaking simple things like svn up if
the user has changed the locale.

 We use setlocale(LC_ALL, ), this is the API that POSIX gives us
 and there is no other that I'm aware of.

But POSIX does not say that filenames should be considered to be
encoded with the corresponding charmap on the disk. For POSIX, a
filename remains a sequence of bytes. Any interpretation of these
bytes is unspecified.

 And we're certainly not going to break every working copy in
 existence by changing the way we transcode file names on Unix
 (except Mac OS, which is always UTF-8 anyway).

I'm certainly not asking to break every working copy in existence.
I'm just asking for an *option* to allow Subversion to remember the
encoding that was used at the creation of the working copy, and use
this information in subsequent operations. Or something similar.

Note that:

* Users who always use the same locale (at least the same charmap)
  wouldn't be affected at all, whether they use such an option or
  not.

* For users affected by locale change (either explicitly by the user
  or in more hidden ways, e.g. because the user has logged in from a
  different machine, whose terminal uses a different charmap):

  - With the current behavior of Subversion (or if the user doesn't
use the proposed option), the working copy is regarded as broken
by Subversion if some filenames have non-ASCII characters.
A write operation such as svn up will break it even more.

  - With the proposed option, the working copy wouldn't break, e.g.
svn st and svn up would be fine.

FYI, some other VCS such as git or Mercurial don't have such problems
of broken working copies if the locale changes, at least under Unix,
probably because they regard a filename just as a sequence of bytes.
The byte-sequence interpretation under Unix is a problem introduced
by Subversion, currently out of the scope of the POSIX API.

 I'll also point out that if you /need/ consistent, parseable output in
 scripts, the command-line client already provides an --xml flag.

Not all svn commands have a --xml flag. For instance:

$ svn up --xml
Subcommand 'update' doesn't accept option '--xml'
Type 'svn help update' for usage.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Vincent Lefevre]

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 let the user choose. LC_CTYPE typically
specifies the encoding used by the *terminal*, and this encoding may
change when the user connects by SSH from a terminal with a different
encoding.

 I posit that if the native encoding is supposed to be UTF-8, then it
 is an error to use LANG=C at all. Instead, one should use LANG=C.UTF-8.

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
cp: missing file operand
Try 'cp --help' for more information.

A script that needs to work in some well-defined way, in particular
with English messages (if they need to be parsed), must use the C
(or POSIX) locale. With most tools, this is fine as they don't need
to know how filenames are encoded.

 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, for Subversion to
 assume it can just write UTF-8 to disk.

Users who want UTF-8 on disk could choose UTF-8 in a config file.
Users who want Big5 on disk could choose Big5 in a config file.
There should also be a way to have ASCII encoding (like what is
done for URL's), for users who want things to work in every context
with the possibly-minor drawback of having some filenames that are
hardly readable with basic tools.

 So indeed, this state of affairs puts the burden of setting up their
 locale correctly on users, but that's simply the way Unix works.

No, according to POSIX, a filename just consists of a sequence of
bytes. How to interpret it is what *you* choose.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Vincent Lefevre]

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 encodings on their filesystems.
However different terminals with different encodings may be used
(this may be less and less the case thanks to laptop computers,
though). There's also the question of portable scripts (see my
other post)...

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Vincent Lefevre]

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 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 let the user choose. LC_CTYPE typically
  specifies the encoding used by the *terminal*,
 
 No, it determines the character set used by various standard C library
 functions that deal with (usually single-byte) characters.

No, how C library functions behave depend on the current locale,
which is C by default. A program needs to call setlocale() to
change the current locale. Obviously it must not do that blindly:
a program may need to deal with different encodings and so on...

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Vincent Lefevre]

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, for Subversion to
  assume it can just write UTF-8 to disk.
 
 Users who want UTF-8 on disk could choose UTF-8 in a config file.
 Users who want Big5 on disk could choose Big5 in a config file.
 There should also be a way to have ASCII encoding (like what is
 done for URL's), for users who want things to work in every context
 with the possibly-minor drawback of having some filenames that are
 hardly readable with basic tools.
[...]

Actually I think that the encoding needs to be stored somewhere in the
working copy. Otherwise even if the user never changes the encoding,
problems may occur, and this is also true with the current behavior.
Indeed it was said in the past that USB keys were supported. So, move
a USB key to a different computer, where the encoding specified by the
environment is different... and see what happens if you try to do an
svn update...

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

[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,
  problems may occur, and this is also true with the current behavior.
  Indeed it was said in the past that USB keys were supported. So, move
  a USB key to a different computer, where the encoding specified by the
  environment is different... and see what happens if you try to do an
  svn update...
 
 Simply storing the encoding doesn't really solve anything. Sure, it
 remembers the LC_CTYPE value as the time the working copy was created.
 But then... what?

At least it would work better. And in some cases, one wouldn't notice
any problem. For instance, a repository (and therefore the corresponding
working copies too) may contain mostly filenames with only US-ASCII
characters, and when moving a USB key to another computer, one may be
interested only in a part of the working copy with such filenames.

 We also need to specify some new behaviour that increases user
 convenience for such a new feature to have any value.
 
 For this, we need answers to questions like:
 How can the client detect whether the stored encoding name matches
 the on-disk encoding? What does it do when they differ? How can users
 re-encode filenames in the working copy when on-disk encoding has changed? 

I don't understand what you mean here. If the chosen encoding for the
filenames is stored in the working copy: The on-disk encoding has been
chosen by Subversion (at checkout time). So, initially it matches the
stored encoding. This normally doesn't change... unless the user has
explicitly chosen to re-encode the filenames globally with some tool.
In such a case, the user also needs to modify the stored encoding, and
Subversion can provide a command for that. Subversion can also provide
a command to re-encode the filenames of a working copy and update the
stored encoding.

The main problem is when a working copy is moved to another machine,
on which the chosen encoding is not supported on the new machine. But
I don't think Subversion can do anything about it. The user needs to
make sure that the chosen encoding is supported on the new machine.
This should be the case for ASCII (+ escaping mechanism) and UTF-8.

 I'm very much interested in enhancements in this area, but at this
 point we don't need to rehash all the problems there are. We need
 to design solutions. This discussion needs a change of direction towards
 being more constructive, or it will die with no results. The discussion
 is also increasingly off-topic for the users@ list.
 
 In other words, I'm happy to continue this discussion on the dev@ list
 and review your proposed design specs and patches there.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Vincent Lefevre]

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 Windows 7 do if I copy files to FAT
 formatted USB stick? How does cp behave on a different, ext4 formatted
 USB stick on two different linux distributions? Both don't look into
 svn working copies, if cp doesn't, shouldn't svn do the same as cp
 whatever it is doing?

AFAIK, cp is a low-level command that just assumes, like standard
C library functions, that a filename is a sequence of bytes. That
is, it assumes that it is up to the user to re-encode the filenames
if need be. Then, if the bytes need to be interpreted (e.g. for FAT
I assume), it is a driver issue. I suppose that the driver expects
the encoding chosen at mount time (UTF-8 by default?), which it'll
convert to UTF-16 on the physical support.

So, I think that a user who wishes to use FAT under Linux, then
transfer to Windows would do the following:

1. Under Linux, he will do the check out using the UTF-8 encoding,
   so that the driver correctly translates the characters to UTF-16.

2. Whatever locales are used, Subversion would always use UTF-8
   (encoding specified in the working copy) for filenames, so that
   everything is fine on the physical support.

3. The user puts the USB stick on a Windows machine, which recognizes
   UTF-16. I don't think that Subversion needs to cope with the
   chosen encoding under Windows.

For ext4 formatted USB sticks between two Linux machines, the chosen
encoding stored in the working copy would tell Subversion how to
interpret filenames from the working copy.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Paths, base revision and symlinks

[Vincent Lefevre]

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, how is path/to/file resolved? And path/to/file@rev,
where rev is a numeric value, BASE or HEAD?

The Subversion book just says: Locate item in the revision identified
by PEG-REV [or OPERATIVE-REV].

But how is the item identified, e.g. when symlinks are involved? And
what is the BASE revision (when this is the implied reg revision) in
a mixed-revision working copy? The specification should cover every
case of the example given below.

With usual commands, a path is resolved according to the local system
rules (under GNU/Linux, given by the path_resolution(7) man page).
But svn doesn't behave that way, and I think this is bad when a peg
revision isn't provided (i.e. when one just has a standard path).

This could seem a bit particular and complex, but after an upgrade
from 1.6.17 to 1.7.5, there is an annoying practical consequence:
symbolic links (whether they are versioned or not) to directories
in the working copy (except the root) are no longer followed.

Here's an example with various tests:


#!/bin/sh

set -x

mkdir my-test-svn || exit
cd my-test-svn

svnadmin create svn
svn co file://`pwd`/svn wc
cd wc

mkdir -p dir1 dir2/dir2b
echo data1  dir1/file
echo data2  dir2/dir2b/file
svn add dir1 dir2
svn ci -m 'dir1 and dir2'

svn rm dir2/dir2b
ln -s ../dir1 dir2/dir2b
cat dir1/file
svn cat dir1/file
cat dir2/dir2b/file
svn cat dir2/dir2b/file

rm dir2/dir2b
svn ci dir2 -m 'dir2 update'
ln -s ../dir1 dir2/dir2b
cat dir2/dir2b/file
svn cat dir2/dir2b/file

echo new  dir1/file
svn ci dir1 -m 'new dir1/file'

cat dir1/file
svn cat dir1/file
cat dir2/dir2b/file
svn cat dir2/dir2b/file

for i in . dir1 dir2 dir1/file; do svn ls -v $i; done

ln -s dir1/file foo-rel
cat foo-rel
svn info foo-rel

ln -s `pwd`/dir1/file foo-abs
cat foo-abs
svn info foo-abs

ln -s `pwd` bar
svn info bar
svn cat bar/dir1/file

ls -l


I've attached the output.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
+ mkdir my-test-svn
+ cd my-test-svn
+ svnadmin create svn
+ pwd
+ svn co file:///tmp/my-test-svn/svn wc
Checked out revision 0.
+ cd wc
+ mkdir -p dir1 dir2/dir2b
+ echo data1
+ echo data2
+ svn add dir1 dir2
A dir1
A dir1/file
A dir2
A dir2/dir2b
A dir2/dir2b/file
+ svn ci -m dir1 and dir2
Adding dir1
Adding dir1/file
Adding dir2
Adding dir2/dir2b
Adding dir2/dir2b/file
Transmitting file data ..
Committed revision 1.
+ svn rm dir2/dir2b
D dir2/dir2b
D dir2/dir2b/file
+ ln -s ../dir1 dir2/dir2b
+ cat dir1/file
data1
+ svn cat dir1/file
data1
+ cat dir2/dir2b/file
data1
+ svn cat dir2/dir2b/file
data2
+ rm dir2/dir2b
+ svn ci dir2 -m dir2 update
Deleting   dir2/dir2b

Committed revision 2.
+ ln -s ../dir1 dir2/dir2b
+ cat dir2/dir2b/file
data1
+ svn cat dir2/dir2b/file
svn: warning: W25: '/tmp/my-test-svn/wc/dir2/dir2b/file' is not under 
version control
svn: E29: Could not cat all targets because some targets are not versioned
svn: E29: Illegal target for the requested operation
+ echo new
+ svn ci dir1 -m new dir1/file
Sendingdir1/file
Transmitting file data .
Committed revision 3.
+ cat dir1/file
new
+ svn cat dir1/file
new
+ cat dir2/dir2b/file
new
+ svn cat dir2/dir2b/file
svn: warning: W25: '/tmp/my-test-svn/wc/dir2/dir2b/file' is not under 
version control
svn: E29: Could not cat all targets because some targets are not versioned
svn: E29: Illegal target for the requested operation
+ svn ls -v .
  0  ?Jun 21 14:04 ./
+ svn ls -v dir1
  1 vlefevre  Jun 21 14:04 ./
  1 vlefevre6 Jun 21 14:04 file
+ svn ls -v dir2
  1 vlefevre  Jun 21 14:04 ./
  1 vlefevre  Jun 21 14:04 dir2b/
+ svn ls -v dir1/file
  3 vlefevre4 Jun 21 14:04 file
+ ln -s dir1/file foo-rel
+ cat foo-rel
new
+ svn info foo-rel
svn: warning: W155010: The node '/tmp/my-test-svn/wc/foo-rel' was not found.

svn: E29: Could not display info for all targets because some targets don't 
exist
+ pwd
+ ln -s /tmp/my-test-svn/wc/dir1/file foo-abs
+ cat foo-abs
new
+ svn info foo-abs
svn: warning: W155010: The node '/tmp/my-test-svn/wc/foo-abs' was not found.

svn: E29: Could not display info for all targets because some targets don't 
exist
+ pwd
+ ln -s /tmp/my-test-svn/wc bar
+ svn info bar
Path: bar
Working Copy Root Path: /tmp/my-test-svn/wc/bar
URL: 

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

[Vincent Lefevre]

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 happens with svn status 
  
  Correct, Subversion does not output these in a sorted order.
 
  but one month ago , svn diff have always same output , now it is
  random , is a bug or regression.
 
 That's the result of a change in the APR hash table implementation.
 Subversion often uses hash order and in the past this was always the
 same for a given set of hash keys.  The new APR implementation means
 that this order is no longer constant.

In Subversion 1.6.x under Debian, it also affects the properties order
in svn dump: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664867
I don't know about Subversion 1.7.x.

As I've said in my bug report:



After the upgrade to libapr1 1.4.6-1, the properties in the svn dump
output are now in a random order. I don't think their order is
specified, but IMHO, they should be in a consistent order to allow
conventional tools like diff, MD5 checking on a dump, rsync[*] and
so on to work nicely.

[*] rsync will still work, but obviously less efficiently.



I had to revert to the previous libapr1 version.

  why the output shouldn't be sorted by name or something else ? 
  or why svn don't have a sort option this is insane . 
 
 It could be done but nobody has done it yet, the APR change is only a
 few weeks old.  Sorting may need to be optional as there is a cost to
 sorting that not everybody would want.

Is this cost noticeable (when done efficiently)?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 think it is unfortunate that Apple broke with the concept that a
   filename is just a string of bytes.
  
  It's also unfortunate that Subversion breaks this concept too. :)
  
  I mean: do a checkout of a repository containing non-ASCII characters
  under Linux. Then change the locales (e.g. ISO-8859-1 - UTF-8). Do
  an update. And see the errors...
 
 I don't agree that this is the same problem. It's a different problem.

I'm not saying that's the same problem, but that Subversion doesn't
regard a filename as a string of bytes.

 Subversion is internally converting path names from the native encoding

If you regard a filename as a string of bytes, there isn't a concept
of native encoding.

 into UTF-8 and sends them to the repository because they are UTF-8-encoded
 there. This way, all encodings used on client systems can be represented
 in the repository. It works fine with client systems that do not support
 UTF-8 natively at all, as long as they use some encoding that iconv
 understands. And this is all happening *within* the application.
 The rules that svn uses to create filenames are clear and consistent.

There aren't consistent, because svn doesn't track the encoding used
to create the filenames. GNOME rules are consistent: the encoding is
always UTF-8.

 They require users not to flip locales willy-nilly, but that's the
 tradeoff with relying on the locale. Locales only support one encoding
 at a time.

Yes, but different processes can use different locales, and this breaks
svn. There's a good reason why locales are set via environment variables
(on POSIX systems) and not globally.

 What apple does is transform the byte sequence behind the
 application's back.

This is not behind application's back, because this is documented in
the API. The application writer should follow the API.

What's more important is that both Mac OS X and svn (e.g. under Linux)
can transform the byte sequence in the *user's* back. For Mac OS X,
this is related to the normalization form, and for svn, this is related
to the locales.

 So the application itself cannot rely on its *own* rules it was using to
 create filenames when it runs again and reads the names back from disk
 because the OS is interfering with these rules. 

I think it's great to have standards, system-wide conventions and things
like that to avoid applications choosing their own rules. So, I wouldn't
blame Mac OS X for that.

Because there are drawbacks to any choice regarding the filenames,
it would be better to make things configurable at the user level,
but hardcoding choices in applications is bad, IMHO.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 work well for applications starting out today.
 but it won't work for Subversion.
 
 Not all operating systems have switched to UTF-8 as the default
 character set yet. ASCII is still the only encoding that works
 everywhere out of the box (especially on the console!).
 E.g. Debian switched to UTF-8 by default for the Etch release in 2008.
 http://www.debian.org/releases/etch/i386/release-notes/ch-whats-new.en.html
 Many unixy systems that aren't Linux have not switched to UTF-8 by
 default, and it is possible that some never will.

Debian still supports non-UTF-8 locales. That's useful when one
connects from a non-UTF-8 terminal with SSH. And that's precisely
why the user may need to use different locales on some machine
(just for consistent terminal I/O).

 Subversion is supposed to be portable across all these platforms and
 more.

Tracking the filename encoding or letting the user choose the filename
encoding wouldn't be against portability.

Also portable scripts need to use LC_ALL=C. And again, this breaks
svn as soon as a filename has non-ASCII characters (even though such
a filename doesn't appear anywhere in the svn arguments).

 I agree that locales aren't the ideal solution to this problem.
 But at least they are standardized by POSIX and can be expected
 to behave the same way everywhere.

Not everything is standardized (e.g. locale names and what they provide
are system specific). And under POSIX, each process can have its own
locale (and change it).

 And they allow Subversion users to say yes, my system supports
 UTF-8, please use it.

But what if the system supports UTF-8, but the terminal doesn't?

 The best solution would be a standardised way of specifying
 filename encoding that works the same on all filesytem types in
 all operating systems. Alas, that doesn't exist :(

When there's no standard, let the user choose (with a good compromise
for the default behavior).

 I don't think the current solution is perfect. But it's a good
 compromise given the circumstances.

It really isn't. Tracking the filename encoding is a must.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

exit status of svn commands

[Vincent Lefevre]

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 sense in case the file was added. Ditto for
svn status: the user may want to test whether the file is in
base but has been removed with rm, for instance. But I wonder
whether the 0 exit status is correct when not in a working copy.

There has already been a too short discussion about this:

  http://svn.haxx.se/users/archive-2006-03/0918.shtml

and there doesn't seem to be an entry in the issue tracker.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

SVN_SSH and arguments

[Vincent Lefevre]

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

  ssh = /home/user/scripts/ssh -i /home/user/.ssh/id_rsa-svn

to the .subversion/config file and it works as expected.

Nokia-N900-02-8:~ svn --version
svn, version 1.6.16 (r1073529)
   compiled May 22 2011, 02:59:15

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.apache.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: SVN_SSH and arguments

[Vincent Lefevre]

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 script, and as zsh sources the .zshenv
file, the SVN_SSH variable gets rewritten before the real svn is
called. :(

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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!
 
 No, not wrong, but totally correct - especially, if you need to parse the
 output in some script, you (kinda) MUST set the locale to some value,
 that you know. Leaving it in a undefined state is no good at all.

No it is wrong because the above script may send non-printable
characters to the terminal, such as control sequences. Such
control sequences can wreck the terminal and depending on its
configuration, send the contents to a printer.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 to some
 predefined value. Omiting this is just plain wrong. You're suggesting
 that this should be omitted.

No, I'm not suggesting that it should be omitted. The environment
variables should be set *only* if the output is captured. So, it must
be done only in the script that will call svn, not by definining some
general svn wrapper.

Moreover, for portabability reasons, only C or POSIX is guaranteed
to work. In particular, en_US.preferred charset (what has been
suggested) is incorrect on Maemo 4, where only en_US exists. But
svn will not use UTF-8 with the C/POSIX locale.

So, really, svn should provide an option that will select a UTF-8
locale.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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:
   
 ~/bin/mysvn:
  #!/bin/sh
  env LC_CTYPE=en_US.preferred charset svn update
   
Wrong, wrong, wrong! Security hole!
 
 ... in your terminal.

Stop saying nonsense. What you proposed is wrong. The locale must
match the settings of the terminal. Period.

  No it is wrong because the above script may send non-printable
  characters to the terminal, such as control sequences. Such
  control sequences can wreck the terminal and depending on its
  configuration, send the contents to a printer.
 
 Use a terminal that does not have security holes.

In general, one doesn't know that there is a security hole until is
it discovered. In the case of xterm, this has eventually been fixed
(after I reported the bug). But filtering non-printable characters
before sending them to the terminal should be done by the application.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 pre-recorded
 value at update time (not sure what your idea is about all the other
 subcommands).
 
 But I don't think having two sources for this information is a good idea.

In any standard Unix system, the locale is process-dependent.
So, anyway, if you consider the locale, the source can change
from one call to another. So, considering the locale only is
definitely not a good idea.

 So I think Subversion should continue trusting users with setting
 their locale. It's simple. It works.

No, it doesn't work. If the locale changes (what is allowed on
any standard Unix system), a svn up breaks the working copy.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 that different platforms may use different UTF-8 encodings
  for the same filename.
 
 Huh? There's only one UTF-8 encoding for each Unicode code point. Are
 you thinking of code pages?

Michael means that there are several ways to represent a same
string (from a semantic point of view). There are two normalized
representations: NFC and NFD. While Linux does not try to normalize
filenames (they are just viewed as a sequence of bytes[*]), Mac OS X
(at least with HFS+) requires that the filenames are valid UTF-8
strings (even in non-UTF-8 locales) and normalize them to NFD for
storing them on disk.

[*] The locale doesn't matter, and top-bit-set bytes are allowed and
can be handled even in ASCII-based locales.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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. Unacceptable.
   
   No, we leave users a choice.
  
  The choice doesn't work.
 
 It doesn't work for your twisted requirement of having a program
 running in the C locale use UTF-8. Otherwise it works fine.

Many programs are able to use UTF-8 in a C locale, such as programs
that handle XML or any file format based on UTF-8.

Also, if Subversion needs a UTF-8 locale for handle UTF-8 data, why
wouldn't there be an option to do that?

  No, this is not *my* idea. Please read the thread again. I proposed to
  leave the choice by storing the charset chosen by the user in the .svn
  directory (or whatever mean following future WC formats). But you
  didn't want this solution.
 
 It's not a solution because storing the information in wc meta-data
 does not fix anything. What is Subversion supposed to do with filenames
 that come down from the repository during an update, but cannot be
 represented in the recorded charset?

Throw an error. But if the user has chosen UTF-8 as the recorded
charset, this won't happen.

 Using UTF-8 instead of the recorded charset is out of the question.
 That leaves erroring out as the only option. So how is that
 different from the current situation?

With the current situation, a svn up run under the non-UTF-8 locale
will either fail or corrupt the working copy if some filenames have
non-ASCII characters. With UTF-8 recorded as the encoding for
filenames, svn up will always work. See the difference?

 There is a clearly defined way of letting Subversion know which
 charset to use. Set the locale. If you have to, set Subversion's
 locale to something other than what locale your terminal uses.
 
 ~/bin/mysvn:
  #!/bin/sh
  evn LC_CTYPE=en_US.preferred charset svn update

Wrong, wrong, wrong! Security hole!

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 copy always the same locale for all
 tools, so all filenames look same.

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 (for shell sessions),
one gets inconsistencies.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 from 'UTF-8' to native 
   encoding
  
  which is bad and prevents users from writing POSIX-conforming scripts
  using svn, i.e. under the POSIX locale (except on systems where the
  POSIX locale uses UTF-8, but I don't know any).
 
 There's no reason your script could not configure a UTF-8 locale if that
 is needed to represent filenames which exist in the repository.

Configuring a UTF-8 locale can yield non-portable behavior.
There's a good reason why various scripts do a LC_ALL=C.

Moreover there's no portable way to select a UTF-8 locale.

And the POSIX API doesn't need a UTF-8 locale to handle filenames
with top-bit-set bytes.

 We agree on the point that Subversion should use a single character
 set for all filenames in the same working copy.
 Because how should Subversion behave if some filenames convert fine to
 the current character set, and some do not? E.g. what if my encoding
 configuration setting is en_US.ISO8859-1? Should Subversion use ISO8859-1
 for some filenames, and UTF-8 for those which cannot be represented in
 ISO8859-1? That gets really confusing.
 
 It seems that this conversation leads to the question of why Subversion
 even bothers with checking the locale at all. It might as well always
 create filenames in UTF-8, and leave the user with apparently mangled
 filenames if they don't use a UTF-8 locale.
 
 But that isn't a solution either, because now you have lots of
 non-UTF-8 users complaining that Subversion cannot represent their
 filenames properly, where previously it worked fine.

That's why I suggested the encoding to be configurable.

  It's not pointless, or at least, something else needs to be done.
  Currently svn up fails to work, and that's a problem.
 
 It doesn't fail if locales are used consistently.

It fails even if locales are used consistently.

 I don't think this problem is specific to Subversion.

I haven't seen such problems with other tools.

 Other tools also suffer from the fact that POSIX doesn't specify a
 standard for defining filename encodings. Maybe we can find a good
 solution by looking around at how other tools handle this.

Most tools just ignore the encoding of filenames.

 However, I'd expect many will just assume that the user wants filenames
 to be encoded according to the current locale.
 If everybody follows this convention, there is no problem, apart from
 user errors during locale configuration.

You're asking the user, and even all users on the system where
the files are shared, to stick with a single locale. This is not
acceptable, this is contrary to POSIX requirements, and is also
a problem for SSH (where the user needs to use the same charset
on both sides). Under these conditions, the only possibility is
to encode the filenames in UTF-8 anyway. So, why not enforcing
that?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 with a file manager, I want my
   filenames to be readable (and renameable). The idea is that usually
   the user uses for one working copy always the same locale for all
   tools, so all filenames look same.
  
  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.
 
 You might as well argue that Subversion's solution works well but
 GNOME's solution does not.

That's wrong. GNOME let's me to use any locale in shell sessions.
Subversion doesn't.

  So, if the user uses ISO-8859-* locales (for shell sessions),
  one gets inconsistencies.
 
 So don't use GNOME if you don't want your filenames encoded in UTF-8,

I meant: one gets inconsistencies between GNOME and Subversion.

 or don't use a non-UTF-8 locale when working with files you want to
 use from GNOME. Problem solved.

You're forcing the user to use a UTF-8 locale. Unacceptable.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 (for shell sessions),
  one gets inconsistencies.
 
 Just curious - why should a user do that (on purpose) in the first
 place, if he has to deal with filenames which are UTF-8 encoded?

The user may need to do that (terminal limitations, remote
connection...), while he (the user) does *not* deal with
filenames with non-ASCII characters (such as in svn up).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 locale,
you get this error: svn: Can't convert string from 'UTF-8' to native 
encoding
   
   which is bad and prevents users from writing POSIX-conforming scripts
   using svn, i.e. under the POSIX locale (except on systems where the
   POSIX locale uses UTF-8, but I don't know any).
  
  There's no reason your script could not configure a UTF-8 locale if that
  is needed to represent filenames which exist in the repository.
 
 Configuring a UTF-8 locale can yield non-portable behavior.
 There's a good reason why various scripts do a LC_ALL=C.
 
 Moreover there's no portable way to select a UTF-8 locale.

Actually, some UTF-8 locales may not give the expected behavior,
even with svn. For instance, one may want to parse the output of
svn info, and using fr_FR.UTF-8 (if installed) gives localized
output (in French), which would make the parsing fail. And I think
that Do not use svn for scripts, reimplement everything using
bindings. would not be a wise answer.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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. Or any other
non-portable behavior. Who knows...

   There's a good reason why various scripts do a LC_ALL=C.
 
 Then those scripts are written for projects which use ASCII filenames.

That's unspecified.

   Moreover there's no portable way to select a UTF-8 locale.
 
 Then your script will have to deal with the intricacies of supporting
 several platforms when selecting the UTF-8 locale. For most platforms,
 export LC_CTYPE=en_US.UTF-8 should work fine.

Not all. Thus this is bad.

 Well, you can use en_US.UTF-8 to force the output to English.

Wrong. There's no guarantee to work. And too often it doesn't work.

  And I think that Do not use svn for scripts, reimplement
  everything using bindings. would not be a wise answer.
 
 Scripts written against bindings won't break when we change the
 command line output (which happens every once in a while).

It is certainly a better solution, but requires too much work
in practice.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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, while
 the command line tools do not).

The main point is that this is transparent to the user.

  You're forcing the user to use a UTF-8 locale. Unacceptable.
 
 No, GNOME forces the user to use a UTF-8 locale, if ls, rm, cd and
 other command line tools are to show/accept the same name as the
 GNOME file manager.

That's just a minor display problem (not even always a problem).
But ls, rm and cd work fine under non-UTF-8 locales on any file.

 Subversion here simply behaves as any other Unix command line tool,

No, if the user uses a different locale, commands like svn up can
fail. There's no such problem with other Unix tools.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 on everybody unacceptable.

No, this is not *my* idea. Please read the thread again. I proposed to
leave the choice by storing the charset chosen by the user in the .svn
directory (or whatever mean following future WC formats). But you
didn't want this solution.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 /svnroot/mpfr/db
total 468
-rw-rw-r-- 1 www-data scm_mpfr 11 Aug  5 02:26 current
-r--r--r-- 1 www-data scm_mpfr 15 Aug  6 16:01 format
-rw-r--r-- 1 www-data scm_mpfr  5 Oct 24  2005 fs-type
drwxrwsr-x 2 www-data scm_mpfr   4096 Aug  6 16:02 node-origins
drwxrwsr-x 2 www-data scm_mpfr 229376 Aug  5 02:26 revprops
drwxrwsr-x 2 www-data scm_mpfr 229376 Aug  5 02:26 revs
drwxrwsr-x 2 www-data scm_mpfr   4096 Aug  5 02:26 transactions
-rw-r--r-- 1 www-data scm_mpfr  2 Aug  6 16:01 txn-current
-rw-r--r-- 1 www-data scm_mpfr  0 Aug  6 16:01 txn-current-lock
drwxr-sr-x 2 www-data scm_mpfr   4096 Aug  6 16:01 txn-protorevs
-rw-r--r-- 1 www-data scm_mpfr 37 Oct 24  2005 uuid
-rw-rw-r-- 1 www-data scm_mpfr  0 Oct 24  2005 write-lock
vlefe...@ff-scm-prod:~$ ls -l /svnroot/mpfr/db/txn-protorevs/
total 0
vlefe...@ff-scm-prod:~$ svnadmin lslocks /svnroot/mpfr
vlefe...@ff-scm-prod:~$ svnadmin lstxns /svnroot/mpfr
vlefe...@ff-scm-prod:~$ 

The other repositories on the server do not have these txn-*
files/directory. Any idea?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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:
 
 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 /svnroot/mpfr/db
 total 468
 -rw-rw-r-- 1 www-data scm_mpfr 11 Aug  5 02:26 current
 -r--r--r-- 1 www-data scm_mpfr 15 Aug  6 16:01 format
[...]

I notice that the current file hasn't been updated by the upgrade.
It contains:

7052 un bv

while the documentation[*] says:

The format of the current file is:

 * Format 3 and above: a single line of the form
   youngest-revision\n giving the youngest revision for the
   repository.

 * Format 2 and below: a single line of the form youngest-revision
   next-node-id next-copy-id\n giving the youngest revision, the
   next unique node-ID, and the next unique copy-ID for the
   repository.

[*] 
http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 session with
UTF-8 locales and another shell session with ISO-8859-* locales.
Unfortunately the svn client doesn't remember which one was used
in the first place. The consequence is that if the user works
with different locales, things go wrong (even if the user doesn't
execute any command with non-ASCII characters in its arguments).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 uses the locale for filename encoding.

 AFAIK there is no standard mechanism on UNIX for telling a process about
 filename encodings. Filenames are just byte sequences. It's up to the
 application to present the byte sequence to the user in a meaningful way.

Yes, however meaningful depends on what the user expects.

 One way of doing it is using assuming the character set of the current
 locale and hope that this will work. That of course breaks down when people
 try to work with the same set of files in locales using different character
 sets (like latin1 vs. UTF-8). E.g. you can't check out a working copy using
 a UTF-8 locale, and then use it with an svn client in a latin1 locale, and
 expect things to just work, if you have filenames in the repository which
 contain non-ASCII characters.

This is precisely the problem I've mentioned.

 There are extensions in some systems like Linux, where filename encoding
 can be specified at mount time and a process can query this information.
 But the actual encoding of filenames might still differ (e.g. due to user
 error). But more importantly since there is no common standard I don't
 see how you'd solve this problem in a portable way.

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 (with the current WC layout, that would be
some file under the .svn directory), so that the next time the svn
client is used for this WC, the same encoding will be used, avoiding
inconsistencies (such as currently obtained by two svn up under two
different locales).

[*] There are several ways to do that, such as:
1. Use a charset specified by the user in the svn config file.
2. Use the current locale.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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': Permission denied
  
  No problems for read operations.
 
 I suspect you have a hook script that isn't aware of the file format
 changes in 1.5.1. I had this problem with a hook script we use to
 check the size of transactions. Try temporarily disabling your
 commit hooks and see if it starts working.

There is no pre-commit hook.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 (with the current WC layout, that would be
  some file under the .svn directory), so that the next time the svn
  client is used for this WC, the same encoding will be used, avoiding
  inconsistencies (such as currently obtained by two svn up under two
  different locales).
 
 I doubt this can be made to work properly. A feature like that is just
 asking people to shoot themselves in the foot.

I don't see any problem with it. If you want another method, then fine,
but in any case, a command like svn up should not fail just because
it is executed under locales unexpected by the client.

 People simply should not mix character sets like that in their
 working copies.

It seems that you didn't understand what I proposed. My proposal is
just to *avoid* mixing character sets in filenames (contrary to what
svn currently does), i.e. to use a single character set, defined at
checkout time (for instance).

 There should be a project-wide convention about the encoding used for
 filenames, and everyone should be using that encoding

For the repository, of course, but it is already the case: UTF-8.
For working copies, if a single encoding must be defined, it should
be UTF-8 too, in particular to be sure to be able to represent all
the filenames that can occur.

 (unless there
 really is a project-specific need to have filenames in multiple encodings
 for some reason, but that's really rare -- and whoever does this should be
 smart enough to deal with the consequences).
 
 Right now, if the filename cannot be represented in the current locale,
 you get this error: svn: Can't convert string from 'UTF-8' to native 
 encoding

which is bad and prevents users from writing POSIX-conforming scripts
using svn, i.e. under the POSIX locale (except on systems where the
POSIX locale uses UTF-8, but I don't know any).

 The native encoding is determined by the locale, but that does not matter.
 The point is that, wherever encoding configuration happens to come from,
 if the configured encoding cannot represent the character string stored
 as UTF-8 in the repository, what is Subversion supposed to do? It cannot
 really do anything with a filename it cannot represent in the character
 set configured by the user, other than throwing an error.

For filenames stored on disk, they (all of them) can be encoded using
UTF-8. Remember, filenames on a POSIX system are just sequences of
bytes. For what is output to the terminal, non-representable
characters can be displayed by a replacement characters such as ?.
This can still be better than an error.

 The filename conversion to UTF-8 and back must not be lossy. Because
 to uniquely identify a file the client needs to send the same UTF-8 byte
 sequence it got from the server back to the server. And it needs to keep
 doing so for backwards compatibility. This is biting us on Mac OS X by the
 way, because some characters have multiple representations in UTF-8,
 see http://subversion.tigris.org/issues/show_bug.cgi?id=2464

This problem is due to the fact that Subversion doesn't enforce a
canonical representation (either NFC or NFD).

Anyway there would still be problems with case-insensitive filesystems
for instance.

  [*] There are several ways to do that, such as:
  1. Use a charset specified by the user in the svn config file.
 
 That provides no advantage over checking the current locale.

The advantage is that the user doesn't need to remember to use a UTF-8
based locale for the checkout. This would also allow the user to do
checkout by portable POSIX scripts (i.e. with LC_ALL=POSIX).

  2. Use the current locale.
 
 That's what's being done. But we're not writing the information down in the
 working copy meta data, and doing so is quite pointless as described above.

It's not pointless, or at least, something else needs to be done.
Currently svn up fails to work, and that's a problem.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Support for filesystem snapshots (?)

[Vincent Lefevre]

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) pristine?
 
 (c) is great
 (b) is ok
 (a) means the operations are not transactional
 
 Further:
 
 (c) snapshots work
 (b) snapshots work, but need a cleanup after restore
 (a) snapshots don't work; repository is not transactional, either

I don't see how (c) could be possible, as a commit requires
several filesystem operations (even for updating current).
Of course, (b) + automatical clean-up could look like (c).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Support for filesystem snapshots (?)

[Vincent Lefevre]

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 system level (physically), in particular with NFS. FYI, the
fflush(3) Linux man page says:

NOTES
  Note that fflush() only flushes the user space buffers provided by the
  C library.  To ensure that the data is physically stored on  disk  the
  kernel  buffers  must  be  flushed  too,  for example, with sync(2) or
  fsync(2).

But even sync() may not be sufficient:

BUGS
  According  to  the standard specification (e.g., POSIX.1-2001), sync()
  schedules the writes, but may return  before  the  actual  writing  is
  done.   However, since version 1.3.20 Linux does actually wait.  (This
  still does not guarantee  data  integrity:  modern  disks  have  large
  caches.)

Ditto for fsync:

  If  the  underlying hard disk has write caching enabled, then the data
  may not really be on permanent  storage  when  fsync()  /  fdatasync()
  return.

 Therefore, the application should make no assumption about whether
 the data has been written through to its final media. What is
 critical is that (a) everything gets flushed, then (b) current is
 updated, then (c) current is flushed.

I don't think this can be guaranteed just by looking at the application
code. Only the kernel and the filesystem implementation can document
whether the system calls are taken into account as expected.

Note: using fcntl locking (possibly in addition to other methods) can
also be useful.

[...]
 All of this can get thrown out the window if the server decides to
 lie. See http://nfs.sourceforge.net/nfs-howto/ar01s05.html,
 section 5.9, where it describes how the Linux async NFS export
 option can cause the NFS server to lie when asked to fsync or
 flush-on-close. The problem here is that the server might keep the
 revs (part 1) in cache, while writing out the current file (part 3),
 leaving a corrupted repository if the server fails. So, this is a
 problem in general, not specific to filesystem snapshots.

Yes.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Support for filesystem snapshots (?)

[Vincent Lefevre]

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 from file system
  crashes, either, which is arguably a bug in Subversion.
 
 Subversion carefully flushes file buffers after writing revision files.

What do you mean by flushes file buffers? A call to fflush()?
Or a call to sync() or fsync() too?

Assuming the filesystem is on a remote machine (say, NFS), the
necessary needs to be done on the client side: the NFS server
cannot take into account the kernel-level buffers of the client.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Support for filesystem snapshots (?)

[Vincent Lefevre]

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 exactly: in case of a power loss or a kernel crash, the file
system can become inconsistent. I think you mean something like:
[...] that lost power or crashed while it wasn't writing to the
disk.

 The fsync's are going to be the critical thing for ordering
 operations at the disk level, however there is no guarantee how much
 of the fsync operation might have completed when a crash or snapshot
 happens.

It depends on whether the filesystem snapshot software takes kernel
buffers into account or not. And one can assume that the snapshot
isn't taken in the middle of a fsync.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Support for filesystem snapshots (?)

[Vincent Lefevre]

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? A call to fflush()?
  Or a call to sync() or fsync() too?
 
  Assuming the filesystem is on a remote machine (say, NFS), the
  necessary needs to be done on the client side: the NFS server
  cannot take into account the kernel-level buffers of the client.
 
 Subversion calls apr_file_flush(). What that does on which platform
 depends on APR (and could theoretically change over time).
 
 I'm not sure what else you suggest we should do to avoid the (from
 my point of view non-existent) bug you were talking about.

Well, not flushing the buffers at some low level is not necessarily
a bug. But in such a case the user has to accept the consequences,
such as a filesystem snapshot not providing a consistent state of a
Subversion repository.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Avoiding the svn: Write error: Broken pipe error messages

[Vincent Lefevre]

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.

Note: for those who use localized messages, the script needs to
be modified accordingly.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
#!/bin/sh

# svn wrapper to avoid svn: Write error: Broken pipe error messages
# when piping the svn output to some command.
#
# Caveat: if svn fails, its exit status is lost. However this script
# will generally be used in an interactive way before a pipe (where
# the user doesn't have a direct access to the exit status), and the
# user can still look 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
  test -z $brpipe || kill -PIPE $$
}

{ svn $@ 21 3 3- | filter 2 3-; } 31

# $Id: svnwrapper 38281 2010-07-30 13:34:46Z vinc17/ypig $

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

[Vincent Lefevre]

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.
 
 Note: for those who use localized messages, the script needs to
 be modified accordingly.

Here's a new version (attached). The previous script had a freezing
problem when a background process was started via $SVN_SSH. The
method used to solve this problem also allowed me to solve the
exit status problem.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
#!/bin/sh

# svn wrapper to avoid svn: Write error: Broken pipe error messages
# when piping the svn output to some command.
#
# Note: the svnwrapper:term trick prevents this script from freezing
# if svn starts a background process via $SVN_SSH (e.g. ssh -fMN ...
# for connection sharing) that still has its stderr connected to the
# pipe after svn terminates. It also allows the script to propagate
# the exit status of svn when there is no broken pipe.
#
# Script written by Vincent Lefevre vinc...@vinc17.net in July 2010,
# released in the public domain.

filter()
{
  unset brpipe status
  while read err
  do
case $err in
  svnwrapper:term:*)
status=${err#svnwrapper:term:}
break ;;
  *Write\ error:\ Broken\ pipe) brpipe=1 ;;
  *) printf %s\n $err ;;
esac
  done
  test -z $brpipe || kill -PIPE $$
  exit $status
}

{
  { svn $@ 21 3 3-; echo svnwrapper:term:$?; } | filter 2 3-
} 31

# $Id: svnwrapper 38299 2010-07-30 17:30:17Z vinc17/ypig $

Re: problem with peg revision

[Vincent Lefevre]

On 2010-03-25 13:06:56 -0400, David Weintraub wrote:
 I played around with svn info and pegged revisions, and had no
 problems. Have you've looked at the svn log? That might be a place to
 start and maybe help you understand when the name change took place.

The file name never changed.

 One of the issues our users run into when specifying pegged revisions
 is that they misstate the revision.
 
 Let's say I removed directory foo and committed a new revision
 10002. When you look at the svn log, you see that revision 10002 is
 where I removed foo.
 
 Sometimes my developers will do something like this:
 
 $ svn info f...@10002
 
 and get the message that they used an invalid URL. I point out that in
 this case, they need the revision BEFORE 10002:
 
 $ svn info f...@10001
 
 works.
 
 Could there be something like that going on here?

No.

But it seems that my problem is a known limitation:

  Verify that the object's location (path-wise) in PEG-REV is the same
  as it is in OPERATIVE-REV. If that's the case, at least the two
  locations are known to be directly related, so perform the requested
  action on the location in OPERATIVE-REV. Otherwise, relatedness was
  not established, so error out with a loud complaint that no viable
  location was found. (Someday, we expect that Subversion will be able
  to handle this usage scenario with more flexibility and grace.)

This is the latter case.

One problem is that it seems to be impossible to specify an object
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. For instance:
 
  $ svn info notes
  Path: notes
  Name: notes
  URL: svn+ssh://mysvn/arith/stds-754/notes
 ^
  Repository Root: svn+ssh://mysvn
  Repository UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
  Revision: 35831
  Node Kind: file
  Schedule: normal
  Last Changed Author: lefevre
  Last Changed Rev: 19957
  ^
  Last Changed Date: 2007-11-20 13:37:18 +0100 (Tue, 20 Nov 2007)
  Text Last Updated: 2010-01-04 19:18:16 +0100 (Mon, 04 Jan 2010)
  Checksum: 06585f431d7af5737b91dcfacd4e7f6d
 
  $ svn info -r19957 notes
 ^
  Path: notes
  Name: notes
  URL: svn+ssh://mysvn/doc/fp/stds-754/notes
 ^^
  Repository Root: svn+ssh://mysvn
  Repository UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
  Revision: 19957
  Node Kind: file
  Last Changed Author: lefevre
  Last Changed Rev: 19957
  Last Changed Date: 2007-11-20 13:37:18 +0100 (Tue, 20 Nov 2007)
 
  $ svn info no...@19957
 ^
  no...@19957:  (Not a valid URL)
 
  svn: A problem occurred; see other errors for details
  zsh: exit 1     svn info no...@19957

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Distributed Subversion Repositories

[Vincent Lefevre]

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 validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Distributed Subversion Repositories

[Vincent Lefevre]

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
 http://flavio.castelli.name/howto_use_git_with_svn
 
 Then you don't have to worry about manually commiting back to Subversion
 ...

But do they support properties?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)