RE: is it necessary to svnsync copy-revprops all reversions everytime executing svnsync?

[Bert Huijben]

No,

 

Just using svnsync will handle copying revprops while synchronizing
revisions just fine. 

 

But revprops may change later if you enable that option in your repository,
so if you use svnsync to keep two repositories completely synchronized you
might want to use this feature to sync those changes.

 

  Bert

 

From: Keva-Slient [mailto:356730...@qq.com] 
Sent: vrijdag 20 april 2018 14:48
To: users 
Subject: is it necessary to svnsync copy-revprops all reversions everytime
executing svnsync?

 

is it necessary to svnsync copy-revprops all reversions everytime executing
svnsync?

RE: File not accepted as valid addition to svn

[Bert Huijben]

> -Original Message-
> From: Bo Berglund [mailto:bo.bergl...@gmail.com]
> Sent: maandag 12 februari 2018 18:42
> To: users@subversion.apache.org
> Subject: Re: File not accepted as valid addition to svn
> 
> On Mon, 12 Feb 2018 15:54:00 +, Philip Martin
>  wrote:
> 
> >Bo Berglund  writes:
> >
> >> svn add Fasadändring
> >> svn: warning: W155010: 'D:\Bosse\Fasadändring' not found
> >
> >'&' has special meaning to the shell and needs to be quoted or escaped.
> 
> I always thought that this was the case only for Linux, since & is a
> perfectly valid part of a file name on Windows...
> But I will refrain from such characters in paths in the future.

F:\>echo q
q
'r' is not recognized as an internal or external command,
operable program or batch file.

F:\>


It is a separator between multiple operations on the same line. You could
quote the argument with "-characters, which usually just pressing TAB would
do for you on Windows if the file exists. Another option is adding a ^ in
front of the &.

Bert

RE: Searching for a C++ API

[Bert Huijben]

> -Original Message-
> From: Branko Čibej [mailto:br...@apache.org]
> Sent: maandag 29 januari 2018 13:54
> To: users@subversion.apache.org
> Subject: Re: Searching for a C++ API
> 
> On 29.01.2018 11:45, R developer wrote:
> > Hello all,
> >
> > I have been involved in writing a closed source application that among
> > other things maintains a checkout from an SVN repository, the
> > application used to be written in C# so at the moment we are used to
> > SharpSvn. Recently the decision was made to incorporate the
> > functionality into a mobile c++ app (yes, I do wish we could use a
> > different language, but for now that's out of our scope).
> >
> > Is there a C++ library available somewhere?
> > One that can be used in a closed source app and compiles both on
> > Windows and Linux (and preferably other platforms like OSx, iOS, Android).
> > Usage of c++11, boost and/or Qt frameworks is fine as our app already
> > uses them.

It is not a real C++ library, but there might be some code that you can copy 
from the SharpSvn library code for your usage. SharpSvn is C++/CLI, to allow 
operation with the .Net environment, but there is enough plain C++ inside that 
might be able to get you started with the C library. The code is Apache 
licensed so you can mostly use it however you like.

Bert

RE: when will file ./svn/tmp/svn-XXXXXX be created? and why?

[Bert Huijben]

In many cases Subversion will create files there, then write its contents and 
when done move the file to the required location in your working copy. This 
makes sure that you will never see half written files during operations… and by 
that loose valuable information.

 

  Bert

 

From: Keva-Slient [mailto:356730...@qq.com] 
Sent: donderdag 21 december 2017 08:29
To: users ; 王运 <694591...@qq.com>; bluecat 
<690853...@qq.com>
Subject: when will file ./svn/tmp/svn-XX be created? and why?

 

 

we use svn managing our config files. 

 

in client side environment, check out repos in client side, processes could 
open the config file and read or write the config file. some of them could keep 
file handler for a long time.

 

now we get some problems:  the config file will be moved to .svn/tmp directory 
and be deleted. 

 

for example: online_assist process:

online_assist will open some config files in /wns/etc/config/ directory. 
/wns/etc/config/ is a repo.

use losf to see which files online_assist are opening.

 

#lsof |grep online_assist |grep .svn/tmp

704  /wns/sbin/online_assist /wns/etc/config/.svn/tmp/svn-ynboPV (deleted)

704  /wns/sbin/online_assist /wns/etc/config/.svn/tmp/svn-sTknMU (deleted)

704  /wns/sbin/online_assist /wns/etc/config/.svn/tmp/svn-39HEsA (deleted)

 

online_assist should open config files which are not in .svn/tmp directory.

in usual, online_assist should open config files like : 
/wns/etc/config/db/ap_data.db ...

 

#pidof online_assist

704

#ls -l /proc/704/fd/* -l |grep config |sort -k 10

lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/19 -> 
/wns/etc/config/.svn/tmp/svn-39HEsA (deleted)

lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/18 -> 
/wns/etc/config/.svn/tmp/svn-sTknMU (deleted)

lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/15 -> 
/wns/etc/config/.svn/tmp/svn-ynboPV (deleted)

lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/23 -> 
/wns/etc/config/db/china_province_city.db

lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/20 -> 
/wns/etc/config/db/phonelocation.db

lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/16 -> 
/wns/etc/config/wac/data/ouiol.db

lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/21 -> 
/wns/etc/config/wac/data/ouiol.db

lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/17 -> 
/wns/etc/config/wac/data/sta_login_stat.db

lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/22 -> 
/wns/etc/config/wac/data/wti.db

 

some files opened by online_assist in  /wns/etc/config are correct, like 
/wns/etc/config/wac/data/ouiol.db. but some are moved to 
/wns/etc/config/.svn/tmp and deleted.

 

why is this ?

 

why would the file opend by process be moved to .svn/tmp

and

why would the file moved to .svn/tmp be deleted?

 

 

--

.

Vanity...My favourite sin.

--<>

 

RE: Access Violation problem in Code Collaborator tool

[Bert Huijben]

  Hi,

 

You just posted this to a publicly archived mailing list. I would recommend
changing the password you use for this Subversion server now.

 

I can't really tell you what caused this problem, but I would recommend
upgrading your Subversion client first. We (as Subversion project) are no
longer providing patches for Subversion 1.7.7.

 

  Bert

 

From: gopayya.devarako...@dell.com [mailto:gopayya.devarako...@dell.com] 
Sent: donderdag 23 november 2017 14:31
To: users@subversion.apache.org
Subject: Access Violation problem in Code Collaborator tool

 

Dell - Internal Use - Confidential 

 

Hi,

 

PFA, for trouble shooting the problem I am facing in Code Collaborator.

 

Thanks in Advance. 

RE: GitHub svn bridge corrupting working copies

[Bert Huijben]

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: zondag 15 oktober 2017 21:28
> To: Ryan Schmidt 
> Cc: Subversion Users 
> Subject: Re: GitHub svn bridge corrupting working copies
> 
> Ryan Schmidt wrote on Sun, Oct 15, 2017 at 14:00:10 -0500:
> > On Oct 15, 2017, at 13:07, Daniel Shahaf wrote:
> > > Ryan Schmidt wrote on Sun, 15 Oct 2017 12:49 -0500:
> > >> And the problem will just occur again sometime later with a different
> node. The node it complains about is always a directory that someone else
> committed to recently, [...]
> > >
> > > Have you looked at these commits?  Is there anything unusual in them,
> > > e.g., do they involve renames?
> >
> > Nothing unusual; just modifying one file and adding another:
> >
> > https://github.com/macports/macports-
> ports/commit/2198debd25b02bcf7f6b17f79b415690449a85f0
> 
> Okay, so perhaps the problem has to do with revisions that add new
> files.
> 
> > Somehow I don't think specific revisions are the problem. I mean, I
> > can now check out a new working copy at revision 139307 and
> > successfully update it to 139308.  Meanwhile, on our server, once,
> > back in August, it encountered a corruption already halfway through
> > the process of checking out a new working copy. And on the next
> > checkout attempt it worked.
> 
> Indeed, there is little we can do without knowledge of the bridge.
> There is any number of ways in which these observations might be
> confounders.
> 
> > > You might be able to reproduce the problem by backdating your working
> > > copy, 'svn up -r N-1 && svn up -r N kde'.
> >
> > Inside the kde directory, I ran:
> ⋮
> > $ svn up -r 139308
> > Updating '.':
> > UU   kdepimlibs4/Portfile
> > Skipped 'kdepimlibs4/files/patch-do_not_include_cpp.diff' -- An
> obstructing working copy was found
> 
> That's interesting; why would there be an obstruction?
> 
> Maybe a file by this name already existed at some point, and was not
> removed cleanly?
> 
> Or perhaps github reported the 'add' to the client twice?

One probable cause for this would be that they somehow changed the revision 
number to hash mapping. I would hope they change the repository UUID in this 
case, but given how easy it is to change history in git, I wouldn't count on 
this.

Is this problem reproducible on a clean checkout from the same base revision?

Bert

RE: Problem with file name encoding during merge - URL Encoding (Percent Encoding)

[Bert Huijben]

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: vrijdag 6 oktober 2017 16:24
> To: Bartosz Pierzchlewicz ;
> users@subversion.apache.org
> Subject: Re: Problem with file name encoding during merge - URL Encoding
> (Percent Encoding)
> 
> I can't reproduce your problem using a trunk client and httpd-2.4.25 on Linux.
> 
> Is there any http proxy or reverse proxy in your setup?

That could cause some issues. Some specific bad httpd versions or selective 
backports of those 'fixes' could do that too... But I wouldn’t be surprised to 
see some of these issues with Subversion 1.6 or earlier under some specific 
circumstances. We didn't have all these nice url and path helper functions with 
strictly defined behavior in those older releases.

Bert

RE: override global-ignores from server side

[Bert Huijben]

> -Original Message-
> From: Balogh Péter [mailto:balogh.pe...@xcite.hu]
> Sent: dinsdag 19 september 2017 10:59
> To: users@subversion.apache.org
> Subject: Re: override global-ignores from server side
> 
> Hi,
> 
> Yes, I'm aware that adding the .a file manually is possible, but it does not
> solve the issue, that we have to check manually after every library update, if
> a new .a file is added And the issue won't show up, until we commit the
> changes, and the CI build fails with a linking error The default list is not 
> large,
> that's why overriding it does not seem to be an irrational request But right
> now, if I put a .a file in an SVN, I have no way to make it show up in the
> status without client side modifications, and I think it's a really important
> missing feature

Where I work we have a strict policy that we don't release binaries that are 
built on normal workstations, just those on regulated build systems where we 
can 100% reproduce previous builds. Having a default that would make users 
commit locally build artifacts would go against that. We manage these artifacts 
using different tooling that was designed for that purpose.

Bert

RE: override global-ignores from server side

[Bert Huijben]

> -Original Message-
> From: Balogh Péter [mailto:balogh.pe...@xcite.hu]
> Sent: dinsdag 19 september 2017 10:45
> To: users@subversion.apache.org
> Subject: override global-ignores from server side
> 
> Hi,
> 
> I think our use case is not covered even with the recent features in
> subversion By default, for example the .a files are ignored in the svn clients
> Since we're developing mobile multi platform titles, it's common to add
> certain libraries as .a files to the repository Is there a way, to override 
> the
> client's default global-ignores with a repository specific one?

The ignores are only applied to files that are not already added, so in your 
case just adding the files and applying the ignore rule on a system where you 
do want to add these would just work fine. The default list of ignores is not 
that large and you can add items via svn:ignore and svn:global-ignores 
properties on a directory.

Bert
> 
> Best regards,
> Peter

RE: Subversion svn+ssh, sshd 100% CPU

[Bert Huijben]

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: donderdag 14 september 2017 22:10
> To: Matt Simmons 
> Cc: Zoran Petkovic ;
> users@subversion.apache.org
> Subject: Re: Subversion svn+ssh, sshd 100% CPU
> 
> On Wed, Sep 13, 2017 at 7:20 AM, Matt Simmons 
> wrote:
> > On Tue, Sep 12, 2017 at 12:14 PM Zoran Petkovic
> > 
> > wrote:


> Perhaps the windows client and the linux client are performing the checkout
> in a different way for some reason (I'm thinking of the so-called "skelta
> mode" vs. "bulk mode", see http://subversion.apache.org/docs/release-
> notes/1.8.html#serf-skelta-default).

'Skelta vs bulk' is specific to operations over http(s), so this wouldn't apply 
here. The relevant part here is probably which ssh client is used here. On most 
*nix systems this would be openssh, while on most Windows systems I would see 
some putty based tools.

Bert
> 
> --
> Johan

RE: Checksum mismatch bug in 1.8.18

[Bert Huijben]

This specific error message was added in the last release, so yes it is new
in the last versions. The last 1.9.x version also added it and I'm surprised
that you see the error on 1.8 and not 1.9 (or vice versa).

 

It tries to tell you that you have two files with an identical SHA-1 hash,
but different contents. A case that we accidentally didn't catch before,
that might have caused some data loss under extreme circumstances.

 

 

This scenario is pretty unlikely to trigger, unless you specifically try to
do that. I'll try to verify what exactly is in your dump file to see if you
really hit this scenario, or that we have a bug in our code that tries to
catch this scenario. Assuming you properly verified with 1.9.6 (and not
1.9.5 or earlier) I assume that this is a bug in 1.8.18, as other scenarios
are really extremely unlikely.

 

I'm not sure I'll have time to look into this before Monday though, so
perhaps one of the other developers beats me to it.

 

Bert

 

From: David Engel [mailto:den...@magnitude.com] 
Sent: zaterdag 29 juli 2017 00:01
To: users@subversion.apache.org
Subject: Checksum mismatch bug in 1.8.18

 

Hi,

 

I think I'm running into a bug in svnadmin in the latest 1.8 release
(1.8.18).  It is not present in 1.8.17 nor 1.9.5 nor 1.9.6.  I'm guessing
it's related to the recent changes around strict repsharing.  I'm not
subscribed to the mailing list, so please CC me on any responses.

 

Here are the relevant details:

 

OS: Windows 10 and Windows 2012 R2

Subversion release: 1.8.18

Both SlikSVN release:

svnadmin, version 1.8.18-SlikSvn-1.8.18-X64 (SlikSvn/1.8.18) X64

   compiled Jul 17 2017, 13:03:37 on x86_64-microsoft-windows6.2.9200

And Collabnet release:

svnadmin, version 1.8.18 (r1800620)

   compiled Jul  7 2017, 05:51:59 on x86_64-microsoft-windows6.2.9200

 

Performing an svnadmin load results in the following error:

...

<<< Started new transaction, based on original revision 650

 * editing path :
Dev/Common/Utils/External/StampVerData/MetaBuilderVersion.inf ... done.

 * editing path :
Dev/Common/Utils/External/StampVerData/MetaBuilderVersionDBG.inf ... done.

 * editing path :
Dev/Common/Utils/External/StampVerData/OracleVersion.inf ...svnadmin:
E16: SHA1 of reps '-1 0 45 132 a6ea37d29094deece56250ebe167ce46
6a2d6bc4c7e58c0d2627a1b0dd5b23e542aec4d1 650-i2/_8' and '-1 136 45 132
a6ea37d29094deece56250ebe167ce46 6a2d6bc4c7e58c0d2627a1b0dd5b23e542aec4d1
650-i2/_8' matches (6a2d6bc4c7e58c0d2627a1b0dd5b23e542aec4d1) but contents
differ

svnadmin: E160004: Filesystem is corrupt

svnadmin: E200014: Checksum mismatch while reading representation:

   expected:  a6ea37d29094deece56250ebe167ce46

 actual:  5f696f5d0755f3bcb5e927bdfba4bfa8

 

In order to reproduce the error, you can use the attached VersionStamps3
repository dump file.  It was taken with the same version of svnadmin from a
multi-GB repository that's been around for over a decade and pruned
(svndumpfilter) to a small set of files and revisions in one folder while
still encountering the error.  I first encountered the error another place
very quickly in an incremental load on top of a repo that was loaded from
1.8.14, but that one was on a revision north of 120,000+.  This is way
easier to reproduce.  I tried filtering the dump further and dropping empty
revisions, but the error did not occur in those cases.  The error also did
not occur using 1.8.17, 1.9.5., and 1.9.6.  It also did not occur in 1.8.18
if I set enable-rep-sharing = false before performing the load.

 

Repro.bat script:

@echo off

 

:defineCommands

rem You might need to adjust these lines to point to your

rem compiled-from-source Subversion binaries, if using those:

for %%i in (svn.exe) do set SVN="%%~$PATH:i"

for %%i in (svnadmin.exe) do set SVNADMIN="%%~$PATH:i"

 

:defineUrls

rem Only supported access method: file://  . If http:// or svn://,
then

rem you'll have to configure it yourself first.

set URL=file:///%CD%/repos

set URL=%URL:\=/%

echo Base url for repo: %URL%

 

:cleanAllDirsAndCreateRepo

if exist repos rmdir /s /q repos

if exist import-me rmdir /s /q import-me

if exist wc rmdir /s /q wc

%SVNADMIN% create repos

pause

 

:prepareGreekTree

echo Making a Tree for import...

mkdir import-me\Dev\Common\Utils\External

echo Importing it...

cd import-me

%SVN% import -q -m "Initial import." %URL%

cd ..

 

rem This is where your reproduction recipe goes.

svnadmin --version

svnadmin load repos < VersionStamps3

goto :eof

 

 

Thanks,

David

RE: "Unable to parse reversed revision range" when merging from trunk to branch

[Bert Huijben]

Can you point to the discussion on the mailinglist where this issue was 
discussed before creating the issue in our tracker?

(We only create issues to track confirmed issues on the tracker *after* 
discussion here, or on the development list)

 

This is the first time I hear about this issue, but perhaps I missed the 
earlier discussion.

 

Bert

 

From: Paul Hammant [mailto:p...@hammant.org] 
Sent: vrijdag 7 juli 2017 13:25
To: Jens Restemeier 
Cc: Stefan Sperling ; Johan Corveleyn ; 
users@subversion.apache.org
Subject: Re: "Unable to parse reversed revision range" when merging from trunk 
to branch

 

 

Done: https://issues.apache.org/jira/browse/SVN-4686

 

 

Jumping in with something that's in the same area - 
https://issues.apache.org/jira/browse/SVN-4635 is a merge tracking (or merge 
info/range props) bug that is still there in v1.9.6, in case anyone wants a 
scripted reproduction (30 seconds of bash script invocation).

 

-ph 

RE: --editor-cmd not working with paths with spaces?

[Bert Huijben]

> -Original Message-
> From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
> Sent: vrijdag 7 juli 2017 09:23
> To: users@subversion.apache.org
> Subject: --editor-cmd not working with paths with spaces?
> 
> Hi all,
> 
> I need to commit to some SVN repo in a Git bash/MinGW environment and
> recognized the following error:
> 
> > $ svn ci --editor-cmd "/usr/bin/vi"
> > Der Befehl "C:/Program" ist entweder falsch geschrieben oder konnte nicht
> gefunden werden.
> > svn: E200012: Commit failed (details follow):
> > svn: E200012: system('C:/Program Files/Git/usr/bin/vi svn-commit.4.tmp')


Where is your vi.exe located?

If it is in C:\usr\bin\vi.exe I would recommend using --editor-cmd 
"C:\usr\bin\vi.exe" or if VI is in your path you could just use --editor-cmd vi.
(I often use --editor-cmd notepad2, which is just located somewhere in my PATH 
dirs.)

Bert

RE: "Unable to parse reversed revision range" when merging from trunk to branch

[Bert Huijben]

> -Original Message-
> From: Jens Christian Restemeier [mailto:j...@playtonicgames.com]
> Sent: maandag 3 juli 2017 16:31
> To: 'Johan Corveleyn' 
> Cc: 'Stefan Sperling' ; users@subversion.apache.org
> Subject: RE: "Unable to parse reversed revision range" when merging from
> trunk to branch
> 
> I narrowed it down to the code in subversion/libsvn_subr/mergeinfo.c line
> 892-898 in adjust_remaining_ranges. At that point next_range actually starts
> before modified_range, so my guess is svn_sort__array_insert has some
> unexpected behaviour.
> 
>x892   svn_merge_range_t *new_modified_range =
> x
>x893 apr_palloc(result_pool, 
> sizeof(*new_modified_range));
> x
>x894   new_modified_range->start = next_range->end;
> x
>x895   new_modified_range->end = modified_range->end;
> x
>x896   new_modified_range->inheritable = FALSE;
> x
>x897   modified_range->end = next_range->start;
> x
>x898   (*range_index)+=2;
> x
>   >x899   svn_sort__array_insert(rangelist, 
> _modified_range,
> x
>   *range_index);
> x
>x901   /* Recurse with the new range. */
> x
>x902   adjust_remaining_ranges(rangelist, range_index,
> result_pool); 
> x
> 
> Intuitively it seems to be awfully complicated to expand a range to the end of
> a change, and then cut it down recursively with adjust_remaining_ranges.
> My first thought would be to step through "rangelist" and "changes" side by
> side in svn_rangelist_merge2, and to modify, insert or skip a range in either
> list until you're at the end. Though obviously I have no idea about all the 
> edge
> cases the current code most likely fixes...
> 
> So how should I proceed from here? Should I open a bug with my findings
> and the test case?

I see you already opened an issue.

To me it looks like the issue is related to mixing recursive and non-recursive 
mergeinfo inside the same range... (The ranges with and without a '*' in the 
string). I see that your example case in the issue has quite a bit of overlap 
with both these kinds of ranges.

It looks like your case triggers a very interesting edge case.

Bert 

RE: "svn status" does not show unversioned items been deleted but not committed

[Bert Huijben]

> -Original Message-
> From: Andrey [mailto:an...@inbox.ru]
> Sent: woensdag 14 juni 2017 12:22
> To: users@subversion.apache.org
> Subject: Re: "svn status" does not show unversioned items been deleted but
> not committed
> 
> So, what about this issues? I see it as not opened yet. Will it be fixed?

It is not easy to really describe 'the issue'.

How would you handle 'svn rm --keep-local ', where the current
behavior is the expected behavior.

In Subversion <= 1.6 versioned directories would always be available locally
until the delete was committed and we explicitly handled this case this way.



On the API level there is no real issue, as the information that something
exists locally is already available there...
So the thing that is missing is how to show this information from the 'svn'
tool without breaking backwards compatibility.

Bert

RE: "svn pget svn:externals -r . -R" dramatically slow

[Bert Huijben]

> -Original Message-
> From: Branko Čibej [mailto:br...@apache.org]
> Sent: donderdag 18 mei 2017 15:19
> To: users@subversion.apache.org
> Cc: Andrey 
> Subject: Re: "svn pget svn:externals -r  . -R" dramatically slow
> 
> On 18.05.2017 13:51, Andrey wrote:
> > Branko Čibej  писал(а) в своём письме Thu, 18 May
> > 2017 14:41:17 +0300:
> >
> >>> However, I don't want to revert anything, i am talking about
> >>> possibility of forget to add files because they are obscured by the
> >>> deletion state in the status.
> >>
> >> So what do you suggest we do instead?
> >>
> >> There's a file named 'foo' that was deleted with 'svn rm' but not
> >> committed, and also a file named 'foo' that you created on disk before
> >> committing the deletion (or rename). What do you propose  'svn status'
> >> should show?
> > may be add file content hash to represent 2 statuses of the same file
> > paths? At least it will protect file from accidental remove and miss
> > of add to commit?
> 
> There will be no accidental remove; when you commit, your new file will
> remain unversioned in the working copy:
> 
> brane@zulu:~/test/wc$ svn mv foo bar
> A bar
> D foo
> brane@zulu:~/test/wc$ echo foo > foo
> brane@zulu:~/test/wc$ svn st
> A  +bar
> > moved from foo
> D   foo
> > moved to bar
> brane@zulu:~/test/wc$ svn ci -mm
> Adding bar
> Deleting   foo
> Committing transaction...
> Committed revision 2.
> brane@zulu:~/test/wc$ svn st
> ?   foo
> 
> So far, this is what you reported. Now see what happens when you
> actually run 'svn add' to replace the deleted file:
> 
> brane@zulu:~/test/wc$ touch qux
> brane@zulu:~/test/wc$ svn add qux
> A qux
> brane@zulu:~/test/wc$ svn ci -mm
> Adding qux
> Transmitting file data .done
> Committing transaction...
> Committed revision 3.
> brane@zulu:~/test/wc$ svn mv qux baz
> A baz
> D qux
> brane@zulu:~/test/wc$ echo qux > qux
> brane@zulu:~/test/wc$ svn add qux
> A qux
> brane@zulu:~/test/wc$ svn st
> A  +baz
> > moved from qux
> ?   foo
> R   qux
> > moved to baz
> brane@zulu:~/test/wc$ svn ci -mm
> Adding baz
> Replacing  qux
> Transmitting file data .done
> Committing transaction...
> Committed revision 4.
> brane@zulu:~/test/wc$ svn st
> ?   foo
> 
> 
> In the first case, I suppose we could display something like the following:
> 
> D  +foo
> > moved to bar
> 
> or:
> 
> D  ?foo
> > moved to bar
> 
> 
> to indicate that the file was deleted, but still exists on disk.
> 
> The more interesting question is how, if at all, this would affect the
> Subversion API.

The api already has this information, as there is some on-disk info in the 
status api that isn't reported by 'svn' (but is used by other clients).

Note that 'svn rm --keep-local Q' is the only thing necessary to trigger this 
case. And before 1.7 (pre WC-NG) we always had to keep deleted directories 
until after they were committed, but we didn't want to report these as still 
existing. That is probably why nobody bothered adding UI for this to 'svn' yet.


Bert

RE: "svn pget svn:externals -r . -R" dramatically slow

[Bert Huijben]

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: woensdag 17 mei 2017 19:57
> To: Andry 
> Cc: users@subversion.apache.org
> Subject: Re: "svn pget svn:externals -r  . -R" dramatically slow
> 
> On Tue, May 16, 2017 at 11:42 PM, Andry  wrote:
> > Hello Users,
> >
> > Original issue: https://issues.apache.org/jira/browse/SVN-4681
> >
> > Just discovered a really strange case where exactly titled command bring
> really slow response.
> >
> > The repository contains more than 1000 revisions. The WC is in the middle,
> say at rev 1193 (the current), the show log shows 1191 at the last revision,
> the HEAD revision say 1300.
> > Trying to cd into WC directory and run the command. Needs about 1
> minute  to wait it's response. The Process Hacker shows traffic with the
> server up to about 2MB.
> >
> > If try to run command w/o -R flag - command returns immediately.
> >
> > The content of the externals property without the -R flag is:
> > https://domain.ab/svn/proj2/trunk - ^/../proj3/trunk/cmake cmake_proj3
> > ^/solutions/project1/sdk proj2-sdk
> >
> > The content of the externals property with the -R flag is:
> > https://domain.ab/svn/proj2/trunk - ^/../proj3/trunk/cmake cmake_proj3
> > ^/solutions/project1/sdk proj2-sdk
> > https://domain.ab/svn/proj2/trunk/proj2-gui -
> > https://domain.ab/svn/proj2/trunk/proj2-gui/lib/Resource/Files -
> >
> > I think the 2 last records draws the svn mad and it begin to crawl the 
> > server
> for something for about 1 minute.
> >
> > I tries variations of the command. For example all these having the same
> result as above:
> > svn pget svn:externals -r "1193" "https://domain.ab/svn/proj2/trunk; -R --
> non-interactive
> > svn pget svn:externals -r "1193"
> "https://domain.ab/svn/proj2/trunk@1193; -R --non-interactive
> > svn pget svn:externals "https://domain.ab/svn/proj2/trunk@1193; -R --
> non-interactive
> >
> > Dig a bit further and found this:
> > svn info https://domain.ab/svn/proj2/trunk/proj2-gui
> > svn: warning: W17: URL 'https://domain.ab/svn/proj2/trunk/proj2-gui'
> non-existent in revision 1300
> > svn: E29: Could not display info for all targets because some targets
> don't exist
> >
> > Seems the 2 last records reference URL's what does not exist anymore in
> the HEAD.
> >
> > These 2 records are left after an upgrade from a previous version of
> database, but why is the svn runs so slow about it? Anyway, i can't just
> cleanup the externals because they are from 3dparty repository in which i
> have no access.
> 
> Thanks for bringing the issue here to the list.

There is no optimized code path for retrieving properties recursively directly 
from the server.

The implementation of this specific command is like running 'svn ls' on every 
directory + fetching the properties on every file and every directory. (It is 
slightly more optimized than that, but not much)

Bert

RE: svn generates long lists of empty diffs with --diff-cmd

[Bert Huijben]

> -Original Message-
> From: Alexey Neyman [mailto:sti...@att.net]
> Sent: donderdag 20 april 2017 02:59
> To: users@subversion.apache.org
> Subject: svn generates long lists of empty diffs with --diff-cmd
> 
> Hi,
> 
> I noticed that SVN generates a lot of spurious diffs when using a
> --diff-cmd option that look like this:
> 
> Index: arch/alpha/boot/tools/objstrip.c
> ==
> =
> Index: arch/alpha/boot/Makefile
> ==
> =
> 
> Is it possible to suppress such empty diffs? This makes the tools like
> ReviewBoard (www.reviewboard.org) examine a lot of unchanged files and
> slows them down considerably and unnecessary.

What argument do you pass to --diff-cmd ?

Is it possible that the files are actually different, but your diff command 
reports that they are not different (e.g. after normalizing whitespace). I 
think this header is printed on changed files, right before invoking the diff 
command.

Bert

> 
> Regards,
> Alexey.

RE: Using UTF8 in repository name?

[Bert Huijben]

This message on the forum is 100% about the server side configuration. The 
client has no known problems encoding paths in a url, but the url specification 
itself doesn’t document an explicit encoding and as such Apache Httpd has to do 
the translation of the first part of the URL to the local path. When this fails 
you see errors as in this forum post.

 

The part after the repository location is 100% handled inside the Subversion 
code and is always UTF-8 safe as it has no relation to real on-disk paths.

 

On platforms like MAC/OS or Windows the server handles UTF-8 paths directly, 
but on unix based platforms like Linux where paths are at the core just formed 
by a bunch of bytes without a special meaning, you have to use a proper 
configuration. If the configuration mismatches there is no way to convert from 
the path form to UTF-8 and the other way around.

 

Bert

 

From: Doug Robinson [mailto:doug.robin...@wandisco.com] 
Sent: maandag 10 april 2017 22:17
To: Branko Čibej 
Cc: users@subversion.apache.org
Subject: Re: Using UTF8 in repository name?

 

Brane:

 

Thank you for replying.  Based on this post:

 

https://www.svnforum.org/forum/opensource-subversion-forums/general-setup-and-troubleshooting/79832-why-repository-name-should-not-be-utf-8

 

I am wondering if the SVN client is properly URL-encoding the repository name?

 

Based on:

 

https://en.wikipedia.org/wiki/Percent-encoding

 

I'm beginning to wonder if it is even possible (sort of similar to what Mac/OS 
does to UTF8 text...)?

 

Thank you.

 

Doug

 

On Mon, Apr 10, 2017 at 8:53 AM, Branko Čibej  > wrote:

On 10.04.2017 14:44, Doug Robinson wrote:
> Folks:
>
> I understand that UTF8 is the standard inside of Subversion repositories.
> My question is whether having the repository name itself be UTF8?  For
> instance zh_CN.utf8 ?  I googled around a bit and don't see an answer.
>
> If it is supported, is there some Apache setting that is required?
>
> Thanks in advance.

As long as the underlying filesystem supports it, there should be no
problems.

-- Brane





 

-- 

DOUGLAS B ROBINSON SENIOR PRODUCT MANAGER

 

T +1 925 396 1125

E   doug.robin...@wandisco.com

 

   

World Leader in Active Data Replication™

Find out more   wandisco.com

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE 
PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are not 
the intended recipient, please notify us immediately and destroy the message 
without disclosing its contents to anyone. Any distribution, use or copying of 
this email or the information it contains by other than an intended recipient 
is unauthorized. The views and opinions expressed in this email message are the 
author's own and may not reflect the views and opinions of WANdisco, unless the 
author is authorized by WANdisco to express such views or opinions on its 
behalf. All email sent to or from this address is subject to electronic storage 
and review by WANdisco. Although WANdisco operates anti-virus programs, it does 
not accept responsibility for any damage whatsoever caused by viruses being 
passed.

RE: [BUG] svn update produces unexpected result

[Bert Huijben]

The last change revision is documented to be the last revision in which that
node changed. 

 

The revision number in Subversion is global for the repository, so not
changing every file in every revision is 100% expected behavior. And this is
the reason we show these different revisions.

 

See the Subversion documentation for the fine details. (E.g.
http://svnbook.red-bean.com )

 

The help from --revision shows that we have even more interesting revisions
tied to a file:

-r [--revision] ARG  : ARG (some commands also take ARG1:ARG2 range)

 A revision argument can be one of:

NUMBER   revision number

'{' DATE '}' revision at start of the date

'HEAD'   latest in repository

'BASE'   base rev of item's working copy

'COMMITTED'  last commit at or before BASE

'PREV'   revision just before COMMITTED

 

 

Bert

 

 

From: Deng, Xiao [mailto:xiao.d...@garmin.com] 
Sent: vrijdag 10 maart 2017 19:48
To: users@subversion.apache.org
Subject: [BUG] svn update produces unexpected result

 

Hi,

 

When using svn update on a file with -r flag from one revision to another
where the content of the file at both revisions are identical, the last
commit of result file appears to be out of sync. 

 

Example:

Foo.txt have identical content at r100 and r200

Foo.txt is at base revision r100

svn update Foo.txt -r200

svn status Foo.txt -v --xml

Expected: 

base revision === last commit revision === 200

Actual:

base revision === 200 !== last commit revision === 100

 

Best Regards,



Xiao Deng

Software Engineer 2

Aviation | Garmin International 

xiao.d...@garmin.com



 

 

  _  


CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use
of the intended recipient(s) and contain information that may be Garmin
confidential and/or Garmin legally privileged. If you have received this
email in error, please notify the sender by reply email and delete the
message. Any disclosure, copying, distribution or use of this communication
(including attachments) by someone other than the intended recipient is
prohibited. Thank you.

RE: Is Subversion compatible and supported for Windows 10?

[Bert Huijben]

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: woensdag 22 februari 2017 09:43
> To: Stefan Hett 
> Cc: users@subversion.apache.org
> Subject: Re: Is Subversion compatible and supported for Windows 10?
> 
> Stefan Hett wrote on Tue, Feb 21, 2017 at 15:12:25 +0100:
> > That said: All the current builds for MaxSVN [1] (an experimental SVN
> > developer focused distribution) are tested on Windows 10 and work fine
> > there.
> 
> MaxSVN is maintained by Stefan.  (The svn devs know this, but not
> everyone on users@ does.)

It really depends on the distribution you use for the fine details, but I
can say that for the CollabNet and SlikSVN Subversion binaries and other
products based on SharpSvn (including AnkhSVN), Windows 10 is a fully
supported platform.

Bert

> 
> > [1] http://www.luke1410.de/typo3/index.php?id=97
> >
> > --
> > Regards,
> > Stefan Hett
> >

RE: How to check which branches have specific commit

[Bert Huijben]

> -Original Message-
> From: Thijs de Ridder [mailto:thijs.de.rid...@mep-info.com]
> Sent: woensdag 22 februari 2017 10:10
> To: users@subversion.apache.org
> Subject: How to check which branches have specific commit
> 
> We have an svn repository with several branches and tags.
> 
> - trunk/
> - branches/
>   - stable_1
>   - stable_2
>   - etc.
> - tags/
>   - stable_1_release_a
>   - stable_1_release_b
>   - etc.
> 
> We develop our software in trunk (or in a development branch which will be
> reintegrated to trunk). We merge the changes from trunk to a stable
branch.
> Sometimes we discover a bug which has been introduced quite some time
> ago.
> Because the list of branches becomes quite long, I would like to know if
it
> is possible to easily see in which branches / tags the bug is? So if for
> instance the bug was introduced in r50 in trunk and currently we are at
> r100, is there an svn command to see which branches / tags have r50 of
trunk
> merged? So we could easily see which branches are infected by this bug?
> An svn command or via tortoisesvn will help us a lot (although for
> tortoisesvn I should ask this on the tortsoisesvn mailing list)

Subversion currently doesn't track where something was branched to, only
where something was branched from... so there is no feature that can tell
you which of all locations miss a certain 'merge'.

For a specific branch you can see if it still needs specific merges via 'svn
mergeinfo --show-revs=eligible'

[[
$ svn help mergeinfo
mergeinfo: Display merge-related information.
usage: 1. mergeinfo SOURCE[@REV] [TARGET[@REV]]
   2. mergeinfo --show-revs=WHICH SOURCE[@REV] [TARGET[@REV]]

  1. Summarize the history of merging between SOURCE and TARGET. The graph
 shows, from left to right:
   the youngest common ancestor of the branches;
   the latest full merge in either direction, and thus the common base
 that will be used for the next complete merge;
   the repository path and revision number of the tip of each branch.

  2. Print the revision numbers on SOURCE that have been merged to TARGET
 (with --show-revs=merged), or that have not been merged to TARGET
 (with --show-revs=eligible). Print only revisions in which there was
 at least one change in SOURCE.

 If --revision (-r) is provided, filter the displayed information to
 show only that which is associated with the revisions within the
 specified range.  Revision numbers, dates, and the 'HEAD' keyword are
 valid range values.

  SOURCE and TARGET are the source and target branch URLs, respectively.
  (If a WC path is given, the corresponding base URL is used.) The default
  TARGET is the current working directory ('.'). REV specifies the revision
  to be considered the tip of the branch; the default for SOURCE is HEAD,
  and the default for TARGET is HEAD for a URL or BASE for a WC path.

  The depth can be 'empty' or 'infinity'; the default is 'empty'.
]]

With some simple scripting you should be able to run this on all branches
below a specific directory, etc.


Thanks / Met vriendelijke groeten,

Bert 

RE: [Bug] svn export -r of single file fails if there is a newer revision available than the exported one

[Bert Huijben]

The -r123 and @123 functions have completely different behavior.

 

The @ syntax looks up the url as it was in in revision r123 and fetches the 
file from there

The -r checks the path as it currently exists, back to the path it had in 
revision 123… following copies, renames, etc.

(Note: you can combine these functions to trace a url backwards starting with a 
specific revision)

 

So this is most likely the completely documented behavior. See the Subversion 
book on   http://svnbook.red-bean.com

 

Bert

 

From: Schedel, Andreas [mailto:andreas.sche...@harman.com] 
Sent: donderdag 16 februari 2017 11:31
To: users@subversion.apache.org
Subject: [Bug] svn export -r  of single file fails if there is a newer 
revision available than the exported one

 

SVN server: V1.8.14 (r1692801)

 

Hi, 

 

When trying to export a dedicated file of a special revision by using 

# svn export –r  https://svn-server/trunk/myfile.txt

everything is working fine as long as no newer revision of this file is 
available in the repository. 

 

If a newer revision is available on the server, the following error message is 
returned: 

svn: E195012: Unable to find repository location for  
in revision 

 

The “@syntax” is working fine: 

# svn export https://svn-server/trunk/myfile.txt@ 
 

 

Is this an already known bug of SVN or perhaps an undocumented feature? 

 

Thanks and best regards

 

Andreas

 

 


Harman Becker Automotive Systems GmbH
Sitz der Gesellschaft: Karlsbad
Amtsgericht Mannheim: HRB-Nr. 361395
Geschäftsführung: Michael Mauser, Dr. Udo Hüls
Vorsitzender des Aufsichtsrats: Dr. Frank Groth

__

ANDREAS SCHEDEL

BMW MGU 

Harman International Automotive Division

 

Parkring 3

85748 Garching, Germany

Phone:   +49 (89) 35870 – 040

Fax:+49 (89) 35870 – 170

Email:    andreas.sche...@harman.com

Web: www.harman.com


 



Confidentiality Notice: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by return e-mail and destroy all copies of the original 
message.

 

RE: how to detect read-only branch from client?

[Bert Huijben]

> -Original Message-
> From: Torsten Mueller [mailto:muelle...@runbox.com]
> Sent: woensdag 15 februari 2017 08:41
> To: users@subversion.apache.org
> Subject: Re: how to detect read-only branch from client?
> 
> Andrew Reedick  schrieb:
> 
> > Not a complete solution, but it's a start. Craft a "svn mkdir" that
> > includes the url to test and a url that will always fail
> 
> That's it. The key is to create a nested directory in a branch, this
> means a directory which has a non-existing parent, and doing that
> without the --parent parameter:
> 
>   Test/ro is a readonly branch
>   Test/rw is a normal (read/write) branch
> 
>   trying to create directory "a/b":
> 
>   $ svn mkdir -m"xx" https://repository/svn/Binaries/Test/ro/a/b;
>   svn: E175013: Access to '/svn/Binaries/!svn/txr/50-1u/Test/ro/a/b'
> forbidden
> 
>   $ svn mkdir -m"xx" https://repository/svn/Binaries/Test/rw/a/b;
>   svn: E160013: Try 'svn mkdir --parents' instead?
>   svn: E160013: File not found: transaction '50-1v', path '/Test/rw/a/b'
> 
> This gives two distiguishable messages: in the first case it fails
> because of the readonly property, in the second case because of the
> missing --parent parameter. No revision is made iin both cases - great.

A better way would be to perform the operation, but *not* specify a log
message and configure no editor either. In that case the operation will fail
client side after these checks via the missing log message.


But then there is always the option that the read-only-ness is applied via a
hook script... And in this case this trickery just fails.

Bert

RE: svn_dirent_t::size: often not the "real" file size

[Bert Huijben]

The size reported is the size of the file in repository form. The size might
be different when a different line end encoding is used and/or when keyword
expansion is enabled. (Can be larger or smaller)

 

svn_client_statusX() reports both sizes when the file is a ‘normal’ working
copy file.

 

The list function works 100% repository side and we simply don’t know the
size the file would be in some working copy, as the size might be different
in other working copies.

 

Bert

 

From: Bijewitz, Volker [mailto:v.bijew...@baum.de] 
Sent: donderdag 2 februari 2017 09:22
To: users@subversion.apache.org
Subject: svn_dirent_t::size: often not the "real" file size

 

Hi SVN developers,

 

I am working on an TotalCommander plugin to browse SVN repositories. Now I
have the problem that on some repositories the filesize reported by
svn_client_list3 is different from the “real” file size of the working copy
– so comparing the SVN repo with the working copy is impossible. So here are
my questions on this issue:

 

* Is there a way for a SVN client to detect the “real” filesize?

* Does this behavior change with the server version? I have one
server where the filesize seems to match, another server where it does not
match. 

* If there are servers that reports “real” file sizes: is there a
client functionality to detect if he is connected to a server with “good”
behavior?

 

This may be not the correct way to do a compare, there would be better ways
using the SVN interface. But I am limited to the TC plugin interface. And in
this interface there is no “Compare with file” function. I have just to
deliver the correct properties, and TC itself does the operation in a way
the user has configured it. 

 

Cheers,

 

Volker Bijewitz

 

BAUM Systeme GmbH

Industriestr. 15

74909 Meckesheim

 

 

E-Mail : v.bijew...@baum.de  

Internet: www.baum.de  

 

 

Geschäftsführer: Wolfgang Baum - Thomas Friehoff

 

Registergericht Mannheim, HRB 333567

Gerichtsstand: Heidelberg

 

VAT Nr: DE 143260354

IK 590820251

 

Bankverbindungen:

Commerzbank Heidelberg

IBAN: DE63 6724 0039 0193 5808 00

BIC: COBADEFFXXX

Postbank Karlsruhe

IBAN: DE40 6601 0075 0202 5007 54

BIC: PBNKDEFF

 

 

RE: How to hide unversioned files from svn status

[Bert Huijben]

> -Original Message-
> From: Branko Čibej [mailto:br...@apache.org]
> Sent: dinsdag 22 november 2016 18:26
> To: users@subversion.apache.org
> Subject: Re: How to hide unversioned files from svn status
> 
> On 22.11.2016 16:30, Olaf van der Spek wrote:
> > On Tue, Nov 22, 2016 at 10:40 AM, Daniel Shahaf 
> wrote:
> >> Johan Corveleyn wrote on Tue, Nov 22, 2016 at 09:43:26 +0100:
> >>> If you want to add that option to every status command, maybe you can
> >>> use a shell alias or something similar for that?
> >> For Bourne-like shells:
> >>
> >> svn() {
> >>   case "$1" in
> >> st|stat|staus) command svn -q "$@";;
> >> *) command svn "$@";;
> >>   esac
> >> }
> >>
> >> (Put that in your shell's dotfiles.)
> > I'm not a fan of such hacks.. ;)
> > Wouldn't it make sense to have a conf file option for this?
> 
> 
> In short ... no. The svn:ignore property already does what you need,
> with less chance of shooting yourself in the foot. You can always set
> svn:ignore to * if you really want that ...

Or set
[miscellany]
global-ignores = *

In ~/.subversion/config

Bert

RE: discrepancies between 'svn -R list' and 'svn -R propget' (on windows using TSVN build command line client)

[Bert Huijben]

> -Original Message-
> From: Lorenz [mailto:loren...@yahoo.com]
> Sent: woensdag 16 november 2016 15:02
> To: users@subversion.apache.org
> Subject: Re: discrepancies between 'svn -R list' and 'svn -R propget' (on
> windows using TSVN build command line client)
> 
> Bert Huijben wrote:
> >[...]
> >The difference is that 'svn ls' is really a repository operation, working
on
> >URLS (or part of urls). On URLs we always use the url / platform
independent
> >'/' separator.
> >
> >'svn propget' usually works on local paths, in which case we use the
local
> >path (or technically 'dirent') separator, which is a '\' on Windows.
> >
> >This behavior was explicitly implemented this way years ago.
> >[...]
> 
> ok, that explains the slash mystery 8-)
> 
> 
> 
> but what about the leading subpath vs. no subpath difference?
> 
> svn -R ls path/subpath
> 
>   file1
>   subsubpath/file2
>   ...

I don't think this was designed behavior... But it follows from the previous
answer: we just return the items relative from the url that you listed. 
There is no easy way to do this differently as local paths might not match
remote paths, like when you have switched paths. 

So when we would show 'path/subpath/subsubpath/file2', it might be a
completely different result than the local relative path with the same name.

> 
> vs.
> 
> svn -R pg svn:keywords path/subpath
> 
>   subpath/file1 - ...
>   subpath/subsubpath/file2
>   ...

And in this case we try to return the paths exactly in the form that you
used on the commandline, to allow you to match the result of multiple
arguments with multiple locations.
(Internally we convert to the absolute path and then back on output these
days, but we used to process everything in the original form before
Subversion 1.7)

If you don't pass something like @rev or -r REV (or a URL instead of a
path), this will always match your local files.


Note that in both cases we recommend using --xml if you are going to parse
the output via tools as that has a more stable output format in case we add
new features in new releases.

Bert

RE: discrepancies between 'svn -R list' and 'svn -R propget' (on windows using TSVN build command line client)

[Bert Huijben]

> -Original Message-
> From: Lorenz [mailto:loren...@yahoo.com]
> Sent: woensdag 16 november 2016 10:02
> To: users@subversion.apache.org
> Subject: discrepancies between 'svn -R list' and 'svn -R propget' (on
windows
> using TSVN build command line client)
> 
> Hi all,
> 
> navigating to a working copy folder (or a subfolder thereof) and
> issuing 'svn -R list path/sub' or 'svn -R list path\sub' results in:
> 
>   file1
>   subsub/file2
>   ...
> 
> 
> whereas  'svn -R pg svn:keywords path/sub'
> or 'svn -R pg svn:keywords  path\sub' results in:
> 
>   sub\file1 - Id URL
>   sub\subsub\file2 - Id URL
>   ...
> 
> 
> There are two discrepancies the first of which looks like it is not
> windos depended:
> 
>   'svn propget' always lists the 'sub' part of the path,
>   'svn list' does not.
> 
> is this the same under linux, and if so is it intended behaviour?

The difference is that 'svn ls' is really a repository operation, working on
URLS (or part of urls). On URLs we always use the url / platform independent
'/' separator.

'svn propget' usually works on local paths, in which case we use the local
path (or technically 'dirent') separator, which is a '\' on Windows.


This behavior was explicitly implemented this way years ago.


> The second one is windows dependent (maybe even TSVN specific):
> 
>   'svn list' uses '/' whereas 'svn pg' uses '\'
> 
> do all native windows clients behave this way or is this with the TSVN
> client only?

The standard 'svn' clients will all use the same formatting as they share
the same code here. (TortoiseSVN compiles the standard 'svn' sourcecode for
their svn binary)
The formatting is really part of the client as internally Subversion always
uses '/', so any other client than 'svn' may use different formatting, but I
think you can expect 'svn' to keep using the existing formats.

Bert
> 
> 
> I'm on win7 using the command line client that ships with tortoise svn
> (TSVN 1.9.4  linked against  svn 1.9.4)
> --
> 
> Lorenz

RE: Re: subversion issue: ignore server invaild certificate in linux

[Bert Huijben]

> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: vrijdag 21 oktober 2016 14:14
> To: yuan lixin 
> Cc: users@subversion.apache.org
> Subject: Re: Re: subversion issue: ignore server invaild certificate in
linux
> 
> On Fri, Oct 21, 2016 at 07:41:18PM +0800, yuan lixin wrote:
> > but in the interface "svn_auth_ssl_server_trust_prompt_func_t",
> > the actual parameter is "failures", not "*failures".  so it can not
change
> > the svn's failures in linux, then can not ignore certificate.
> > could you look at my code for a solution.
> >
> > Thank you
> > --woodsp
> 
> libsvn_subr gets 'failures' from the 'parameters' hash:

Code shouldn't touch the failures value; they should change the
accepted_failures in the credentials value. 

/** @c SVN_AUTH_CRED_SSL_SERVER_TRUST credentials. */
typedef struct svn_auth_cred_ssl_server_trust_t
{
  /** Indicates if the credentials may be saved (to disk). For example, a
   * GUI prompt implementation with a checkbox to accept the certificate
   * permanently shall set @a may_save to TRUE if the checkbox is checked.
   */
  svn_boolean_t may_save;
  /** Bit mask of the accepted failures */
  apr_uint32_t accepted_failures;
} svn_auth_cred_ssl_server_trust_t;


If svn uses a different way to change a value in the caller that is a bug
that should be fixed there.

Bert

RE: svn switch, touches files with svn:keywords

[Bert Huijben]

> -Original Message-
> From: Daniel Shahaf [mailto:danie...@apache.org]
> Sent: zaterdag 24 september 2016 09:11
> To: FEDERICO PRADES ILLANES 
> Cc: users@subversion.apache.org
> Subject: Re: svn switch, touches files with svn:keywords
> 
> FEDERICO PRADES ILLANES wrote on Fri, Sep 23, 2016 at 12:36:24 +0200:
> > Steps to reproduce:
> >
> >1. Create a branch b1.
> >2. Create an dummy file in b1, with svn:keywords.
> >3. Don't use the svn:keywords on the file.
> >4. Commit the changes to b1.
> >5. Create a branch b2, from b1.
> >6. Perform a switch to b2.
> >
> > Expected results:
> >
> >- Dummy file modification time hasn't change
> >
> > Actual results
> >
> >- Dummy file modification time has change
> 
> I can reproduce this with current trunk and I agree it's a (minor) bug.

See also issue #1975, which documented the opposite behavior as a bug, which 
was fixed in 1.9.0
http://subversion.apache.org/issue1975

Bert

RE: Can't compile Subversion against Serf-1.3.9.

[Bert Huijben]

> -Original Message-
> From: Andreas Stieger [mailto:andreas.stie...@gmx.de]
> Sent: woensdag 7 september 2016 10:32
> To: "Alexandre C. Guimarães" 
> Cc: users@subversion.apache.org
> Subject: Aw: Can't compile Subversion against Serf-1.3.9.
> 
> Hi,
> 
> Alexandre C. Guimarães wrote:
> > I am getting trouble to rebuild subversion-1.9.4 on my
> > FreeBSD-10.3 box after Serf be updated to 1.3.9:
> [...]
> > /usr/local/lib/libserf-1.so: undefined reference to `BIO_meth_set_gets'
> 
> Looks like an OpenSSL linking problem. Ensure Apache Serf and Apache
> Subversion are built against the same OpenSSL version.

It looks like your Serf is compiled against OpenSSL 1.1.0, while some 
dependency of Subversion that is loaded before serf uses an older version.

On FreeBSD OpenSSL 1.1.0 is only part of the 'openssl-devel' port. The normal 
openssl package is 1.0.2, while the base system is still at 1.0.1.

My guess would be that you have an apr-util or cyrus sasl port that is linked 
to the base system version. (On FreeBSD apr and apr-util are a single package)


Bert

RE: SVN Feature Request: Selecting the revision for pinning externals

[Bert Huijben]

A single argument specifying a revision may only work for very specific
scenarios. The --pin-externals feature also works when you have dozens of
externals, all pointing towards different repositories.

 

When adding the feature we determined that we can't handle all these
additional cases using the generic copy api. This function really 'pins'
what a checkout would do at the time of the pinning. going any further would
require much manual work from the user, which he/she could already do before
we added this. (Update working copy manually, and commit by using svn cp
PATH URL. Perhaps revert the local copy after this)

 

Bert

 

From: Israel Sadeh [mailto:israel.sa...@rtc-vision.com] 
Sent: donderdag 1 september 2016 18:47
To: users@subversion.apache.org
Subject: SVN Feature Request: Selecting the revision for pinning externals

 

Hi,

 

The new '-pin-externals' switch of the 'svn copy' command pins the externals
to their latest version.

This makes sense when copying the latest revision, but in case the copied
branch is from an older revision, it also makes sense to pin the externals
to the old revision.

This way in case it will be possible to create a tag from an old revision,
and not only from the latest one.

 

My suggestion:  Add an optional pinning-revision parameter to the
'-pin-externals' switch.

By default (if the pinning-revision' parameter isn't set)  - the externals
will be pinned to the latest version.

If the parameter is set - the externals will be pinned to the parameter
revision.

 

Best regards,

 

Israel Sadeh

 



 

Israel Sadeh
Software Engineer 

RTC Vision Ltd.

  www.rtc-vision.com

 

 

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

[Bert Huijben]

> -Original Message-
> From: Vincent Lefevre [mailto:vincent-...@vinc17.net]
> Sent: woensdag 27 juli 2016 02:36
> To: users@subversion.apache.org
> Subject: svnserve takes too much memory for "svn blame"
> 
> When I do "svn blame" on some file (36972 lines), svnserve takes
> more than 800 MB on the server (and is killed due to lack of
> memory). So, it seems that svnserve is inefficient in terms of
> memory usage (that's at least 22 KB per line!).
> 
> svnserve, version 1.8.8 (r1568071)
>compiled Aug 20 2015, 12:51:30 on x86_64-pc-linux-gnu

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

Bert

RE: Subversion Exception! - on cleanup after uncomplete checkout

[Bert Huijben]

> -Original Message-
> From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com]
> Sent: maandag 2 mei 2016 09:57
> To: Tomáš Bartek 
> Cc: Subversion Users 
> Subject: Re: Subversion Exception! - on cleanup after uncomplete checkout
> 
> 
> > On Apr 29, 2016, at 2:17 AM, Tomáš Bartek 
> wrote:
> >
> > ---
> > Subversion Exception!
> > ---
> > Subversion encountered a serious problem.
> > Please take the time to report this on the Subversion mailing list
> > with as much information as possible about what
> > you were trying to do.
> > But please first search the mailing list archives for the error message
> > to avoid reporting the same problem repeatedly.
> > You can find the mailing list archives at
> > http://subversion.apache.org/mailing-lists.html
> >
> > Subversion reported the following
> > (you can copy the content of this dialog
> > to the clipboard using Ctrl-C):
> >
> > In file
> >  'D:\Development\SVN\Releases\TortoiseSVN-
> 1.9.3\ext\subversion\subversion\libsvn_client\cleanup.c'
> >  line 227: assertion failed (svn_dirent_is_absolute(dir_abspath))

This is an assertion on the very first line of svn_client_cleanup2(), asserting 
that the passed argument is an absolute path (required, as documented).

Please report this issue at TortoiseSVN, as they somehow call this function 
with an invalid path.

Bert

RE: A verbose option to "svn update"?

[Bert Huijben]

This may work for a system like CVS that does everything per file, but in case 
of Subversion this doesn’t really work. We check all files locally at the start 
 of the update, then send a report to the server to what exactly we have 
locally… and then the server only sends a binary-tree-diff of what has changed 
between revisions.

So changing a really large file, could be a very tiny operation… or changing a 
small one a huge operation. The client would only know when the file is done 
(=the moment you see the notification now).

The verbose information you want is not available on either the client or the 
server… just on the combination. And redesigning the protocol to expose it 
would only slow things down.

What might help is looking at how much data is transferred, which some of our 
common GUI clients do. Exposing this on the console is hard. (We made some 
early prototypes some time ago, but non that we liked enough to release in 
‘svn’)

Bert

Sent from Mail for Windows 10

From: Doug Robinson
Sent: woensdag 27 april 2016 22:57
To: users@subversion.apache.org
Subject: A verbose option to "svn update"?

Folks:

A suggestion from one of our customers:

I see that "svn update" does not have a -v (verbose) option either. That would 
be helpful, because verbose output of what svn update is doing file by file 
would help narrow in on what is going on much faster. Something like this:

> svn -v update
Updating '.':
checking file1 ...
checking bin/file2 ...
U bin/file2
fetching file3 ...
A file3
checking lib/file4 ...

If something like the above was available, then users would see what svn was 
update while getting updates. I could have, for example, quickly seen it was 
stuck "checking file galaxy_ms_wroute_pg.v ..." the file the ended up being the 
issue in this case.

In this case they found a problem with a large file by watching "ps" output.  
But such a verbose option would enable much easier diagnostics.

Even better, on slow links this could definitely help delay the end-user SIGINT 
because they thought something was "hung".

Thoughts?  Is there already a better way?

Thank you.

Doug
-- 
DOUGLAS B. ROBINSON SENIOR PRODUCT MANAGER

T 925-396-1125
E doug.robin...@wandisco.com

www.wandisco.com



Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges
Listed on the London Stock Exchange: WAND
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege.  If 
you are not the intended recipient, please notify us immediately and destroy 
the message without disclosing its contents to anyone.  Any distribution, use 
or copying of this e-mail or the information it contains by other than an 
intended recipient is unauthorized.  The views and opinions expressed in this 
e-mail message are the author's own and may not reflect the views and opinions 
of WANdisco, unless the author is authorized by WANdisco to express such views 
or opinions on its behalf.  All email sent to or from this address is subject 
to electronic storage and review by WANdisco.  Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

RE: Error---After upgrading from subversion 1.6 to 1.8.

[Bert Huijben]

> -Original Message-
> From: Reyaz [mailto:skreyazaha...@gmail.com]
> Sent: maandag 28 maart 2016 11:45
> To: users@subversion.apache.org
> Subject: Error---After upgrading from subversion 1.6 to 1.8.
> 
> Hi Team,
> 
> We have recently upgraded subversion from 1.6 version to 1.8 version on
> RHEL
> 5.8. After upgrade we are getting below error in error_log file. Before
> upgrade everything working fine.Now we are unable to access the projects
> with below given error.
> 
> 
> "[Tue Mar 15 03:06:57 2016] [error] [client 10.191.212.115] Failed to load
> the mod_authz_svn config: Section name 'Ents_0590_EA:2113:ELA Amd #5 -
> 340
> BCDs:/' contains non-canonical fspath '2113:ELA Amd #5 - 340 BCDs:/''"

It looks like there is some invalid path in the authz file.

This should be the file that you configured in
[[
AuthzSVNAccessFile /u10//svnauthfile
]]
in your configuration.


Bert

RE: Upgrade Subversion from 1.5 to 1.9

[Bert Huijben]

I'm not sure where you read that, but subversion can upgrade working copies
all the way up from 1.0. (See our compatibility guarantee)

 

There is one exception: If a working copy operation was stopped halfway. in
this case you need to run 'svn cleanup' with your older Subversion version
(or 1.6.x) prior to upgrading to Subversion 1.7 or newer.

 

You would have seen an error at the end of the operation and/or explicitly
cancelled the operation as a user in all cases where you need this.

 

Bert

 

From: Safarulla Meerasahib [mailto:safarulla.meerasa...@oracle.com] 
Sent: maandag 21 maart 2016 18:34
To: users@subversion.apache.org
Subject: Upgrade Subversion from 1.5 to 1.9

 

Hi,

 

We have recently taken over a production  application from other team, which
uses the SVN 1.5.0 as one of the component. Now we have a requirement to
upgrade this to latest version of the subversion.

While going through the Apache subversion link we have noticed that
Subversion 1.9 can only upgrade working copies created with Subversion 1.6
and Subversion 1.7.

Is there any workaround to upgrade 1.5.0 to 1.9?

 

Thanks & Regards,

Safarulla M.

 

RE: Modifying svn:log property: good or bad?

[Bert Huijben]

> -Original Message-
> From: Alfred von Campe [mailto:alf...@von-campe.com]
> Sent: maandag 29 februari 2016 16:56
> To: webster.br...@rogers.com
> Cc: Eric Johnson ; Subversion Users
> 
> Subject: Re: Modifying svn:log property: good or bad?
> 
> Thanks to all who have shared their respective policies.  I’d be very
> interested to hear from the Subversion contributors themselves as to what
> the policy is for the Subversion repo.

Subversion is now hosted in the ASF wide repository of the Apache foundation, 
so we don't declare the policy ourselves. (Although I think the original 
Subversion developers were involved when this repository was created)

This repository allows changing the log message of revisions that apply to 
projects you are privileged to commit to. (I'm guessing it uses some custom 
scripting for this... not sure)

Before that we used a similar 'allow edit svn:log' policy for committers on the 
now disabled svn.collab.net server. I think propedits to other properties are 
denied.


All repository changes go through a commit mailer script, which sends out mails 
to the mailinglists of projects touched. For ^/subversion in the ASF repository 
that would be commits@subversion.a.o.


Bert

RE: (unknown)

[Bert Huijben]

[Moving thread to dev@s.a.o from users@]

> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: maandag 22 februari 2016 13:21
> To: 'Daniel Shahaf' <d...@daniel.shahaf.name>; 'Michal Matyl'
> <michal.ma...@zf.com>
> Cc: users@subversion.apache.org
> Subject: RE: (unknown)
> 


> I just reviewed most of the code that is responsible for this behavior... and 
> I
> have to conclude it works 'as designed'.
> 
> 1) We determine the changes on both sides.
> * On one side we see a replacement of line 'C', by a different set of tokens.
> * And on the other side we see an insertion of a set of tokens after 'C'.
> (This code is in subversion/diff/lcs.c)
> 
> 2) Then we combine the changes of both sides.
> * We can apply the first change as there are no overlapping regions
> * We can apply the second change as there no overlapping regions
> (This code is in subversion/diff/diff3.c)
> 
> In our very abstract implementation things work as intended... so now we
> have to determine how we want to fix things. -> back to design phase.
> 
> 
> I have a working patch that determines that these changes touch each other
> and then marks them as conflict, but that still doesn't produce the kind of
> conflict that you would really want here. And I'm not sure
> 
> In the optimal case we would flag one conflict containing both changes *as
> one*, but that will take more work.
> 
> 
> 
> Note that the 'whitespace' (noted in original report) is completely unrelated
> to this issue. Our diff code works with tokens, while the whitespace is
> handled in the tokenizer. I can easily reproduce this issue without any
> whitespace changes.

I completed the patch to a form, where I like the result.

[[
Index: subversion/libsvn_diff/diff3.c
===
--- subversion/libsvn_diff/diff3.c  (revision 1731660)
+++ subversion/libsvn_diff/diff3.c  (working copy)
@@ -320,16 +320,17 @@ svn_diff_diff3_2(svn_diff_t **diff,
  suffix_lines, subpool);
   lcs_ol = svn_diff__lcs(position_list[0], position_list[2], token_counts[0],
  token_counts[2], num_tokens, prefix_lines,
  suffix_lines, subpool);
 
   /* Produce a merged diff */
   {
 svn_diff_t **diff_ref = diff;
+svn_diff_t *diff_last = NULL;
 
 apr_off_t original_start = 1;
 apr_off_t modified_start = 1;
 apr_off_t latest_start = 1;
 apr_off_t original_sync;
 apr_off_t modified_sync;
 apr_off_t latest_sync;
 apr_off_t common_length;
@@ -429,16 +430,17 @@ svn_diff_diff3_2(svn_diff_t **diff,
 is_modified = lcs_om->position[0]->offset - original_start > 0
   || lcs_om->position[1]->offset - modified_start > 0;
 
 is_latest = lcs_ol->position[0]->offset - original_start > 0
 || lcs_ol->position[1]->offset - latest_start > 0;
 
 if (is_modified || is_latest)
   {
+svn_boolean_t add_diff = TRUE;
 modified_length = modified_sync - modified_start;
 latest_length = latest_sync - latest_start;
 
 (*diff_ref) = apr_palloc(pool, sizeof(**diff_ref));
 
 (*diff_ref)->original_start = original_start - 1;
 (*diff_ref)->original_length = original_sync - original_start;
 (*diff_ref)->modified_start = modified_start - 1;
@@ -450,26 +452,47 @@ svn_diff_diff3_2(svn_diff_t **diff,
 if (is_modified && is_latest)
   {
 svn_diff__resolve_conflict(*diff_ref,
_list[1],
_list[2],
num_tokens,
pool);
   }
-else if (is_modified)
+else if (is_modified
+ && (!diff_last
+ || diff_last->type != svn_diff__type_diff_latest))
   {
 (*diff_ref)->type = svn_diff__type_diff_modified;
   }
-else
+else if (is_latest
+ && (!diff_last
+ || diff_last->type != svn_diff__type_diff_modified))
   {
 (*diff_ref)->type = svn_diff__type_diff_latest;
   }
+else
+  {
+/* We have a latest and a modified region that touch each 
other,
+   but not directly change the same location. Create a single
+   conflict region to properly mark a conflict, and to ease
+   resolving. */
+diff_last->type = svn_diff__type_conflict;
+diff_last->ori

RE: (unknown)

[Bert Huijben]

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: zondag 14 februari 2016 15:35
> To: Michal Matyl 
> Cc: users@subversion.apache.org
> Subject: Re: (unknown)
> 
> Michal Matyl wrote on Thu, Feb 11, 2016 at 10:19:02 +:
> > The example is about a simple branch merging with default settings and
> > a classic conflict situation, no fancy features or complex
> > trunk-to-branch back merging, so I belive simple prose description of
> > the problem is enough.
> 
> The prose did not suffice: I would not have understood the problem
> without the attachment.  The preferred way to describe a bug is by
> a script that reproduces it.
> 
> For future reference, we provide template scripts at:
> https://subversion.apache.org/docs/community-
> guide/issues.html#reporting-bugs
> (fourth paragraph)
> 
> > First developer creates branch-01 and inserts few lines into existing
> > file. Another developer creates branch-02 and makes exactly the same
> > changes as first developer, i.e. inserts the same lines with the same
> > content. The only difference in the second's developer branch is
> > whitespace change (space/tab doesn't matter) in a line preceding
> > inserted lines.
> >
> 
> You are describing a merge where
> 
> * The difference between the OLD and MINE is:
> 
> Index: branches/branch-01/test_file.txt
> 
> ==
> =
> --- branches/branch-01/test_file.txt(revision 3)
> +++ branches/branch-01/test_file.txt(revision 4)
> @@ -1,6 +1,9 @@
>  A
>  B
>  C
> +D
> +E
> +F
>  J
>  K
>  L
> \ No newline at end of file
> 
> * The difference between OLD and THEIRS is:
> 
> Index: branches/branch-02/test_file.txt
> 
> ==
> =
> --- branches/branch-02/test_file.txt(revision 6)
> +++ branches/branch-02/test_file.txt(revision 7)
> @@ -1,6 +1,9 @@
>  A
>  B
> -C
> + C
> +D
> +E
> +F
>  J
>  K
>  L
> \ No newline at end of file
> 
> * There are no local mods.
> 
> That merge results in:
> 
> Index: trunk/test_file.txt
> 
> ==
> =
> --- trunk/test_file.txt (revision 7)
> +++ trunk/test_file.txt (revision 8)
> @@ -1,9 +1,12 @@
>  A
>  B
> -C
> + C
>  D
>  E
>  F
> +D
> +E
> +F
>  J
>  K
>  L
> \ No newline at end of file
> 
> Yes, I also think that is a bug: a text conflict should have been
> flagged.

I just reviewed most of the code that is responsible for this behavior... and I 
have to conclude it works 'as designed'.

1) We determine the changes on both sides.
* On one side we see a replacement of line 'C', by a different set of tokens.
* And on the other side we see an insertion of a set of tokens after 'C'.
(This code is in subversion/diff/lcs.c)

2) Then we combine the changes of both sides.
* We can apply the first change as there are no overlapping regions
* We can apply the second change as there no overlapping regions
(This code is in subversion/diff/diff3.c)

In our very abstract implementation things work as intended... so now we have 
to determine how we want to fix things. -> back to design phase.


I have a working patch that determines that these changes touch each other and 
then marks them as conflict, but that still doesn't produce the kind of 
conflict that you would really want here. And I'm not sure

In the optimal case we would flag one conflict containing both changes *as 
one*, but that will take more work.



Note that the 'whitespace' (noted in original report) is completely unrelated 
to this issue. Our diff code works with tokens, while the whitespace is handled 
in the tokenizer. I can easily reproduce this issue without any whitespace 
changes.

Bert

RE: svn_fs for rename file and folder

[Bert Huijben]

Currently not.  We still express moves as copies+delete.
(There is some experimental support hidden in the implementations, but that 
isn’t used yet)

Bert

Sent from Mail for Windows 10

From: Ren Wang
Sent: zondag 21 februari 2016 16:44
To: users@subversion.apache.org
Subject: svn_fs for rename file and folder


Are there APIs for renaming file/folder in the svn_fs layer?

Regards,

Ren

RE: upgrade Subversion from version 1.6 to svn, version 1.8.15 (r1718365)

[Bert Huijben]

Are you sure the directory you tried to upgrade is a 'working copy'? The way
you describe it, it looks like it is a repository.

 

Subversion 1.9 and 1.8 can just use 1.6 repositories without upgrade. or you
can run 'svnadmin upgrade' on them to enable new features.

 

Bert

 

From: Hom, Margaret [mailto:margaret@ucsf.edu] 
Sent: zaterdag 20 februari 2016 02:30
To: users@subversion.apache.org
Cc: Hom, Margaret 
Subject: upgrade Subversion from version 1.6 to svn, version 1.8.15
(r1718365)

 

Hi,

I installed version 1.8.15, copied the working directory from an existing
1.6 version server to this new server.   I su logged in as subvadm, cd to
working directory, cd to one of the working directory ais_repos.   I issued
the command 'svn upgrade', but   I got the error not a working copy root,
file not found error. (please see the following copy and paste).

I am new to the Subversion.  Please advise.

Thanks,

Margaret Hom

UCSF

 

 

 

 

[sfaismh@vx63 ~]$ su - subvadm

Password: 

[subvadm@vx63 ~]$ cd /subv_repos

[subvadm@vx63 subv_repos]$ cd ais_repos

[subvadm@vx63 ais_repos]$ svn upgrade

svn: E155019: Can't upgrade '/subv_repos/ais_repos' as it is not a working
copy root

svn: E02: Working copy database '/subv_repos/ais_repos/.svn/wc.db' not
found

svn: E02: Additional errors:

svn: E02: Can't open file '/subv_repos/ais_repos/.svn/entries': No such
file or directory

 

RE: Subversion exception report

[Bert Huijben]

> -Original Message-
> From: Andreas Stieger [mailto:andreas.stie...@gmx.de]
> Sent: vrijdag 19 februari 2016 10:58
> To: Carlos Hernandez Alaniz 
> Cc: users@subversion.apache.org
> Subject: Re: Subversion exception report
> 
> Hello,
> 
> Carlos Hernandez Alaniz wrote:
> > In file
> >  'D:\Development\SVN\Releases\TortoiseSVN-
> 1.9.1\ext\subversion\subversion\libsvn_client\commit_util.c'
> >  line 1197: assertion failed (svn_dirent_is_absolute(base_dir_abspath))
> 
> Please update to the compatible TortoiseSVN 1.9.3 (with svn 1.9.3) and try
> again.
> 
> > I had two copies of a repository and didn't notice I was
> > trying to commit two files from one, and one file from the other.
> 
> Could you describe this in more detail please?

By checking the sourcecode, I think this issue is reproducable by committing 
files from two different drives on Windows.

$ F:\>svn ci f:\svn-dev\dev g:\brk
svn: E235000: In file '..\..\..\subversion\libsvn_client\commit_util.c' line 
1197: assertion failed (svn_dirent_is_absolute(base_dir_abspath))

Confirmed with 1.9.3.

Bert

RE: files always reported as reverted for different owner

[Bert Huijben]

> -Original Message-
> From: Oleksiy Zagorskyi [mailto:zalex...@i.ua]
> Sent: zondag 14 februari 2016 13:31
> To: users@subversion.apache.org
> Subject: files always reported as reverted for different owner
> 
> Is that ok?
> 
> When I do "svn revert" using for example "root" account, but files in
> the folder are owned by different user, then every file is reported as
> reverted but actually there is nothing to be reverted?
> Such wrong messages mislead a lot!
> 
> An example:
> root@it0:/zab/www-dev/trunk# whoami
> root
> 
> root@it0:/zab/www-dev/trunk# ls -l users.php
> -rw-r--r-- 1 zalex zalex 13689 Jan 18 16:00 users.php
> 
> root@it0:/zab/www-dev/trunk# svn st
> 
> root@it0:/zab/www-dev/trunk# svn revert users.php
> Reverted 'users.php'
> 
> root@it0:/zab/www-dev/trunk# svn revert users.php
> Reverted 'users.php'
> 
> root@it0:/zab/www-dev/trunk# svn revert users.php
> Reverted 'users.php'
> 
> 
> In short to reproduce: a file owner and "svn revert" command issuer are
> different users.

Subversion doesn't check file ownership (as there is no platform independent 
way to do this), so there must be some different reason why you see that you 
can revert multiple times.

(I'm unable to reproduce your issue with just your script)


Which Subversion version did you try this with?

Does the file have any specific 'svn:' properties set on it?

I'm guessing that it has a 'svn:eol-style' set on it.
The only known reproducible case of this issue involves getting a non-standard 
encoded EOL in your repository, with an eol-style defined that should convert 
it to another style.


Bert

RE: Commit Error using ms onedrive repo

[Bert Huijben]

> -Original Message-
> From: dennisj2 [mailto:djorge...@gmail.com]
> Sent: zondag 14 februari 2016 01:22
> To: users@subversion.apache.org
> Subject: Commit Error using ms onedrive repo
> 
> I have a basic cloud setup, primary windows 10 client with onedrive
> installed, and a remote server pointing to the onedrive url - I have full
> access to the repository and can update, export, et.al., but cannot commit
> changes made on the remote server. I get the following errors:
> 
> 
> 
> Thought this was going to be easy, thought wrong. Help?

file:/// access to a repository really needs a real filesystem behind the
local path you use. Onedrive (when mapped as a drive letter) doesn't provide
the proper filesystem semantics needed to directy store a Subversion
filesystem.

I wouldn't recommend storing a Subversion repository in a local directory
shadowed to onedrive/dropbox/other-store via its app either, as that doesn't
provide the necessary guarantees either.

Subversion really needs full read, write, lock, move, etc. access to the
repository to guarantee stable behavior.

If you want to run Subversion against some cloud you should install some
server (Apache Httpd, svnserve) in the cloud and use a proper network layer
to access it. File based repository access isn't designed for that scenario,
and will most likely cause problems if you somehow get it running... 


The documentation even documents that you shouldn't run repositories on
network drives that don't provide the necessary ACID behavior.

Bert

RE: svnversion output changed when redirecting the output. Why?

[Bert Huijben]

This is a known issue with some slightly older builds of TortoiseSVN.

 

Please upgrade and otherwise (re-)report the issue at the TortoiseSVN project 
as this is (was) caused by their specific build scripts.

 

This issue is (was) caused by linking and using multiple CRT instances inside 
the same program, causing undefined behavior inside Visual C++ code.

 

Bert

 

From: Steenveld, Andre [mailto:a.h.m.steenv...@marin.nl] 
Sent: woensdag 10 februari 2016 16:09
To: users@subversion.apache.org
Subject: svnversion output changed when redirecting the output. Why?

 

Hi,

 

I’m working with svn (via TortoiseSVN) versions 1.7, 1.8 and 1.9 and due to 
external factors I cannot bring it up to the same version.

Also, I’m using svn via the TortoiseSVN package but I believe that my question 
is related to svn and not to TortoseSVN, please correct me it this is not the 
case.

 

I use the svnversion command to keep track of versions in my sandboxes. For 
this I redirect the output from svnversion to a file and use that file in other 
parts.

 

For versions 1.7 and 1.8 the command line output from svnversion is identical 
to the redirected output. But for version 1.9 it is not and there is no command 
line option to get it to the `old style’ output.

 

Here is an example for 1.8

C:\…> svnversion .

22923:22924M

 

C:\...>svnversion . > output.txt

C:\...>type output.txt

22923:22924M

 

And here is the same example but now for 1.9

C:\…> svnversion .

22923:22924M

 

C:\...>svnversion . > output.txt

C:\...>type output.txt

M

22923:22924

 

Note that if the sandbox is not modified the first line is an empty one.

 

Question:

Why is the M (sandbox modified) on a separate line?

How do I get ‘1.8’ behavior back for this 1.9 version of svnversion?

 

Kind regards.


André Steenveld | Software Engineer | Production Onderhoud, Ontwikkeling & 
Support
MARIN | T +31 317 49 34 30 | a.h.m.steenv...@marin.nl 
  | www.marin.nl  

    
      
 
MARIN news: Viscous free-surface power predictions for self-propulsion using a 
hybrid RANS-BEM coupling procedure 

  

RE: Question to svn merge (merge just parts of a diff)

[Bert Huijben]

> -Original Message-
> From: Kai Behncke [mailto:kai.behn...@uni-osnabrueck.de]
> Sent: dinsdag 9 februari 2016 07:49
> To: users@subversion.apache.org
> Subject: Question to svn merge (merge just parts of a diff)
> 
> Dear users,
> 
> I`m quite new to svn. I would like to know it the following in svn is
> possible:
> 
> 
> 
> I have in (let`s say Revision 2) a file, that I have changed onetime (I
> deleted "B"), with the following content now:
> A
> C
> D
> 
> Then, in Revision 3 an automatic update occurs. The new file has the
> content:
> A
> B
> E
> 
> ...that means that some changes, that I made, are overwritten now. But
> that should not be.

If all these versions were just committed and updated via the repository, this 
is the intended behavior and there is nothing you can do about it. If on update 
the local file is unmodified, the file is replaced by the new version. I can't 
think of a version management system that does this differently. No merging 
happens in this situation

If you have local changes, and then an update comes in with changes, you have a 
different situation. In that case we start a merge operation, that may or may 
not complete automatically depending on the combination of local and remote 
changes. You can even configure your own 3-way-merge tool to handle this merge 
step by your own tool in the config file.


> 
> 
> A diff between 2 and 3 would show someting like:
> A
> -C
> -D
> +B
> +E

If everything is committed, then this is unrelated information. It is local 
modified vs unmodified that handles the first step.

Otherwise updates that skip revisions aren't possible, etc. etc.


I think you need a more complete sample, perhaps even as a pseudo-script to 
describe what you really want to ask.

Bert

> 
> Is there a possibility to do (for Revision 4) a "svn merge" to get a new
> file, that:
> 
> * "knows" that B has been deleted before, so it will not be reintegrated
> *  does not delete  C and D (I would like to declare s.th. like: Don`t
> delete anything that has been added in a former revision)
> * integrates E (as a new entry, that has not been in any former version)
> 
> so that a result like:
> A
> C
> D
> E
> 
> ...comes out?
> What I mean is: Is it possible to "have a look to a diff" and then
> analyze automatically by the system the single-diff parts
> to set some rules if the single diff-parts should be integrated or not?
> 
> Thank you very much, Kai
> --
> 
> Dr. Kai Behncke
> Zentrum für Informationsmanagement und virtuelle Lehre
> Raum 42/06, Heger-Tor-Wall 12, 49074 Osnabrück
> Telefon: +49 (0)541/969-6505
> http://www.virtuos.uni-osnabrueck.de

RE: Subversion crashes on list with an empty format 3 repo

[Bert Huijben]

> -Original Message-
> From: Daniel Shahaf [mailto:danie...@apache.org]
> Sent: zondag 7 februari 2016 01:22
> To: Michael Osipov 
> Cc: Ivan Zhakov ; users@subversion.apache.org
> Subject: Re: Subversion crashes on list with an empty format 3 repo
> 
> Michael Osipov wrote on Fri, Feb 05, 2016 at 23:34:16 +0100:
> > Am 2016-02-05 um 22:10 schrieb Ivan Zhakov:
> > >'vn: E160033: Invalid name for FS type 'fsfs
> > >]]]
> > We know now that the repo is mangled. The output of the last line is
> broken
> > btw. It should read "svn:... 'fsfs'" but it reads "'vn:...'fsfs". Shall a I
> > create a JIRA issue for that?
> 
> Yes, please.  We should be escaping the \r character rather than
> printing it literally.
> 
> The root problem is that we just use the equivalent of apr_psprintf("The
> value is '%s'", value) to enter replaceables into error messages; we
> don't escape the argument to %s, nor do we use a format code (like
> the %r and {!r} of Python's string formatting or the %q of the printf(1)
> builtin of bash and zsh) that implements single-quoting-and-escaping itself.
> 
> >>> print("The value is '%s'." % ('fsfs\x0D',))
> '.e value is 'fsfs
> >>> print("The value is %r." % ('fsfs\x0D',))
> The value is 'fsfs\r'.
> 
> > I have unzipped the repo on:
> > FreeBSD bsd10 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r28: Wed Aug
> 12
> > 15:26:37 UTC 2015
> r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
> > amd64
> >
> > and I receive the very same error as you do.
> 
> That's not surprising: the fs-type file has a CRLF line ending, and on
> FreeBSD the CR wouldn't be removed.
> 
> Does 'svnadmin create' use CRLF for the fs-type file on windows?  It
> should probably use LF to make the format entirely platform-independent.

No, it uses a LF only, like on other platforms. (I think that should be clear 
about this bug report... We fail when we have a file with that byte sequence we 
never create ourselves). We open most text files as binary in the libsvn_* code 
on Windows. (Note that we use the other default in our python testsuite)

It is probably nice to fix this specific case as it is above the FS layer, but 
I don't think we should really start to look at fsfs as EOL agnostic.

Bert

RE: Svn 1.9 repository 20% bigger than svn 1.8 repository

[Bert Huijben]

> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: maandag 1 februari 2016 11:11
> To: Philip Martin 
> Cc: Stefan Fuhrmann ; Gert Kello
> ; users@subversion.apache.org
> Subject: Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
> 
> On Mon, Feb 01, 2016 at 10:06:19AM +, Philip Martin wrote:
> > Stefan Fuhrmann  writes:
> >
> > > So, all user content is there and merely the deduplication failed
> > > (as already being investigated elsewhere in this thread).
> >
> > I suppose format 7 might allow us to implement a system that fixes
> > missing deduplication during packing.
> 
> And perhaps get rid of sqlite in the repository while at it?

I think at least that last part will require a format 8. Optimizing pack
should (theoretically) be possible without a format bump. We could even
backport changes that allow this, but I'm still waiting on real world test
experience with format 7. 

There are still far too many users delaying their upgrades to 1.9 waiting
for others to switch :(

Waiting for the ASF to perform a major upgrade is on reason I hear quite
often...

Bert

RE: Svn 1.9 repository 20% bigger than svn 1.8 repository

[Bert Huijben]

> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: donderdag 28 januari 2016 13:38
> To: Gert Kello 
> Cc: users@subversion.apache.org
> Subject: Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
> 
> Gert Kello  writes:
> 
> > I have a svn 1.9 repository, created with svnsync, that has ~15
> > revisions and size about 45 GB. Due to some issues in
svn-all-fast-export I
> > wanted to have svn 1.8 version repository so I downgraded it by doing
> > svnadmin (v 1.9) dump /svnadmin (v 1.8) load cycle. I was surprised that
> > the size of v 1.8 repository is "only" 37.5 GB
> > I tried to compare content of db\revs folder: some files are bigger in
1.8
> > repo, some in 1.9 repo.

Just to be sure: that 1.9 repository was recently created with 1.9 and then
loaded via svnsync?

Or was it upgraded from previous versions?

Did you try to svnadmin load the same repository into a new 1.9 repository?
(I would be interested in that result). 1.9 should also be able to create
repositories compatible with older versions.

You might have a very interesting testcase at hand :-)

But with such a size repository it might be hard to test different variants.

Bert

RE: Compiling ZLIB for svn 1.9.3 on Windows 7 using MSVC 2008

[Bert Huijben]

> -Original Message-
> From: Stefan Hett [mailto:ste...@egosoft.com]
> Sent: maandag 4 januari 2016 11:41
> To: users@subversion.apache.org
> Subject: Re: Compiling ZLIB for svn 1.9.3 on Windows 7 using MSVC 2008
> 
> On 12/31/2015 10:31 AM, Cooke, Mark wrote:
> >> -Original Message-
> >> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> >> Sent: 30 December 2015 18:59
> >>
> >> On 30 December 2015 at 19:06, Cooke, Mark
>  wrote:
> >>> [Updates below]
> >>>
>  -Original Message-
>  From: Cooke, Mark [mailto:mark.co...@siemens.com]
>  Sent: 30 December 2015 15:56
> 
>  Folks,
> 
>  I was having issues compiling httpd and svn for use with Trac (via the
>  python 2.7 bindings).  I have compiled httpd 2.4.18 (with apr 1.5.1,
>  apr-util 1.5.4, apr-iconv 1.2.1, openssl 1.0.2e, pcre 1.3.8 and
>  mod_wsgi 4.4.21) and am now trying to compile svn.
> 
>  I noted the comments about zlibstat and ZLIB_WINAPI [1][2], so I
> edited:
>  - zconf.h (added #define ZLIB_WINAPI)
>  - bld_ml32.bat (added the /safeseh switch to both lines)
>  ...and ran:
>  - vcbuild /rebuild contrib\vstudio\vc9\zlibvc.sln "Release|Win32"
> 
>  This seems to compile OK so I copied the zlibstat.lib up to the zlib 
>  root.
> 
>  [1] http://svn.apache.org/repos/asf/subversion/trunk/INSTALL
> (section E4
>  ZLib)
>  [2] http://www.tannerhelland.com/5076/compile-zlib-winapi-wapi-
> stdcall/
> 
>  Next I built SERF 1.3.8:
> 
>  [...]
> 
>  In the end I got it running by _removing_ all the ZLIB_WINAPI
>  defines in the Visual Studio project files and _not_ defining
>  ZLIB_WINAPI in the main config file: this is the opposite of the
>  advice in [1]! Does this sound correct? If so I think the INSTALL
>  file needs updating.
> >>> I get one test failure but it looks bad:-
> >>>
> >>> START: checksum-test.exe
> >>> PASS:  checksum-test 1: checksum parse
> >>> PASS:  checksum-test 2: checksum emptiness
> >>> PASS:  checksum-test 3: zero checksum matching
> >>> svn_tests: E26: Decompressed data doesn't match expected size or
> crc
> >>> with blocksize 17: Found crc32=0x3a74e3ee, size=241883.
> >>> Verify your ZLib installation, as this should never happen
> >>> FAIL:  checksum-test 4: zlib expansion test (zlib regression)
> >> Zlib has known bug in assembly optimized code. Just disable assembly
> >> optimized code in zlib and everything should be fine.
> > Thanks, Ivan, that makes sense.  For the record this is how I got ZLib
> working for me:
> >
> > Unpack archive to \svn\zlib
> > Search/Remove all instances of ZLIB_WINAPI from *.vcproj
> Are you sure this is required? My current build environment suggests
> it's just building/working fine and as intended by adding the
> ZLIB_WINAPI define. That's how it should also work.
> I've to admit that I didn't test it using VS 2008 (but rather 2010 and
> 2015), but I would not expect that having an impact on the reported
> linker error you got.
> Might it be that you compiled another lib which pulled in zlib without
> defining ZLIB_WINAPI? Then that would explain the linker error you are
> reporting.

The ZLIB_WINAPI patch changes the calling convention of the library. 
That is not necessary for Subversion's usage, but it might be necessary if you 
use the same ZLIB dll file from something else. Just make sure both the headers 
and the actual libraries use the same convention or you see huge problems in 
edge scenarios.

In general I would recommend using a normal static compilation of ZLIB for 
Subversion or otherwise one with LTCG enabled, to allow completely inlining 
things in the linker step. That allows even further optimizations than just 
changing the calling convention.

Bert

RE: Unexpected HTTP status 400 'Bad request'.

[Bert Huijben]

Usually you wouldn’t get ‘bad request’ errors from httpd unless Subversion 
sends a bad request. Server side errors as disk io are usually reported by 
other error codes, such as 500.

 

Most bad cases of status 400 are caused by firewall and antivirus products that 
somehow alter requests in unexpected ways. Another ‘expected’ case of this 
error is when Subversion sends too many headers to the server; we see this in 
some commits of subtrees with hundreds of locks. The investigation for this 
error code should start in the server log.

 

Except for that too much header data, the Subversion client should never 
generate a request that the server thinks is ‘bad’. That is what it tells with 
status 400.

 

But as noted before: more details should be in the server log (and often in the 
response body itself… but if there was usable data there Subversion should have 
noted that)

 

Bert

 

From: Yves Martin [mailto:ymartin1...@gmail.com] 
Sent: dinsdag 8 december 2015 11:06
To: users@subversion.apache.org
Subject: Re: Unexpected HTTP status 400 'Bad request'.

 

 Hello​

 

Is your repository served read-write by other services like svnserve or 
eventually through SSH in addition to Apache HTTPS access ?

 

If so you have to check your repository file permissions: owner, group and 
modes (for instance g+w or g+s...)

 

I guess your repository has been created long ago with a previous version of 
Subversion.

What is your repository format version ? Are some revisions packed ? Use 
svnadmin info.

 

Maybe you should use "svnadmin upgrade" to get some new features properly 
enabled with Subversion 1.9,

or even use dump/load procedure (or svnsync) to get your repository ready (and 
optimized) for Subversion 1.9.

 

Regards

-- 

Yves Martin

RE: Unexpected HTTP status 400 'Bad request'.

[Bert Huijben]

These are both about bodies… The headers causing that lock problem are not part 
of the body. 

 

There is probably another configuration knob for them.

 

Bert

 

From: Yves Martin [mailto:ymartin1...@gmail.com] 
Sent: dinsdag 8 december 2015 12:10
To: Subversion 
Subject: Re: Unexpected HTTP status 400 'Bad request'.

 

 Hello,

 

In my Apache2 configuration, I have added "LimitRequestBody 0" and 
"LimitXMLRequestBody 0" to avoid such troubles with a 12-year-old-really-large 
repository...

 

Hope this helps

Regards

-- 

Yves Martin

 

 

RE: Unexpected HTTP status 400 'Bad request'.

[Bert Huijben]

This is just the Subversion operational log generated by mod_dav_svn. The 
interesting things would be in the apache access and/or error logs.

(Depending on the configuration of your apache these could be the same logfile)

 

The operational log just shows successful Subversion operations, so that 
doesn’t tell us much why a request failed.

 

Bert

 

 

From: Chris Capon [mailto:ttab...@gmail.com] 
Sent: dinsdag 8 december 2015 15:29
To: users@subversion.apache.org
Subject: Re: Unexpected HTTP status 400 'Bad request'.

 

Hi Bert.
The only log I know of is under /var/log/apache2/subversion.log, and when I 
issue a checkout, I get only two lines in it:

[08/Dec/2015:09:24:53  -500] myself get-inherited-props /dev/trunk r3066
[08/Dec/2015:09:24:53  -500] myself checkout-or-export /dev/trunk r3066

If the error were caused by a firewall or antivirus software, would it still 
make sense that the checkout begins and gets several files in before failing?  
Also, to try and eliminate that possibility, I've been performing the checkout 
tests on the subversion server machine.

On 2015-12-08 05:37, Bert Huijben wrote:

Usually you wouldn’t get ‘bad request’ errors from httpd unless Subversion 
sends a bad request. Server side errors as disk io are usually reported by 
other error codes, such as 500.

 

Most bad cases of status 400 are caused by firewall and antivirus products that 
somehow alter requests in unexpected ways. Another ‘expected’ case of this 
error is when Subversion sends too many headers to the server; we see this in 
some commits of subtrees with hundreds of locks. The investigation for this 
error code should start in the server log.

 

Except for that too much header data, the Subversion client should never 
generate a request that the server thinks is ‘bad’. That is what it tells with 
status 400.

 

But as noted before: more details should be in the server log (and often in the 
response body itself… but if there was usable data there Subversion should have 
noted that)

 

Bert

 

From: Yves Martin [ <mailto:ymartin1...@gmail.com> 
mailto:ymartin1...@gmail.com] 
Sent: dinsdag 8 december 2015 11:06
To:  <mailto:users@subversion.apache.org> users@subversion.apache.org
Subject: Re: Unexpected HTTP status 400 'Bad request'.

 

 Hello​

 

Is your repository served read-write by other services like svnserve or 
eventually through SSH in addition to Apache HTTPS access ?

 

If so you have to check your repository file permissions: owner, group and 
modes (for instance g+w or g+s...)

 

I guess your repository has been created long ago with a previous version of 
Subversion.

What is your repository format version ? Are some revisions packed ? Use 
svnadmin info.

 

Maybe you should use "svnadmin upgrade" to get some new features properly 
enabled with Subversion 1.9,

or even use dump/load procedure (or svnsync) to get your repository ready (and 
optimized) for Subversion 1.9.

 

Regards

-- 

Yves Martin

 

RE: Unexpected HTTP status 400 'Bad request'.

[Bert Huijben]

> -Original Message-
> From: Chris Capon [mailto:ttab...@gmail.com]
> Sent: dinsdag 8 december 2015 14:47
> To: users@subversion.apache.org
> Subject: Re: Unexpected HTTP status 400 'Bad request'.
> 
> On 2015-12-08 05:06, Yves Martin wrote:
> >  Hello​
> >
> > Is your repository served read-write by other services like svnserve
> > or eventually through SSH in addition to Apache HTTPS access ?
> I'm sorry.  I don't understand what this asks.  Permissions are
> controlled by a .apache_auth and .apache_htpasswd file (in addition to
> client certificates).  The .apache_auth file has the folder defined as
> 'rw' for my user id.
> >
> > If so you have to check your repository file permissions: owner, group
> > and modes (for instance g+w or g+s...)
> All the file level permissions are set to rwxr-xr-x (755) and both owner
> and group are www-data, the user id under which the Apache2 service runs.
> >
> > I guess your repository has been created long ago with a previous
> > version of Subversion.
> > What is your repository format version ? Are some revisions packed ?
> > Use svnadmin info.
> Repository Format: 5
> Compatible With Version: 1.9.0
> Repository Capability: mergeinfo
> Filesystem Type: fsfs
> Filesystem Format: 7
> FSFS Sharded: yes
> FSFS Shard Size: 1000
> FSFS Shards Packed: 0/3
> FSFS Logical Addressing: no
> Configuration File: /root/subversion/root/repository/db/fsfs.conf
> 
> >
> > Maybe you should use "svnadmin upgrade" to get some new features
> > properly enabled with Subversion 1.9,
> After running
>  svn upgrade /root/subversion/root/repository
> 
> The response was "Upgrade completed."  But an svn checkout gives the
> same error:
> 
> svn: E175002: Unexpected HTTP status 4000 'Bad request' on
> '/svn/repository/!svn/rvr/1903/dev...'
> 
> Again, at a random file about 5 or 6 files in.
> > or even use dump/load procedure (or svnsync) to get your repository
> > ready (and optimized) for Subversion 1.9.
> We tried this in a previous e-mail (see for details).

Are you using some kind of (caching) proxy server when you connect to the 
server?

You are focusing your search to a disk problem (probably caused by hints on 
this list), while you are trying to determine what causes a 'bad HTTP request' 
error.

Bad requests on these urls may be caused by sending bad header values... I've 
seen those before when using nginx as proxy with a too strict caching policy.

Bert

RE: API for creating file and revision

[Bert Huijben]

In this context we use the word 'text' for the body/content/whatever is in
the file, so you don't have to use separate functions.

 

On the fs and repos layers we don't handle binary and textual files in
different ways. 

 

Where we do at the client level we usually use a few properties if we want
to make the behavior explicit.

 

Bert

 

From: Ren Wang [mailto:renwang...@gmail.com] 
Sent: woensdag 25 november 2015 13:27
To: users@subversion.apache.org
Subject: API for creating file and revision

 

First of all, I would like to express my appreciation for the support from
the community in the past few days. 

 

Here are some more another questions:

 

The API svn_fs_make_file() will create an empty file, and the
svn_fs_apply_text() will fill the text content to the repository. Is there a
similar API for setting binary content?

 

If the file already created in the repository, what's the API to create a
revision of it?

 

Regards,

 

Ren

 

 

 

 

 

 

 

RE: svn_repos_fs_commit_txn error

[Bert Huijben]

> -Original Message-
> From: Branko Čibej [mailto:br...@apache.org]
> Sent: dinsdag 24 november 2015 06:13
> To: users@subversion.apache.org
> Subject: Re: svn_repos_fs_commit_txn error
> 
> On 23.11.2015 21:01, Ren Wang wrote:
> > I got an error for creating a new directory to the repository. Strange to me
> > is that enve the code failed at the svn_repos_fs_commit_txn, but the
> > directory got created:
> >
> >
> >
> >
> >
> > 1)  Open repository, repos
> >
> > 2)  Get the latest revision, youngest
> >
> > 3)  Do the following:
> >
> > svn_fs_txn_t *txn;
> >
> > svn_fs_root_t *txn_root;
> >
> > apr_pool_t *subpool = svn_pool_create(pool);
> >
> > SVN_ERR(svn_repos_fs_begin_txn_for_commit(, ,
> youngest_rev,
> > "UncleYinan", "log msg", subpool));
> >
> > SVN_ERR(svn_fs_txn_root(_root, txn, subpool));
> >
> > SVN_ERR(svn_fs_make_dir(txn_root, directoryPath, subpool));
> >
> > SVN_ERR(svn_repos_fs_commit_txn(NULL, c->repos, _rev, txn,
> > subpool));-- failed here

This may be 100% expected... see the documentation of this function.
Especially the part
[[
* A successful commit is indicated by a valid revision value in @a
 * *new_rev, not if svn_fs_commit_txn() returns an error, which can
 * occur during its post commit FS processing.  If the transaction was
 * not committed, then return the associated error and do not execute
 * the post-commit hook.
]]

For completeness I copied the documentation from svn_repos.h here:

/** Like svn_fs_commit_txn(), but invoke the @a repos' pre- and
 * post-commit hooks around the commit.  Use @a pool for any necessary
 * allocations.
 *
 * If the pre-commit hook fails, do not attempt to commit the
 * transaction and throw the original error to the caller.
 *
 * A successful commit is indicated by a valid revision value in @a
 * *new_rev, not if svn_fs_commit_txn() returns an error, which can
 * occur during its post commit FS processing.  If the transaction was
 * not committed, then return the associated error and do not execute
 * the post-commit hook.
 *
 * If the commit succeeds the post-commit hook is executed.  If the
 * post-commit hook returns an error, always wrap it with
 * SVN_ERR_REPOS_POST_COMMIT_HOOK_FAILED; this allows the caller to
 * find the post-commit hook error in the returned error chain.  If
 * both svn_fs_commit_txn() and the post-commit hook return errors,
 * then svn_fs_commit_txn()'s error is the parent error and the
 * SVN_ERR_REPOS_POST_COMMIT_HOOK_FAILED wrapped error is the child
 * error.
 *
 * @a conflict_p, @a new_rev, and @a txn are as in svn_fs_commit_txn().
 */
svn_error_t *
svn_repos_fs_commit_txn(const char **conflict_p,
svn_repos_t *repos,
svn_revnum_t *new_rev,
svn_fs_txn_t *txn,
apr_pool_t *pool);

--
Bert

RE: svnlook changed doesn't include all of the files that are part of the commit

[Bert Huijben]

Diff reports copies of directories as adds of the individual files, while
svnlook changed reports a copy on the root and only interesting changes
below that. Just like how 'svn status' would have reported it before the
commit.

 

Bert

 

From: Hartleroad, James [IT] [mailto:james.hartler...@sprint.com] 
Sent: maandag 23 november 2015 15:30
To: users@subversion.apache.org
Subject: svnlook changed doesn't include all of the files that are part of
the commit

 

Why doesn't svnlook changed show all of the files that are part of the
commit?

 

A developer created a new directory with two files in a branch and the
branch was merged into another branch.  When running svnlook it shows the
directory was added, but not the included files.  If I run a svn diff with
the summarize option it does list the files, so shouldn't svnlook include
them too?

 

svnlook changed -r5596 /data/ans/repos/r4BN

_U  4BN/cmblds/1551-MID16.1.2.0/

A
4BN/cmblds/1551-MID16.1.2.0/4BN_Envs/dev/ReleaseChanges/MID16.1.2_Release_Ch
anges.txt

_U  4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/DB_Scripts/

A   4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/DB_Scripts/MID16.1.2/

_U  4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/LDAP_Scripts/

A   4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/LDAP_Scripts/MID16.1.2/

 

 

svn diff -r5595:5596 --summarize file:///data/ans/repos/r4BN
 

A
file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_Envs/dev/Release
Changes/MID16.1.2_Release_Changes.txt
 

A
file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/LDAP
_Scripts/MID16.1.2/MID16.1.2_PJ019964_Epic363_Add_New_Programs.ldif
 

A
file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/LDAP
_Scripts/MID16.1.2
 

M
file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/LDAP
_Scripts
 

A
file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/DB_S
cripts/MID16.1.2/MID16.1.2_PJ019964_Epic363_AUTO_ACTIVITY_WRKFLW_TASK_DML_Ch
anges.sql
 

A
file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/DB_S
cripts/MID16.1.2/MID16.1.2_PJ019964_Epic363_ADD_New_Programs_DML_Changes.sql
 

A
file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/DB_S
cripts/MID16.1.2
 

M
file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/DB_S
cripts
 

M  file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0
 

 

 

 

  _  


This e-mail may contain Sprint proprietary information intended for the sole
use of the recipient(s). Any use by others is prohibited. If you are not the
intended recipient, please contact the sender and delete all copies of the
message.

RE: how to get node property by using C API

[Bert Huijben]

There should be an api for the size. Author, creation info, etc. are
attached to the revision in which the file was created.

 

Bert

 

From: Ren Wang [mailto:renwang...@gmail.com] 
Sent: vrijdag 20 november 2015 16:19
To: users@subversion.apache.org
Subject: how to get node property by using C API

 

I would like to know how to get a directory or file property with Subversion
C API, if I already have the node ID and path, what's the API to get file
size and author, creation time etc.?

 

Regards,

 

Ren

RE: Subversion C API

[Bert Huijben]

Mod_dav mostly uses the repository layer api. In a few specific cases it
goes into the fs layer directly. sometimes because something isn't mapped,
but in other cases because mod_dav was developed very early in the
development process and the repository layer wasn't as complete as it is
today.

 

But is the client layer really that expensive for you that you can't use it?
Did you measure it?

 

I can't imagine usecases where the performance is that critical that you
really can't afford the thin layer that the file:/// repository api has, but
don't want a specialized datastore 100% optimized for your usecase.

 

I can think of a few cases where you might want to avoid the overhead of
having a working copy, but even there the costs aren't usually that high
that it makes sense to spend a lot of time to develop something else.

(And in many cases the still private API behind svnmucc can already help you
there)

 

Bert

 

From: Ren Wang [mailto:renwang...@gmail.com] 
Sent: vrijdag 6 november 2015 19:44
To: users@subversion.apache.org
Subject: Subversion C API

 

I have posted the same question to the stackoverflow, here it is. Looking
forward to hear from you:

 

We are considering to use Subversion as the file system layer to store
version enabled documents. Since the security function will be handled by
other code, I am considering to directly use the Subversion FS C API layer.
I wonder if there any good sample code for using Subversion FS APIs?

 

Someone answered back:

Subversion's FSFS store is meant to be used by the subversion server. While
it might be useable in other scenarios, whatever sits on top of it will
likely have to act much like a subversion server when interacting with it.
Subversion differentiates between client workspaces and the server storage
space. If you are going to leverage subversion components, your application
needs to realize that these two spaces are not the same within a subversion
architecture, and therefore should not be the same within your solution that
uses their components.

Why not just embed a subversion client into the place you desire and then go
from there? The user workspace will still be "the subversion user workspace"
and the server side will be the server side. In fact, check out tortise SVN
(or other desktop integrations of subversion). You might not even need to
write anything.

I asked again with more context for the project:

SVN Client API will have performance penalty since it will go through other
layers such as user authentications, authorizations, transport etc. which
are not needed for us. Subversion server side API will bypass those calls. I
wonder which API mod_dav_svn used.

Regards,

Ren

 

RE: subversion 1.9.2 could not be built "all-static" on FreeBSD 10+

[Bert Huijben]

> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: maandag 19 oktober 2015 13:22
> To: 'Philip Martin' <philip.mar...@wandisco.com>; 'Lev Serebryakov'
> <l...@freebsd.org>
> Cc: 'Daniel Shahaf' <d...@daniel.shahaf.name>;
> users@subversion.apache.org
> Subject: RE: subversion 1.9.2 could not be built "all-static" on FreeBSD
10+
> 
> 
> 
> > -Original Message-
> > From: Philip Martin [mailto:philip.mar...@wandisco.com]
> > Sent: maandag 19 oktober 2015 11:19
> > To: Lev Serebryakov <l...@freebsd.org>
> > Cc: Daniel Shahaf <d...@daniel.shahaf.name>;
> users@subversion.apache.org
> > Subject: Re: subversion 1.9.2 could not be built "all-static" on FreeBSD
> 10+
> >
> > Lev Serebryakov <l...@freebsd.org> writes:
> >
> > > Hello Daniel,
> > >
> > > Sunday, October 18, 2015, 11:08:45 AM, you wrote:
> > >
> > >>>  I could not build subversion 1.9.2 with "--enable-all-static" on
> FreeBSD.
> > >>> "configure" script forms wron arguments to ${CC} in this case and
> fails to
> > >>> find any library.
> > >>>
> > >>>  Here is couple of lines from config.log for 1.9.2:
> > >>>
> > >>> configure:6130: checking for sqlite3_close in -lsqlite3
> > >>> configure:6155: cc -o conftest -Werror=unknown-warning-option -O2
> > >>> -pipe -fpic -DPIC -fstack-protector -fno-strict-aliasing
> > >>> -I/usr/local/include -fstack-protector -L/usr/local/lib
> > >>> -L/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib
> > >>> -R/usr/local/lib -L/usr/local/lib conftest.c -lsqlite3 >&5
> > >>> cc: error: unknown argument: '-R/usr/local/lib'
> > >>> cc: error: unknown argument: '-R/usr/local/lib'
> > >>> configure:6155: $? = 1
> > >
> > >> I assume you're building the 1.9.2 tarball, correct?  Does the
problem
> > >   Yep.
> > >
> > >> also occur if you build from a checkout of the 1.9.2 tag?  (You'll
need
> > >> to run autogen.sh before configure.)
> > >   Yes. Here is version of tools used by autogen.sh:
> > >
> > > buildcheck: autoconf version 2.69 (ok)
> > > buildcheck: autoheader version 2.69 (ok)
> > > buildcheck: libtool version 2.4.6 (ok)
> > >
> > >  And after that same error if "--enable-all-static" is passed.
> >
> > On my FreeBSD 10.1 install I get further than that when I try to build
> > the 1.9.x branch, but linking svn fails due unresolved SSL symbols.  I
> > can fix it by changing LIBS in Makefile to add -lssl -lcrypto.
> >
> > Subversion configure script does not add the -R so I suppose on of the
> > dependencies must be telling Subversion to add it.  What does your
> > configure line look like?  Have you build any of the dependencies
> > yourself?
> 
> I think I found these flags in /usr/local/libdata/pkgconfig/serf-1.pc
> 
> [[
> SERF_MAJOR_VERSION=1
> prefix=/usr/local
> exec_prefix=${prefix}
> libdir=/usr/local/lib
> includedir=${prefix}/include/serf-1
> 
> Name: serf
> Description: HTTP client library
> Version: 1.3.8
> Requires.private:
> Libs: -L${libdir} -lserf-${SERF_MAJOR_VERSION}
> Libs.private: -L/usr/local/lib -R/usr/local/lib -laprutil-1  -ldb-5.3
-lgdbm
> -lexpat -L/usr/local/lib -R/usr/local/lib -lapr-1 -lcrypt  -lpthread  -lz
> -L/usr/lib -lssl -lcrypto
> Cflags: -I${includedir}
> ]]

And now including dev@serf, as I think this should be fixed there:

It looks like serf gets these flags from:
$ apr-1-config --link-libtool

Which is invoked from SConstruct

[[
### there is probably a better way to run/capture output.
### env.ParseConfig() may be handy for getting this stuff into the build
apr_libs = os.popen(env.subst('$APR --link-libtool
--libs')).read().strip()
if apr_major < 2:
  apu_libs = os.popen(env.subst('$APU --link-libtool
--libs')).read().strip()
else:
  apu_libs = ''
]]

And at this point I don't know what this is supposed to do.

Bert

RE: subversion 1.9.2 could not be built "all-static" on FreeBSD 10+

[Bert Huijben]

> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: maandag 19 oktober 2015 11:19
> To: Lev Serebryakov 
> Cc: Daniel Shahaf ; users@subversion.apache.org
> Subject: Re: subversion 1.9.2 could not be built "all-static" on FreeBSD
10+
> 
> Lev Serebryakov  writes:
> 
> > Hello Daniel,
> >
> > Sunday, October 18, 2015, 11:08:45 AM, you wrote:
> >
> >>>  I could not build subversion 1.9.2 with "--enable-all-static" on
FreeBSD.
> >>> "configure" script forms wron arguments to ${CC} in this case and
fails to
> >>> find any library.
> >>>
> >>>  Here is couple of lines from config.log for 1.9.2:
> >>>
> >>> configure:6130: checking for sqlite3_close in -lsqlite3
> >>> configure:6155: cc -o conftest -Werror=unknown-warning-option -O2
> >>> -pipe -fpic -DPIC -fstack-protector -fno-strict-aliasing
> >>> -I/usr/local/include -fstack-protector -L/usr/local/lib
> >>> -L/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib
> >>> -R/usr/local/lib -L/usr/local/lib conftest.c -lsqlite3 >&5
> >>> cc: error: unknown argument: '-R/usr/local/lib'
> >>> cc: error: unknown argument: '-R/usr/local/lib'
> >>> configure:6155: $? = 1
> >
> >> I assume you're building the 1.9.2 tarball, correct?  Does the problem
> >   Yep.
> >
> >> also occur if you build from a checkout of the 1.9.2 tag?  (You'll need
> >> to run autogen.sh before configure.)
> >   Yes. Here is version of tools used by autogen.sh:
> >
> > buildcheck: autoconf version 2.69 (ok)
> > buildcheck: autoheader version 2.69 (ok)
> > buildcheck: libtool version 2.4.6 (ok)
> >
> >  And after that same error if "--enable-all-static" is passed.
> 
> On my FreeBSD 10.1 install I get further than that when I try to build
> the 1.9.x branch, but linking svn fails due unresolved SSL symbols.  I
> can fix it by changing LIBS in Makefile to add -lssl -lcrypto.
> 
> Subversion configure script does not add the -R so I suppose on of the
> dependencies must be telling Subversion to add it.  What does your
> configure line look like?  Have you build any of the dependencies
> yourself?

I think I found these flags in /usr/local/libdata/pkgconfig/serf-1.pc

[[
SERF_MAJOR_VERSION=1
prefix=/usr/local
exec_prefix=${prefix}
libdir=/usr/local/lib
includedir=${prefix}/include/serf-1

Name: serf
Description: HTTP client library
Version: 1.3.8
Requires.private:
Libs: -L${libdir} -lserf-${SERF_MAJOR_VERSION}
Libs.private: -L/usr/local/lib -R/usr/local/lib -laprutil-1  -ldb-5.3 -lgdbm
-lexpat -L/usr/local/lib -R/usr/local/lib -lapr-1 -lcrypt  -lpthread  -lz
-L/usr/lib -lssl -lcrypto
Cflags: -I${includedir}
]]

Bert

RE: svn segfaults on relocate when having a not checked out external

[Bert Huijben]

Hi,

 

It looks like this issue was already fixed since 1.9.0.

 

Backporting the fix to 1.8 is not trivial (but not that hard either). The 
relevant revision is r1627338.

 

The old code just assumes that svn:externals describes exactly what is in the 
working copy, while the new code checks what is really there. (Will even 
relocate working copies that are still there, but already removed from 
svn:externals)

 

Bert

 

From: Axel Kittenberger [mailto:axk...@gmail.com] 
Sent: dinsdag 6 oktober 2015 13:25
To: users@subversion.apache.org
Subject: svn segfaults on relocate when having a not checked out external

 

Hello, below is my shell script that raises the svn segfault for me.

 

The issue is, doing a relocate while having an external that is not in the 
working copy. It raised for me, since I got one automated instance that 
automatically sets externals for a repository, but does not need to check it 
out itself, so it updates with "--ignore-externals", now I tried to relocate 
that daemons working copy, svn segfaulted. Its no big issue for me, since I can 
always revert to do a full checkout instead, or update without 
--ignore-externals, relocate and delete the externals in the working copy.

 

Still I guess, a segfault never should be not a bug, so I report it.

 

Operating System is Debian Jessie, if you no need any more info just ask.

 

Kind regards,
Axel

~

~$ svn --version

svn, version 1.8.10 (r1615264)

   compiled Aug  9 2015, 13:48:39 on x86_64-pc-linux-gnu

 

Copyright (C) 2014 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.8

  - handles 'http' scheme

  - handles 'https' scheme

~$ mkdir atest

~$ cd atest/

atest$ svnadmin create repository1

atest$ svnadmin create repository2

atest$ svn checkout file:///home/axel/atest/repository1 rep1

Checked out revision 0.

atest$ svn checkout file:///home/axel/atest/repository2 rep2

Checked out revision 0.

atest$ 

atest$ cd rep2/

rep2$ echo "bar" > foo

rep2$ svn add foo

A foo

rep2$ svn commit -m foobar

Adding foo

Transmitting file data .

Committed revision 1.

rep2$ cd ..

atest$ cd rep1/

rep1$ echo "^/../repository2 extrep2" > externals

rep1$ svn propset svn:externals . -F externals

property 'svn:externals' set on '.'

rep1$ svn up

Updating '.':

 

Fetching external item into 'extrep2':

Aextrep2/foo

Updated external to revision 1.

 

At revision 0.

rep1$ cat extrep2/foo 

bar

rep1$ ### everything working as expected so far ###

rep1$ rm -rf extrep2/

rep1$ cd ..

atest$ mv repository1/ namechange1

atest$ cd rep1/

rep1$ svn relocate file:///home/axel/atest/namechange1 

Segmentation fault

rep1$ 

 

 

 

 

This is easily tough circumvented with this. Which once again works as expected:

 

rep1$ svn up

Updating '.':

 

Fetching external item into 'extrep2':

Aextrep2/foo

Updated external to revision 1.

 

At revision 0.

rep1$ svn relocate file:///home/axel/atest/namechange1 

 

 

 

RE: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

[Bert Huijben]

> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Subject: Re: Bug report: The auto-props setting of svn:mime-type is
> impossible to avoid.
> 

> > This whole discussion -in its many iterations- is one of the reasons why
I
> > never looked at enabling this feature on Windows.
> 
> And nobody has been asking for it to be enabled?

I don't remember anybody asking...

I doubt many users explicitly enable it on other platforms either, but we do
an autodetect there, which usually just works.


Bert

RE: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

[Bert Huijben]

> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: zondag 4 oktober 2015 13:32
> To: Edward d'Auvergne 
> Cc: Greg Stein ; users@subversion.apache.org
> Subject: Re: Bug report: The auto-props setting of svn:mime-type is
> impossible to avoid.
> 
> On Sun, Oct 04, 2015 at 12:52:33PM +0200, Edward d'Auvergne wrote:
> > I would maybe suggest introducing an option for disabling the entire
> > automatic property subsystem, i.e. it combines both of these, and
> > overrides them.  This is an interesting thought experiment - devise
> > any name for such a top level automatic property override - and this
> > should convincingly demonstrate the confusion that the current setting
> > names induces.
> 
> I think that would just make the situation worse by adding to
> the current mess.
> 
> I agree the documentation needs to be improved. Would you have time
> to update the documentation and send patches for it?
> 
> > The problem with the svn:mime-type block is that for svn clients <
> > 1.9, 'svn import' can never work.  Specifically because the libmagic
> > layer overwrites any user decision to disable automatic properties.
> 
> There's another trick to disable libmagic which works with all
> client versions. I just tested it with 1.8.
> 
> Set the MAGIC environment variable to a file which does not exist.
> 
>   env MAGIC=/nonexistent svn import ...
> 
> This effectively disabled libmagic support.

For Windows I don't think you need any disabling, as our build doesn't even
support building with libmagic there. (Perhaps somebody patched something in
their own build... but I don't think that is really an interesting
scenario). 

Note that the Cygwin version is an exception to most of this... It is a
Windows build but tries to do everything the unix way.
 
Bert

RE: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

[Bert Huijben]

> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: zondag 4 oktober 2015 22:01
> To: Branko Čibej 
> Cc: users@subversion.apache.org
> Subject: Re: Bug report: The auto-props setting of svn:mime-type is
> impossible to avoid.
> 
> On Sun, Oct 04, 2015 at 09:16:04PM +0200, Branko Čibej wrote:
> > On the other hand, I am surprised that the logic that uses libmagic
> > isn't turned off with 'enable-auto-props=no'. After all, using libmagic
> > is just a convenient extension to the definitions in the [auto-props]
> > section.
> 
> Recall that the idea was to make setting svn:mime-type convenient.
> 
> Before we added this feature, people had to fiddle with their client
> config, know what MIME-types are about, what useful values to set
> them to, and keep their config consistent across all systems they
> used since libmagic support pre-dates the svn:autoprops feature.
> In a sane universe, almost nobody would ever bother setting it up that way.
> 
> I am not opposed to the idea, though. But not because of the fairly
> minor configurability issues raised in this thread. Rather, because
> the more I learn about how libmagic actually works, the more potentially
> dangerous, from the security point of view, it seems to be.
> The libmagic parser could potentially cause security problems whenever
> people are adding untrusted files to SVN. Which is a good reason to make
> this feature opt-in.

I would support changing Subversion to -by default- disable this feature, 
unless it is enabled in the configuration (or some flag passed to 'svn add' in 
1.10+).

I'm not sure if I would call it a security problem when a user adds a file of 
their choosing to Subversion though :-)


This whole discussion -in its many iterations- is one of the reasons why I 
never looked at enabling this feature on Windows.

Bert

RE: Incomplete SVN dump files

[Bert Huijben]

> -Original Message-
> From: Andreas Mohr [mailto:a...@lisas.de]
> Sent: woensdag 16 september 2015 07:48
> To: Eric Johnson 
> Cc: b...@qqmail.nl; users@subversion.apache.org
> Subject: Re: Incomplete SVN dump files
> 
> Hi,
> 
> On Tue, Sep 15, 2015 at 05:26:38PM -0700, Eric Johnson wrote:
> >I just checked, and there aren't any open bugs about this.
> >Interrupting svnrdump can result in a dump file with not all the
files of
> >the last commit in the dump record. Accidentally use that dump file
to
> >load into a new repository, and the resulting repository will not be
a
> >copy of the original.
> >My particular use case, I was trying to suck down a large repository.
> >Connection interrupted part way through. I resumed from part way
through
> >(using the --incremental option) into an additional dump file. Then
did a
> >load of those two dump files. Did not yield a copy of the original
> >repository, though.
> >This seems like a critical issue for possible data loss when copying
> >repositories from machine to machine using svnrdump.
> 
> AFAICS (not an svnrdump expert here) very well described and to the point.
> You just managed to pinpoint a rather important serialization format
> that seemingly isn't fully properly atomically transaction-safe...
> (good catch!)

In some ways a dumpfile is a stream and not a file... and when you use the
commandline tools you always obtain it from stdout.

I could argue that you in that case should check if the operation exited
successfully or with an error.

After an error you can't trust that the final portion is ok.


The stream was also deliberately designed in a way that you can
incrementally generate it... E.g. after each new revision or as a daily
backup operation.

Adding some 'this is the end' marker would break those use cases, that we
have been using since the day subversion was self-hosted. (Long before 1.0)


And when loading from a stream we can't continue reading to the end to see
if there is a final marker, as at that point we aren't able to go back to
the start and start the whole process.
(I've used '$ svn dump  | ssh  svnadmin load ...' more than a few
times for repository migrations)

Bert

RE: 1.9 - Can't resolve to 'mine full' option for binary file conflict

[Bert Huijben]

> -Original Message-
> From: Stefan Hett [mailto:ste...@egosoft.com]
> Sent: maandag 14 september 2015 09:54
> To: users@subversion.apache.org
> Subject: Re: 1.9 - Can't resolve to 'mine full' option for binary file 
> conflict
> 
> On 9/14/2015 7:56 AM, Daniel Becroft wrote:
> > Hi guys,
> >
> >
> > I've just upgraded to SVN 1.9. One of the first things I noticed is
> > that when a binary file conflict is raised during an SVN update, I can
> > no longer use the 'mine-full' option to resolve.
> >
> > The only options I have are: (r) working and (tf) theirs-full.
> >
> > I can't use the 'r' (working) option, as I get a message of "Invalid
> > option; use diff/edit/merge/launch before choosing 'mark resolved'.
> >
> > If I postpone, and try resolving afterwards, I get the following errors;
> > > svn resolve file.binary --accept mine-full
> > svn: warning: W155027: Conflict on 'file.binary' could not be resolved
> > because the chosen version of the file is not available.
> > svn: E155027: Failure occurred resolving one or more conflicts
> >
> > I can't find anything in the release notes about the removal of the
> > 'mine-full' option on binary files. Was it intentional? If so, what's
> > the intended workflow for resolution?
> >
> > Current version:
> > svn, version 1.9.0-SlikSvn (SlikSvn/1.9.0)
> >compiled Aug 26 2015, 17:09:55 on x86/x86_64-microsoft-windows6.2.9200
> >
> > Cheers,
> > Daniel B.
> Hi Daniel,
> 
> just to second ur observation:
> I think I ran into the same problem last Thursday/Friday using TSVN
> 1.9.1. I didn't report it yet because I didn't check out whether it's a
> TSVN or an SVN issue.
> Using TSVN, it however also gives me the "file not found" error when I
> try to resolve a binary conflict selecting "Use Repository version"
> during the merge dialog.
> 
> I'm sure u are already ware, but just in case: My workaround was to let
> the file in conflict and afterwards resolve the conflict by reverting
> the file (so it was in the repository's state which I intended).

In case of a binary file the original working copy version is left as the 
working version, whereas for text conflict the working copy version is changed 
into a mine version and a best effort merge is performed to the a new working 
copy version potentially containing conflict markers.

In this case you probably get the result you want by just choosing the working 
copy version. The Subversion developer responsible for choosing this UI 
determined that it didn't make much sense to offer two different resolve 
options with exactly the same result.

Bert

> 
> --
> Regards,
> Stefan Hett

RE: win32svn for 1.9.1?

[Bert Huijben]

> -Original Message-
> From: Olivier Sannier [mailto:oliv...@obones.com]
> Sent: woensdag 9 september 2015 23:46
> To: users@subversion.apache.org
> Subject: Re: win32svn for 1.9.1?
> 
> On 08/09/2015 18:57, Win32Svn wrote:
> >
> >
> > On 2015-09-08 13:00, Stefan Hett wrote:
> >> On 9/7/2015 10:21 PM, Win32Svn wrote:
> >>> On 2015-09-07 18:59, Barry Scott wrote:
> > On 7 Sep 2015, at 11:43, Andreas Stieger 
> > wrote:
> >
> > Hi,
> >
> > Barry Scott wrote:
> >> I see that the recent 1.7 and 1.8 win32svn builds being
> >> announced, thanks for
> >> them.
> >>
> >> Do you know when the svn 1.9 win32svn build might be available?
> > Available at other binary "vendors":
> > https://subversion.apache.org/packages.html#windows
>  Sadly only win32svn packages the include files that are needed to
>  write
>  code against svn. In my case I use win32svn as the basis of the pysvn
>  win32 build.
> 
>  Barry
> 
> >>>
> >>> Hi Barry!
> >>>
> >>> I'm sorry to say there won't be any 1.9.x build of Win32SVN.
> >>> You can read about it on http://alagazam.net   (click the 1.9.x info
> >>> link on the right)
> >>>
> >>> Regards,
> >>> David Darj  a.k.a. Alagazam
> >>> Maintainer of Win32SVN
> >>> http://alagazam.net
> >>>
> >>> ps.
> >>> If you like my work, please support this project by donating at
> >>> http://sourceforge.net/donate/index.php?group_id=357628
> >>>
> >>
> >> Hi David,
> >>
> >> I'm wondering which particular VS6 issue you are referring to in that
> >> note.
> >> I've been told the only known issues atm not working using VS6 would
> >> be in the javahl code (due to the template code) which I assume is
> >> not the issue you are talking about, or is it?
> >>
> >
> > Hi Stefan
> >
> > I don't remember exactly now, but I gave one of the 1.9.0-alpha a shot
> > with my build scripts (you can find them on sourceforge).
> > There were a lot more compilation errors than in 1.8.x where I've
> > already patched a lot, and the time to look deeper then didn't exist.
> > Maybe there isn't any specific windows api issues or other features,
> > but the old C standard (MS-standard) in VC6 makes the burden, right
> > now at least, to much.
> >
> > Regards,
> > David Darj  a.k.a. Alagazam
> > Maintainer of Win32SVN
> 
> Hello David,
> 
> Do you think it would be possible to migrate the scripts to VC2010?
> I mean, I have it installed and am using it on a regular basis, so I
> could help with building part if need be.

If you try this as a group effort I would recommend directly going to VS
2013 or VS 2015, as those are now available for free for noncommercial usage
via the new 'Community Edition'. With 2010 you are still limited to those
who have access to these versions.

Note that if you want to remain compatible with Windows XP and 2003 with
those versions, you need special options which will mostly get you back at
the VS 2010 tools.

Bert

RE: chcp has no effect on output encoding for chcp

[Bert Huijben]

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: maandag 7 september 2015 23:26
> To: Matthias Ludwig 
> Cc: users@subversion.apache.org
> Subject: Re: chcp has no effect on output encoding for chcp
> 
> Matthias Ludwig wrote on Mon, Sep 07, 2015 at 11:45:13 +0200:
> > The use of the subversion language bindings is no alternative because
there
> > exists no language bindings for svnlook.
> 
> svnlook just wraps the svn_fs/svn_repos APIs, which do have bindings:
> 
> % python2
> >>> from svn.fs import *
> >>> from svn.repos import *
> >>> fs = svn_repos_fs(svn_repos_open("/tmp/r"))
> >>> svn_fs_youngest_rev(fs)
> 0L
> 
> (The repository was empty, i.e., zero revisions.)

You could also look at the SharpSvn library (.Net on Windows). This library
has a higher level SvnLookClient class which has mostly the same functions
as 'svnlook'.

You can find some examples on StackOverflow via
http://stackoverflow.com/search?q=SvnLookClient

Bert

RE: Access denied error on checkout-commit after updating to 1.9.X

[Bert Huijben]

I have no problem using Subversion on 1.9.x on network drives, testing to 
Windows servers and to Samba 4.x, so clearly not everyone using Subversion on a 
network drive has this problem.

 

Perhaps you tried to say that most users seeing this problem have it on a 
network drive?

 

Are there other common similarities?

 

Are you all using the same virus scanner on either the client or the server, or 
the same windows version on client and/or server? (Or not even using Windows at 
all on the server?)

 

Bert

 

From: Daniele Pedroni [mailto:pedroni.dani...@zapispa.it] 
Sent: vrijdag 4 september 2015 17:15
To: users@subversion.apache.org
Subject: Access denied error on checkout-commit after updating to 1.9.X

 

After updating from 1.8.X to 1.9.X (tried also 1.9.1, no luck), TortoiseSVN as 
well as command line throw the following error after trying to checkout or 
commit a Working Directory on a network share:

 

Commit failed (details follow): 
Can't move 'U:\1-Administration\Management\.svn\tmp\svn-ADD80C28' to 
 
'U:\1-Administration\Management\.svn\pristine\b7\b7c3f06170d83d3aac6b4489b78c4c8509c70ed6.svn-base':
 
 Access is denied. 

 

(full discussion on TSVN mailing list here: 
https://groups.google.com/forum/#!topic/tortoisesvn/Goi-Ay3BV6U )

 

It seems to be a Subversion issue, not a TortoiseSVN one, since command line 
acts exactly the same as TSVN: everything fine with local paths, issues with 
network drives. Sometimes, trying more and more, the checkout/commit succeeds 
also on network share, but it is a random occurrence.

 

Any clue? As you can see in the suggested link, it seems that everyone who 
works on network drive has the same problem: something has been changed or 
broken in 1.9.X release about it? I didn’t find anything about it.

 

Thank you in advance

 

Daniele P.

Zapi Spa - Società per Azioni con Unico Socio - Via Parma, 59, 42028 Poviglio 
(RE) - Tel. +39 0522 960050 - Fax +39 0522 960259 - E-mail: z...@zapispa.it 
  - web site: www.zapispa.it   - 
Capitale Sociale € 2.582.500,00 - Iscrizione Registro Imprese di Reggio Emilia 
n. 00794070342 - C.F. 00794070342 - P. IVA 01184200358 

AVVERTENZA: Ai sensi del Codice Privacy DLGS n.196/03 si precisa che le 
informazioni contenute in questo messaggio sono riservate e ad uso esclusivo 
del destinatario. Qualora il messaggio Le fosse pervenuto per errore La 
preghiamo di eliminarlo senza copiarlo, di non inoltrarlo a terzi e di darcene 
tempestiva comunicazione. According to Privacy Code DLGS n.196/03 we state that 
the information contained in this message are contidential and for the 
exclusive use of the receveir. In case the message reached you by mistake, we 
kindly ask you to delete it without copying it, not to send it to others and to 
inform us about it immediately. 
Rispetta l'ambiente: non stampare questa e-mail se non ti è necessario. Please 
consider your environmental responsability before printing this e-mail. 

RE: Can't dump a subtree using svnrdump

[Bert Huijben]

 -Original Message-
 From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
 Sent: zondag 30 augustus 2015 20:30
 To: users@subversion.apache.org
 Subject: Can't dump a subtree using svnrdump
 
 Hi all,
 
 I would like to dump one or maybe two subtrees of the ASF repo and
 whatever I feed to svnrdump I always get the contents of unrelated
 subtrees as well. If I don't provide a revision range I get thew
 complete repo, if I provide a range where my subtrees have changed, I
 get all the revisions of unrelated subtrees in between as well. In the
 documentation and such I can read that svnrdump does support subtrees,
 so there must be something wrong ho I call it.
 
 What I want is the following URL:
 
  https://svn.apache.org/repos/asf/incubator/log4cxx
 
 Which was originally added as the following:
 
  https://svn.apache.org/repos/asf/logging/log4cxx
 
 What I've tried so far:
 
  svnrdump.exe dump https://svn.apache.org/repos/asf/incubator/log4cxx
  svnrdump.exe dump https://svn.apache.org/repos/asf/logging/log4cxx
  svnrdump.exe dump https://svn.apache.org/repos/asf/logging/log4cxx -r
 307452:1554780
  svnrdump.exe dump https://svn.apache.org/repos/asf/incubator/log4cxx -r
 1554780:HEAD
 
 But all of those always dump revisions not related to my subtrees.
 
 What am I doing wrong? Thanks!

I don't think you are doing anything wrong. 
Any revision in a repository applies to each path that exists at that revision 
and the only way to ensure a 100% compatible dump with matching revision 
numbers is to produce empty revisions for revisions that don't have relevant 
paths.

So yes, you will see many more revisions than just your own project... but if 
filtered correctly not the changes in those revisions.


Once you have dumps you can use tools like 'svndumpfilter' to filter out 
dummy/stub revisions, fixing things like copies and merges.


I just used this to import the Serf repository into 
https://svn.apache.org/repos/asf/serf, while filtering a thousand stub 
revisions.

Bert

RE: How to pass a message file in UTF8 encoding to svn commit?

[Bert Huijben]

 -Original Message-
 From: Hunger Tobias [mailto:tobias.hun...@theqtcompany.com]
 Sent: donderdag 27 augustus 2015 15:45
 To: users@subversion.apache.org
 Subject: How to pass a message file in UTF8 encoding to svn commit?
 
 Hello SVN users list!
 
 I have a file in UTF8 encoding, containing a couple of non-ASCII
characters
 (Cyrillic mostly, some äüß and such). I know that file to be in UTF8
encoding.
 
 Then I am trying to run:
 svn commit --encoding utf8 --file mymsg.txt somefile.cpp
 
 and I get the following error:
 svn: E22: Commit failed (details follow):
 svn: E22: Error normalizing log message to internal format
 svn: E22: Non-ASCII character (code 195) detected, and unable to
convert
 to/from UTF-8
 
 Did I set something wrong in --encoding? Or does that not effect --file?
How
 can I force SVN to treat the file contents as UTF8?

I think at least UTF-8 as passed value should work.
That encoding name is hardcoded to avoid the entire conversion.

The other values might depend on what iconv settings are used by your
specific client.

Bert

RE: Is it safe to redirect from HTTP to HTTPS in case of svn:externals?

[Bert Huijben]

 -Original Message-
 From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
 Sent: woensdag 19 augustus 2015 21:50
 To: users@subversion.apache.org
 Subject: Is it safe to redirect from HTTP to HTTPS in case of svn:externals?
 
 Hi,
 
 I'm implementing publicly accessible mod_davn_svn in addition to some
 internally used svnserve. Some of my repos use svn:externals where we
 used to defined //internal.example.org/..., my publicly available
 entry point is https://external.example.org;. For the public
 internal.example.org is resolved as external.example.org, so
 checking out a repo from HTTPS with svn:externals used would result in
 a request to https://internal.example.org; and produce certificate
 verification failures in the client because of mismatching domain
 names and such.
 
 So I thought of simply changing the svn:externals definition to
 http://internal.example.org; which I can then redirect to
 https://external.example.org; on my public server. In my tests that
 seemed to work properly and the important part is that the locally
 created working copy for svn:externals only contained HTTPS-URLs.
 
 So am I correct that my approach is safe regarding that no user
 passwords or such are going unencrypted over the wire if only the
 first request doesn't contain such passwords and will always only be
 the redirect? Any other problems which I might overlook currently?

The key Subversion uses to store passwords is different between http and https, 
so a password used for https won't be used for http.

There are other options to specify your externals; see 'svn help propset'
[[
  The URL may be a full URL or a relative URL starting with one of:
../  to the parent directory of the extracted external
^/   to the repository root
/to the server root
//   to the URL scheme
  ^/../  to a sibling repository beneath the same SVNParentPath location
]]


Bert

Re: Broken SVN revision paths encoding

[Bert Huijben]

What client (including version) did you use to commit… and against what kind of 
server?


Subversion's clients properly encode characters to utf-8 as far as we know, but 
perhaps you used some not standard client for the commit.

(Newer servers should perform more verifications; that is why that answer is 
also relevant)


Bert






Sent from Surface





From: dpsen...@apache.org
Sent: ‎Tuesday‎, ‎July‎ ‎28‎, ‎2015 ‎4‎:‎11‎ ‎PM
To: users@subversion.apache.org






Hi there,

 

Somehow I was able to commit a file with a broken filename encoding and now the 
svn client can no longer process the log messages from the server! For example 
I commited the file “fooä.bar” and when I then try to svn log I get this:

 

svn: E130003: The REPORT response contains invalid XML (200 OK)

 

However, in wireshark I can see this coming in (stripped to the interesting 
lines):

 

S:log-item

S:added-pathfoo\344.file/S:added-path

/S:log-item

 

The clients svn is not the latest, but a newer version does not work either:

 

svn –version

svn, version 1.8.10 (r1615264)

   compiled Aug 10 2014, 15:48:46 on x86-microsoft-windows

 

Any good ideas how we can bring the repository back to be fully functional?

 

Cheers

RE: Feature request: Save the old file when svn revert

[Bert Huijben]

 -Original Message-
 From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
 Sent: woensdag 22 juli 2015 13:43
 To: Markus Schaber m.scha...@codesys.com
 Cc: Grierson, David david.grier...@sky.uk; d...@subversion.apache.org; 牛
 暁冬 neoedm...@gmail.com; users@subversion.apache.org
 Subject: Re: Feature request: Save the old file when svn revert

 Markus Schaber wrote on Tue, Jul 21, 2015 at 13:01:09 +:
  All other commands need a --force or other explicit user decision to
  override user changed data, but the whole purpose of the svn revert
  command is to undo local changes - putting a --force option or
  something similar seems like a bit of contradiction.

 Note that 'svn revert' without further arguments does nothing and errors
 out; you must name explicitly what will be reverted.  (Even with '-R'
 you still need to specify a target directory.)

  How do the other RCSes handle this situation? Maybe we can learn
  some ideas for a nice(r) UI there...

 In Git, if you add a file to the index, you can generally 'cat-file
 blob' it out of there for a while later if you know its hash (eg, if you
 have the header of a diff of that file, as headers mention the hash).
 Ditto for local commits, you can get them from the reflog for a while
 later (until a garbage collection pass).

Adding it to the index, is usually done by something like commit. In that
case I don't think you really need to stash the actual file locally, as you
can just get it with 'svn cat' (probably after finding some revision with
svn log)

The local version of the file might have local changes though...

If you would store that one in the pristine store, it would have some sha-1
hash...


But I doubt the user would know that hash, and without that he/she would be
unable to retrieve it, unless we build some UI.


In that case I would start by looking at the UI.

Bert

RE: E175002

[Bert Huijben]

Hi Anup,

 

This error is raised from SvnKit. A pure java reimplementation of the
Subversion libraries.

 

While it is possible that this error is caused by the/a Subversion server,
the fact that you can fix it by restarting Jenkins points towards an issue
in either SvnKit or Jenkins.

 

I think you should ask at either of these project's support mailinglists.

 

The 'Caused by: java.lang.NoClassDefFoundError:
hudson/remoting/RemoteClassLoader$RemoteIClassLoader' would point towards a
bit more towards Jenkins, than to SvnKit.

 

Bert

 

From: Somashekarappa, Anup (CWM-NR) [mailto:anup.somashekara...@rbc.com] 
Sent: maandag 13 juli 2015 15:26
To: 'users@subversion.apache.org'
Subject: E175002

 

 

 

Hi,

 

 

We are frequently getting the below error when trying to downloading svn
data from jenkins.

 

Issue will get resolved when we restart jenkins slave node.Any idea what is
the root cause?

 

 

org.tmatesoft.svn.core.SVNException
http://stacktrace.jenkins-ci.org/search?query=org.tmatesoft.svn.core.SVNExc
eption : svn: E175002: OPTIONS /svn/repo/trunk failed 

 

Caused by: java.io.IOException: Remote call on channel failed

at hudson.remoting.Channel.call(Channel.java:760)

at
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:
173)

... 36 more

Caused by: java.lang.NoClassDefFoundError:
hudson/remoting/RemoteClassLoader$RemoteIClassLoader

at
hudson.remoting.RemoteClassLoader.export(RemoteClassLoader.java:657)

at hudson.remoting.UserRequest.init(UserRequest.java:70)

at hudson.remoting.Channel.call(Channel.java:750)

... 37 more

 

 

Thanks  Regards,

Anup T S

 

 

__

This email is intended only for the use of the individual(s) to whom it is
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive this e-mail in
error, please advise immediately
and delete the original message. This message may have been altered without
your or our knowledge
and the sender does not accept any liability for any errors or omissions in
the message.

Emails are monitored by supervisory personnel in jurisdictions where
monitoring is permitted. 
Such communications are retained and may be produced to regulatory
authorities or others with legal rights to the information.

RE: Subversion 1.8.13 on Cygwin: E170000 or E180001: Unable to connect to a repository at URL , Unable to open an ra_local session to URL

[Bert Huijben]

Hi Marc,

 

It has nothing to do with cross compilation. (I don’t know how Cygwin produces 
their binaries… doesn’t matter)

 

But Cygwin is a fake unix environment for Windows. As such it expects unix 
style paths. And when you compile Subversion for Cygwin, Subversion assumes 
that it is not on Windows so the path processing combines multiple slashes to 
one.

 

The APR library that Subversion uses provides full Windows compatibility and 
Subversion itself also adds many Windows specific features, but only if you 
compile Subversion for Windows… which is what the Cygwin developers explicitly 
don’t. They explicitly disable the Windows portions to make Subversion behave 
as on other platforms. 

 

This is the problem you see here.

 

Subversion 1.6 was very sloppy in its path handling, which required a lot of 
unneeded path processing all through the code. With Subversion 1.7 the path 
processing was completely updated to fully work with canonical and in most 
cases absolute paths, to avoid all kinds of errors.

 

In 1.6 we didn’t catch all kinds of user errors, including file: 
file:///\\  style paths, or even file:///\\\ file:///\\ , but for 1.7 we 
declared these non canonical and convert them to a supported format before we 
use them. But depending on the platform we use different rules. Things like 
‘c:hi’ are a valid filename on platforms like linux, while they are a drive 
relative path on Windows. The unix/posix code in Subversion doesn’t support UNC 
paths, while the Windows code does.

 

We support a Windows version of Subversion, to handle the Windows platform.

And the Cygwin developers support their compilation… but when they decide not 
to use our platform support, we can’t help you.

 

That’s why I recommended mapping the drive (to work around the problem) or to 
use a proper Windows subversion client.

 

Bert

 

From: MORGAN Marc [mailto:marc.mor...@csem.ch] 
Sent: vrijdag 26 juni 2015 11:41
To: Bert Huijben; users@subversion.apache.org
Subject: RE: Subversion 1.8.13 on Cygwin: E17 or E180001: Unable to connect 
to a repository at URL , Unable to open an ra_local session to URL

 

Hi Bert,

 

Thanks for your reply.

 

1)  Are you suggesting that Cygwin executables are cross-compiled for 
Cygwin under Linux? Are you sure of this? I’ve never come across a Linux 
environment for cross-compiling code for Cygwin execution. Do you have more 
information about this?

2)  Access to the same repository worked fine with the previous svn on 
Cygwin on the same Windows computer, same Linux server, same network. Are you 
suggesting that someone removed the path mapping capability from svn between 
versions 1.6 and 1.8?

 

Marc

 

From: Bert Huijben [mailto:b...@qqmail.nl] 
Sent: vendredi 26 juin 2015 05:17
To: MORGAN Marc; users@subversion.apache.org 
mailto:users@subversion.apache.org 
Subject: Re: Subversion 1.8.13 on Cygwin: E17 or E180001: Unable to connect 
to a repository at URL , Unable to open an ra_local session to URL

 

The cygwin version of Subversion is a unix compilation of subversion running on 
Windows, via the cygwin libraries. As such it doesn't understand special 
Windoes paths.

 

If you would use a normal windows client (compiled for windows; not cygwin) it 
would understand that it should transform file://myserver/share/path 
file:///\\myserver\share\path  to \\myserver\share\path 
file:///\\myserver\share\path .

 

If you would like to use the cygwin version, you should probably map the 
network share and then relocate your working copy.

 

Bert

 

Sent from Surface

 

From: MORGAN Marc mailto:marc.mor...@csem.ch 
Sent: ‎Thursday‎, ‎June‎ ‎25‎, ‎2015 ‎3‎:‎47‎ ‎PM
To: users@subversion.apache.org mailto:users@subversion.apache.org 
Cc: MORGAN Marc mailto:marc.mor...@csem.ch 

 

Hi,

 

I’ve been using subversion on my Windows 7 PC with Cygwin with a repository on 
a Linux server accessed via file:// file:///\\ .

I installed a brand new Cygwin version yesterday.

My local workspace lost its connection to the repository.

I can no longer access via svn the repository which I was previously using on 
the same PC.

 

% svn status -u

svn: E17: Unable to connect to a repository at URL 
'file://server/path/repository/trunk'

svn: E17: Unable to open an ra_local session to URL

svn: E17: Local URL 'file://server/path/repository/trunk'contains 
unsupported hostname

 

% svn ls file:server/path/repository file:///\\server\path\repository 

svn: E180001: Unable to connect to a repository at URL 
'file:///server/path/repository'

svn: E180001: Unable to open an ra_local session to URL

svn: E180001: Unable to open repository 'file:///server/path/repository'

 

% ls //server/path/repository

conf  dav  db  format  hooks  locks  README.txt

 

The new svn version is 1.8.13 (r1667537) on i686-pc-cygwin. The previous svn 
version I was using is 1.6.17.

 

With file:// I get the E17 error. With file

Re: Subversion 1.8.13 on Cygwin: E170000 or E180001: Unable to connect to a repository at URL , Unable to open an ra_local session to URL

[Bert Huijben]

The cygwin version of Subversion is a unix compilation of subversion running on 
Windows, via the cygwin libraries. As such it doesn't understand special 
Windoes paths.


If you would use a normal windows client (compiled for windows; not cygwin) it 
would understand that it should transform file://myserver/share/path to 
\\myserver\share\path.


If you would like to use the cygwin version, you should probably map the 
network share and then relocate your working copy.


Bert






Sent from Surface





From: MORGAN Marc
Sent: ‎Thursday‎, ‎June‎ ‎25‎, ‎2015 ‎3‎:‎47‎ ‎PM
To: users@subversion.apache.org
Cc: MORGAN Marc






Hi,

 

I’ve been using subversion on my Windows 7 PC with Cygwin with a repository on 
a Linux server accessed via file://.

I installed a brand new Cygwin version yesterday.

My local workspace lost its connection to the repository.

I can no longer access via svn the repository which I was previously using on 
the same PC.

 

% svn status -u

svn: E17: Unable to connect to a repository at URL 
'file://server/path/repository/trunk'

svn: E17: Unable to open an ra_local session to URL

svn: E17: Local URL 'file://server/path/repository/trunk'contains 
unsupported hostname

 

% svn ls file:server/path/repository

svn: E180001: Unable to connect to a repository at URL 
'file:///server/path/repository'

svn: E180001: Unable to open an ra_local session to URL

svn: E180001: Unable to open repository 'file:///server/path/repository'

 

% ls //server/path/repository

conf  dav  db  format  hooks  locks  README.txt

 

The new svn version is 1.8.13 (r1667537) on i686-pc-cygwin. The previous svn 
version I was using is 1.6.17.

 

With file:// I get the E17 error. With file:/// or file: I get the 
E180001 error. 

 

The repository directory is technically on another computer but is seen as 
local on my PC (I guess it’s NFS or SAMBA) when accessed with the // prefix 
from the shell. 

I tried touch-ing a new file in the repository’s directory and that worked, 
with correct owner, group and file permissions when checked from the Linux 
server.

 

If I copy the repository folder to my local /tmp, I can access it correctly via 
svn. But that’s obviously not my goal.

 

If I access the repository via the URL  
svn+ssh://somelinuxcomputer/nfspath/repository, that works. But my experience 
with the SSH tunnel is that it tends to slow down access.

 

Has anyone experienced this problem before? Any suggestions?

 

Thanks in advance

RE: building SVN trunk on Windows fails on python gen-make.py

[Bert Huijben]

 -Original Message-
 From: Cooke, Mark [mailto:mark.co...@siemens.com]
 Sent: maandag 22 juni 2015 13:46
 To: Stefan Hett; users@subversion.apache.org
 Subject: RE: building SVN trunk on Windows fails on python gen-make.py
 
 Sorry I cannot help with the current issue but I wanted to add a comment about
 the content of INSTALL (below)...


 While I agree in principle, I need to build httpd and subversion to work with
 Trac (trac.edgewall.org) which is currently limited to python  3.0 (I use 2.7
 also).  For this to work properly my understanding is that httpd and python 
 (and
 svn) all need to use the same compiler libraries and Python 2.7 is built using
 Visual C++ 2008...
 
 So the 2008 stuff is not completely irrelevant (I got it compiling and making 
 the
 python bindings).  I have some notes but they are not really fit for 
 publication
 and are for VC2008 but I can share them if you think they would be useful.

To build AnkhSVN for Visual Studio 2005 and 2008 I continue to build Subversion 
using VS 2008 at least every week, so I would consider VS 2005 and 2008 as 
fully supported for Subversion.

But I don't think anybody working on Subversion really uses VS 6.0 (released +- 
18 years ago) or 2002 and 2003, so I don't consider our support for these 
versions as really supported. I'm guessing that the VS 6.0 support might still 
work with a minor tweak, while I think the 2002/2003 support would need at 
least some patches to make it work again.

If nobody is going to comment on this after the release of 1.9.0, I think we 
will drop support for these 12+ year old versions with 1.10+.  With VS 2013 
Community Edition now free to use for everybody working on open source 
projects, there is no good reason to continue to support these very old 
versions, that target platforms that are no longer supported anyway.


One interesting point for some usecases is that the VS 2010 tooling allows 
building with the VS2008 compiler by passing a few specific flags to msbuild. 
This is how the first version of XP compatibility in VS2012+ was implemented. 
(And this is also how VC 2010+'s C++/CLI can target .Net 2.0-3.5)

Bert

RE: svn 1.8.13 test failures: wc-queries-test.exe and move_tests.py

[Bert Huijben]

 -Original Message-
 From: Cooke, Mark [mailto:mark.co...@siemens.com]
 Sent: maandag 1 juni 2015 08:24
 To: users@subversion.apache.org
 Cc: Bert Huijben
 Subject: RE: svn 1.8.13 test failures: wc-queries-test.exe and
move_tests.py
 
   -Original Message-
   From: Cooke, Mark [mailto:mark.co...@siemens.com]
   Sent: vrijdag 29 mei 2015 15:21
  
   Hello,
  
   I am trying to compile svn (and httpd) with VS2008 (for python 2.7
   compatibility) on Win 7 Enterprise and am getting some test failures:
   {{{
  win-tests.py --release --cleanup --parallel
  win-tests.py -r -c --httpd-dir=d:\Apache24 --httpd-daemon
   }}}
  
   [40/96] wc-queries-test.exe ... FAILED
   [72/96] move_tests.py . success
  
   For #40 I noticed that Andreas confirmed [1] that r1672295 fixes a
(similar?) issue (which is more recent than the 1.8.13 tag), so can
   I safely ignore this?
 
  -Original Message-
  From: Bert Huijben [mailto:b...@qqmail.nl]
  Sent: 29 May 2015 16:15
 
  What version of sqlite do you use,
 
 I made a mistake and took a nightly snapshot:
 - sqlite-amalgamation-201505290135.zip
 
  and what is the error that you see?
 
 Apologies for not being more precise earlier, I am still finding my way
around
 the code trees.  This is the summary:-
 
 At least one test FAILED, checking D:\svn\src\Release\dav-tests.log
 FAIL:  wc-queries-test.exe 3: test query expectations
 Summary of test results:
   1950 tests PASSED
   55 tests SKIPPED
   32 tests XFAILED (1 WORK-IN-PROGRESS)
   1 test FAILED
 SUMMARY: Some tests failed.
 
 ...and from the test log:-
 
 START: wc-queries-test.exe
 DBG: Using Sqlite 3.8.11
 PASS:  wc-queries-test.exe 1: sqlite up-to-date
 PASS:  wc-queries-test.exe 2: queries are parsable
 svn_tests: E26: STMT_SELECT_EXTERNALS_DEFINED: Uses externals with
 only 1 index component: (wc_id=? )
 SELECT local_relpath, def_local_relpath FROM externals WHERE (wc_id = ?1
 AND def_local_relpath = ?2)OR (wc_id = ?1 AND (((def_local_relpath) 
 (CASE (?2) WHEN '' THEN '' ELSE (?2) || '/' END)) AND ((def_local_relpath)

 CASE (?2) WHEN '' THEN X'' ELSE (?2) || '0' END)))
 svn_tests: E200035: Additional errors:
 svn_tests: E200035: |SEARCH TABLE externals USING COVERING INDEX
 I_EXTERNALS_DEFINED (wc_id=?)
 FAIL:  wc-queries-test.exe 3: test query expectations
 PASS:  wc-queries-test.exe 4: test schema statistics
 END: wc-queries-test.exe
 ELAPSED: wc-queries-test.exe 0:00:00.125000

Ok, this confirms that it is a known failure that will be fixed when the
'r1672295, r1673691' group of ^/subversion/branches/1.8.x/STATUS is
backported. I hope this will happen for the next 1.8.x version. The problem
occurs with Sqlite 3.8.10 and later.

It currently tells us that it is using the index in a less than optimal way,
but unless you have hundreds of externals in a working copy you wouldn't be
able to tell the difference. The query optimizer is expected to use two
index components here, but currently only one... which makes it essentially
a table scan. But with typically every external in a single database page
there won't be real performance problems.

 
 For the `move_tests.py` crash success the log states:
 
 START: move_tests.py
 PASS:  move_tests.py 1: lateral (rename) move of a file test
 PASS:  move_tests.py 2: sibling move of a file test
 PASS:  move_tests.py 3: shallower move of a file test
 PASS:  move_tests.py 4: deeper move of a file test
 PASS:  move_tests.py 5: test property merging on move-update
 PASS:  move_tests.py 6: move a missing directory
 PASS:  move_tests.py 7: move many and delete-on-update
 W: svn: E235000: In file
'..\..\..\subversion\libsvn_wc\wc_db_update_move.c'
 line 809: assertion failed (move_dst_revision ==
expected_move_dst_revision
 || status == svn_wc__db_status_not_present)
 W:
 W: This application has requested the Runtime to terminate it in an
unusual
 way.
 W: Please contact the application's support team for more information.
 W: CWD: D:\svn\src\Release\subversion\tests\cmdline
 W: EXCEPTION: Failure: Command failed:
 D:\svn\src\Release\subversion\svn\svn.exe up svn-test-
 work\working_copies\move_tests-8 --accept ...; exit code 3
 Traceback (most recent call last):
   File d:\svn\src\subversion\tests\cmdline\svntest\main.py, line 1561,
in run
 rc = self.pred.run(sandbox)
   File d:\svn\src\subversion\tests\cmdline\svntest\testcase.py, line
114, in run
 return self._delegate.run(sandbox)
   File d:\svn\src\subversion\tests\cmdline\svntest\testcase.py, line
176, in run
 return self.func(sandbox)
   File d:\svn\src\subversion\tests\cmdline\move_tests.py, line 1397, in
 move_many_update_add
 wc_dir, '--accept', 'mine-conflict')
   File d:\svn\src\subversion\tests\cmdline\svntest\actions.py, line 865,
in
 run_and_verify_update
 exit_code, output, errput = main.run_svn(error_re_string, 'up', *args)
   File d:\svn\src\subversion\tests\cmdline\svntest\main.py, line 682, in
 run_svn
 *(_with_auth

RE: svn 1.8.13 test failures: wc-queries-test.exe and move_tests.py

[Bert Huijben]

 -Original Message-
 From: Cooke, Mark [mailto:mark.co...@siemens.com]
 Sent: vrijdag 29 mei 2015 15:21
 To: users@subversion.apache.org
 Subject: svn 1.8.13 test failures: wc-queries-test.exe and move_tests.py
 
 Hello,
 
 I am trying to compile svn (and httpd) with VS2008 (for python 2.7
 compatibility) on Win 7 Enterprise and am getting some test failures:
 {{{
win-tests.py --release --cleanup --parallel
win-tests.py -r -c --httpd-dir=d:\Apache24 --httpd-daemon
 }}}
 
 [40/96] wc-queries-test.exe ... FAILED
 [72/96] move_tests.py . success
 
 For #40 I noticed that Andreas confirmed [1] that r1672295 fixes a
(similar?)
 issue (which is more recent than the 1.8.13 tag), so can I safely ignore
this?

What version of sqlite do you use, and what is the error that you see?

In most cases you can ignore the wc-query-expectations error failure, which
only signals some performance loss. But it is hard to tell what failure you
see if you only post the name of the .exe where one (or more) of the tests
failed. The summary at the bottom is more valuable, and the test log
contains the real details.

Bert

RE: Error with quick-start experiment

[Bert Huijben]

Hi,

 

You could use %REPOS_DIR:\=/% instead of just %REPOS_DIR% to replace all ‘\’ 
characters with ‘/’

 

(In batch scripts you might have to enable cmd extensions, but on the 
commandline this is enabled by default)

 

Bert

 

From: Antti Simola [mailto:asimol...@gmail.com] 
Sent: donderdag 28 mei 2015 11:19
To: Antti Simola; users@subversion.apache.org
Subject: Re: Error with quick-start experiment

 

This is what I typed in my last attempt. I've made several attempts after the 
one that worked earlier.

C:\set REPOS_DIR=h:\repos\my-repos

C:\mkdir h:\repos

C:\svnadmin create %REPOS_DIR%

C:\svn mkdir -m Create directory structure. file:///%REPOS_DIR%/trunk 
file:///\\%25REPOS_DIR%25\trunk  file:///%REPOS_DIR%/branches 
file:///\\%25REPOS_DIR%25\branches  file:///%REPOS_DIR%/tags 
file:///\\%25REPOS_DIR%25\tags 
svn: E235000: In file '..\..\..\subversion\libsvn_subr\dirent_uri.c' line 2307: 
assertion failed (svn_uri_is_canonical(url, pool))

C:\

 

On Thu, May 28, 2015 at 11:30 AM, Stefan Sperling s...@elego.de 
mailto:s...@elego.de  wrote:

On Thu, May 28, 2015 at 11:08:17AM +0300, Antti Simola wrote:
 Hello,



 I’m learning to use the command-line Subversion (1.8.13 64-bit Win,
 SLIKSVN) by reading the book online and doing some tests. I followed the
 quick-start guide for some experiments:



 https://subversion.apache.org/quick-start



 The first time around went spotless. But the second time when I wanted to
 create another repo for another project I get the following error message:



 svn: E235000: In file '..\..\..\subversion\libsvn_subr\dirent_uri.c' line
 2307: assertion failed (svn_uri_is_canonical(url, pool))


  when I execute the part that makes trunk, branches and tags
 subdirectories. That opens a dialog window for the error as well. Does
 anyone have any idea what I’m doing wrong here?


Can you please show exactly what you typed on the command line
when this happened?



 Antti Simola





 PS: There’s a typo in quick-start guide as the first “ is missing from the
 tags subdirectory address.

Fixed, thanks.

 

RE: Error with quick-start experiment

[Bert Huijben]

If you want to use URL operations, the whole url should use ‘/’ separators. It 
now tries to open the local directory file:\\something 
file:///\\something , which certainly won’t exist because file: is not a 
valid device specifier on Windows.

 

You want to use something like 

$ svn mkdir -m Create directory structure.  
file:///\\%25REPOS_DIR:\=\%25\trunk file:///%REPOS_DIR:\=/%/trunk  
file:///\\%25REPOS_DIR:\=\%25\branches file:///%REPOS_DIR:\=/%\branches  
file:///\\%25REPOS_DIR:\=\%25\tags file:///%REPOS_DIR:\=/%\tags

 

But it might be easier to just set the properly encoded path in REPOS_DIR

 

 

From: Antti Simola [mailto:asimol...@gmail.com] 
Sent: donderdag 28 mei 2015 11:55
To: Bert Huijben
Subject: Re: Error with quick-start experiment

 

Thanks! There's another error now with replaced slashes:

C:\svn mkdir -m Create directory structure. file:\\\%REPOS_DIR%\trunk 
file:///\\%25REPOS_DIR%25\trunk  file:\\\%REPOS_DIR%\branches 
file:///\\%25REPOS_DIR%25\branches  file:\\\%REPOS_DIR%\tags 
file:///\\%25REPOS_DIR%25\tags 
svn: E020024: Error resolving case of 'file:\\\h:\repos\my-repos\trunk'

 

On Thu, May 28, 2015 at 12:51 PM, Bert Huijben b...@qqmail.nl 
mailto:b...@qqmail.nl  wrote:

Hi,

 

You could use %REPOS_DIR:\=/% instead of just %REPOS_DIR% to replace all ‘\’ 
characters with ‘/’

 

(In batch scripts you might have to enable cmd extensions, but on the 
commandline this is enabled by default)

 

Bert

 

From: Antti Simola [mailto:asimol...@gmail.com mailto:asimol...@gmail.com ] 
Sent: donderdag 28 mei 2015 11:19
To: Antti Simola; users@subversion.apache.org 
mailto:users@subversion.apache.org 
Subject: Re: Error with quick-start experiment

 

This is what I typed in my last attempt. I've made several attempts after the 
one that worked earlier.

C:\set REPOS_DIR=h:\repos\my-repos

C:\mkdir h:\repos

C:\svnadmin create %REPOS_DIR%

C:\svn mkdir -m Create directory structure. file:///%REPOS_DIR%/trunk 
file:///\\%25REPOS_DIR%25\trunk  file:///%REPOS_DIR%/branches 
file:///\\%25REPOS_DIR%25\branches  file:///%REPOS_DIR%/tags 
file:///\\%25REPOS_DIR%25\tags 
svn: E235000: In file '..\..\..\subversion\libsvn_subr\dirent_uri.c' line 2307: 
assertion failed (svn_uri_is_canonical(url, pool))

C:\

 

On Thu, May 28, 2015 at 11:30 AM, Stefan Sperling s...@elego.de 
mailto:s...@elego.de  wrote:

On Thu, May 28, 2015 at 11:08:17AM +0300, Antti Simola wrote:
 Hello,



 I’m learning to use the command-line Subversion (1.8.13 64-bit Win,
 SLIKSVN) by reading the book online and doing some tests. I followed the
 quick-start guide for some experiments:



 https://subversion.apache.org/quick-start



 The first time around went spotless. But the second time when I wanted to
 create another repo for another project I get the following error message:



 svn: E235000: In file '..\..\..\subversion\libsvn_subr\dirent_uri.c' line
 2307: assertion failed (svn_uri_is_canonical(url, pool))


  when I execute the part that makes trunk, branches and tags
 subdirectories. That opens a dialog window for the error as well. Does
 anyone have any idea what I’m doing wrong here?


Can you please show exactly what you typed on the command line
when this happened?



 Antti Simola





 PS: There’s a typo in quick-start guide as the first “ is missing from the
 tags subdirectory address.

Fixed, thanks.

 

 

RE: Error with quick-start experiment

[Bert Huijben]

That is not strictly typo, but I already committed a change to that line before 
I wrote my previous mail (r1682198). 

 

The current form specifies a root relative path on Windows ( \repos ), which 
would work while your current drive is ‘C:’ but stops working when you switch 
the active drive.

 

Bert

 

From: Antti Simola [mailto:asimol...@gmail.com] 
Sent: donderdag 28 mei 2015 12:49
To: Bert Huijben
Cc: users@subversion.apache.org
Subject: Re: Error with quick-start experiment

 

Thanks! I got it working now by following the updated quick-start. There's 
perhaps one typo remaining as the drive is missing from this address:

 svn checkout file:///repos/my-repos/trunk file:///\\repos\my-repos\trunk  
 ./

 

On Thu, May 28, 2015 at 1:10 PM, Bert Huijben b...@qqmail.nl 
mailto:b...@qqmail.nl  wrote:

If you want to use URL operations, the whole url should use ‘/’ separators. It 
now tries to open the local directory file:\\something 
file:///\\something , which certainly won’t exist because file: is not a 
valid device specifier on Windows.

 

You want to use something like 

$ svn mkdir -m Create directory structure. file:///%REPOS_DIR:\=/%/trunk 
file:///\\%25REPOS_DIR:\=\%25\trunk  file:///%REPOS_DIR:\=/%\branches 
file:///\\%25REPOS_DIR:\=\%25\branches  file:///%REPOS_DIR:\=/%\tags 
file:///\\%25REPOS_DIR:\=\%25\tags 

 

But it might be easier to just set the properly encoded path in REPOS_DIR

 

 

From: Antti Simola [mailto:asimol...@gmail.com mailto:asimol...@gmail.com ] 
Sent: donderdag 28 mei 2015 11:55
To: Bert Huijben


Subject: Re: Error with quick-start experiment

 

Thanks! There's another error now with replaced slashes:

C:\svn mkdir -m Create directory structure. file:\\\%REPOS_DIR%\trunk 
file:///\\%25REPOS_DIR%25\trunk  file:\\\%REPOS_DIR%\branches 
file:///\\%25REPOS_DIR%25\branches  file:\\\%REPOS_DIR%\tags 
file:///\\%25REPOS_DIR%25\tags 
svn: E020024: Error resolving case of 'file:\\\h:\repos\my-repos\trunk'

 

On Thu, May 28, 2015 at 12:51 PM, Bert Huijben b...@qqmail.nl 
mailto:b...@qqmail.nl  wrote:

Hi,

 

You could use %REPOS_DIR:\=/% instead of just %REPOS_DIR% to replace all ‘\’ 
characters with ‘/’

 

(In batch scripts you might have to enable cmd extensions, but on the 
commandline this is enabled by default)

 

Bert

 

From: Antti Simola [mailto:asimol...@gmail.com mailto:asimol...@gmail.com ] 
Sent: donderdag 28 mei 2015 11:19
To: Antti Simola; users@subversion.apache.org 
mailto:users@subversion.apache.org 
Subject: Re: Error with quick-start experiment

 

This is what I typed in my last attempt. I've made several attempts after the 
one that worked earlier.

C:\set REPOS_DIR=h:\repos\my-repos

C:\mkdir h:\repos

C:\svnadmin create %REPOS_DIR%

C:\svn mkdir -m Create directory structure. file:///%REPOS_DIR%/trunk 
file:///\\%25REPOS_DIR%25\trunk  file:///%REPOS_DIR%/branches 
file:///\\%25REPOS_DIR%25\branches  file:///%REPOS_DIR%/tags 
file:///\\%25REPOS_DIR%25\tags 
svn: E235000: In file '..\..\..\subversion\libsvn_subr\dirent_uri.c' line 2307: 
assertion failed (svn_uri_is_canonical(url, pool))

C:\

 

On Thu, May 28, 2015 at 11:30 AM, Stefan Sperling s...@elego.de 
mailto:s...@elego.de  wrote:

On Thu, May 28, 2015 at 11:08:17AM +0300, Antti Simola wrote:
 Hello,



 I’m learning to use the command-line Subversion (1.8.13 64-bit Win,
 SLIKSVN) by reading the book online and doing some tests. I followed the
 quick-start guide for some experiments:



 https://subversion.apache.org/quick-start



 The first time around went spotless. But the second time when I wanted to
 create another repo for another project I get the following error message:



 svn: E235000: In file '..\..\..\subversion\libsvn_subr\dirent_uri.c' line
 2307: assertion failed (svn_uri_is_canonical(url, pool))


  when I execute the part that makes trunk, branches and tags
 subdirectories. That opens a dialog window for the error as well. Does
 anyone have any idea what I’m doing wrong here?


Can you please show exactly what you typed on the command line
when this happened?



 Antti Simola





 PS: There’s a typo in quick-start guide as the first “ is missing from the
 tags subdirectory address.

Fixed, thanks.

 

 

 

RE: API accessing property diff of svn:mergeinfo

[Bert Huijben]

 -Original Message-
 From: Branko Čibej [mailto:br...@wandisco.com]
 Sent: woensdag 6 mei 2015 14:49
 To: users@subversion.apache.org
 Subject: Re: API accessing property diff of svn:mergeinfo
 
 On 06.05.2015 14:20, Bernhard Haumacher wrote:
  Hi Branko,
 
  On 06.05.2015 08:24, Bernhard Haumacher wrote:
  
   ... I'd
   like to analyze the diff of the svn:mergeinfo property (what other
   revisions were merged into some branch in a commit). ...
  
 
  ISVNClient.getMergeinfoLog should give you that information.
 
  The upcoming 1.9 release will have http://s.apache.org/pVj which allows
  you to limit the revision range.
 
 
  I tried out your suggestion, but it seems that it cannot be used for
  my purpose: I'm not interested in the merged revisions limited to
  those revisions that were merged from a specific merge source (for
  using the getMergeinfoLog() API, I do not have the `mergeSourceUrl`
  info):
 
  {{{
  getMergeinfoLog(Mergeinfo.LogKind kind, String pathOrUrl,
   Revision pegRevision, String mergeSourceUrl,
   Revision srcPegRevision,
   Revision srcStartRevision, Revision
  srcEndRevision,
   boolean discoverChangedPaths,
   Depth depth, SetString revProps,
   LogMessageCallback callback)
  }}}
 
  What I'm interested in is the combination of all merge sources plus
  merged revisions that were merged within a single commit. At the
  command line, this information can be retrieved with
 
  {{{
  svn diff --depth empty -crev url of branch
  }}}
 
  resulting in e.g.:
 
  {{{
  Eigenschaftsänderungen: .
 
 
 ___
  Modified: svn:mergeinfo
 Zusammengeführt /trunk:r161790
 Zusammengeführt /branches/x:r160492
 Zusammengeführt /branches/y:r185821
  }}}
 
  Unfortunately, I cannot access this information using javahl in a
  structured way?!
 
 You can call ISVNClient.getMergeinfo twice with the same path and
 different revisions and calculate the difference of the returned
 Mergeinfo structures. That's just a hash+list intersection.

In AnkhSVN I usually skip the diff apis and just obtain the whole files ('svn 
cat FILE' 'svn cat FILE@BASE')  and properties ('svn proplist FILE' 'svn 
proplist FILE@BASE) and do the calculations myself.

That way I also have access to what is not changed.

Specifically for svn:mergeinfo you might be better of using the dedicated apis 
(which in many cases contact the server), but for all other properties I would 
guess just obtaining the values and explicitly apply further processing 
yourself is most likely far more future proof.

Bert

Re: Cannot checkout or clean up using 1.9 dev build

[Bert Huijben]

I’m not sure if the \\?\ format is supported in the new rename api(as this is 
an option in certain publi apis and not a low level supported format), but it 
should certainly be used in the fallback codepath where the normal rename is 
tried, like hiw it is in apr.


But if the new api fails with the limit, it is quite likely that it supports 
the \\?\ format. Some more recent new in Windows 8+ apis just dropped the path 
length limit and therefore don’t support the \\?\ format… but that doesn’t 
apply here as this api was new in Vista.




I hope somebody looks at this earlier, but I’ll will look into this early next 
week.


Bert




Sent from Windows Mail





From: Ivan Zhakov
Sent: ‎Tuesday‎, ‎April‎ ‎28‎, ‎2015 ‎9‎:‎07‎ ‎AM
To: Benjamin Fritz, Bert Huijben
Cc: 'subversion'





On 27 April 2015 at 21:35, Benjamin Fritz fritzophre...@gmail.com wrote:
 Apparently I'm not subscribed to get list emails; please CC me on future
 responses. I had to get this message from the archive :-)

 Branko Čibej wrote:
 On 27.04.2015 18:06, Benjamin Fritz wrote:
  I get the following error when I try to check out a working copy from
  my repository at work (exact path names obfuscated but length
  unchanged, in case it matters

 It probably does matter ... FWIW, I believe you did change the length of
 the file name, the workqueue record says 234 chars but the name in the
 record is 240; still, that shouldn't be an issue.


 Oops. You're right. My actual directory has only 3 characters where I
 replaced with Prog in the path string. Still, those 6 fewer
 characters are probably irrelevant.

  ), leaving a partially downloaded working copy:
 
  svn: E155009: Failed to run the WC DB work queue associated with
  'C:\Project_Files\Proj_Dev\Prog_svn_1.9_cmdline', work item 2160
  (file-install 234
 
  Logical_Architecture/APP/App_PL_Verification/XXX/XXX_XXXs/XXX_7_APPDB_PROJ_PROG--0021_BE/APPDB_PROJ_PROG--0021.SUP/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021.SUP/XXX_APPDB_PROJ_PROG--002101.CRC
  1 0 1 1)
  svn: E720123: The filename, directory name, or volume label syntax is
  incorrect.

 The full path of the file would be 281 characters long, which is more
 than Windows' limit of 260. But Subversion goes to a lot of trouble to
 avoid the path limit ... I wonder what's going on here.

It seems Windows specific implementation of
svn_stream__install_stream() doesn't prepend path with \\?\ for long
names. Replacing svn_utf__win32_utf8_to_utf16() call with
svn_io__utf8_to_unicode_longpath() should fix the problem, but I
didn't try yet.

Bert, is it intentional behavior or just small typo?


-- 
Ivan Zhakov

RE: Dealing with very old repo format (version 1)

[Bert Huijben]

 -Original Message-
 From: Andrew Reedick [mailto:jreed...@incomm.com]
 Sent: dinsdag 28 april 2015 23:03
 To: users@subversion.apache.org
 Subject: Dealing with very old repo format (version 1)
 
 Does anyone have any tips on how to upgrade a very old repo?  The
db/format
 lists 1.  A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade
such an
 old repo, all of which fail with svnadmin: E720002: Can't open file
 'devel\db\current': The system cannot find the file specified.
 
 Do I need find a really old svn client (1.3?) and upgrade?  Do I need to
manually
 create the db/current file?
 
 
 Supposedly , a format of 1 is from pre-svn 1.0.

https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/re
p
 os.h - Formats 0, 1 and 2 were pre-1.0.

There are repository versions and database versions (format files are in
repos/ and repos/db/). It looks like he is talking about the db format,
which is documented in the filesystem backends.

Bert 

RE: building SVN trunk on Windows fails on python gen-make.py

[Bert Huijben]

 -Original Message-
 From: Stefan Hett [mailto:ste...@egosoft.com]
 Sent: woensdag 22 april 2015 15:59
 To: 'subversion'
 Subject: building SVN trunk on Windows fails on python gen-make.py
 
 Hi,
 
 I just tried to build
 https://svn.apache.org/repos/asf/subversion/branches/svn-mergeinfo-
 normalizer
 on Windows following the INSTALL file documentation up to the point
 where the make file is being generated.
 
 Using this call: python gen-make.py -t vcproj --with-zlib=..\zlib
 --with-apr=..\apr --with-apr-util=..\apr-util --vsnet-version=2010
 I'm now getting the following error:
 
 Traceback (most recent call last):
File gen-make.py, line 325, in module main(conf, gentype,
 skip_depends=skip, other_options=rest.list)
File gen-make.py, line 62, in main generator =
 gen_module.Generator(fname, verfname, other_options)
File build\generator\gen_vcnet_vcproj.py, line 36, in __init__
 'vcnet-vcproj')
File build\generator\gen_win.py, line 83, in __init__
 self.find_libraries(True)
File build\generator\gen_win_dependencies.py, line 286, in
 find_libraries self._find_apr()
File build\generator\gen_win_dependencies.py, line 395, in
 _find_apr bin_files = os.listdir(dll_dir)
 FileNotFoundError: [WinError 3] The system cannot find the path
 specified: '..\\apr\\bin'
 
 Looking at the apr-directory I downloaded/extracted, there's no
 apr/bin-directory.
 I downloaded the following APR-source package (1.5.1):
 http://mirror.serversupportforum.de/apache//apr/apr-1.5.1-win32-src.zip
 
 Did I get the wrong one? Or did I miss some step?

Subversion expects that you already build apr before using it as a source of 
binaries to link against. It is not going to build apr for you. 

Building APR would have created this bin directory. (A patch to produce a nicer 
error message would be welcome :))


There are other scripts that may help you building Subversion and all 
dependencies. I maintain one such script as part of SharpSvn (Repository: 
https://ctf.open.collab.net/svn/repos/sharpsvn/trunk/imports ; username guest; 
no password). This script uses NAnt, and is used to produce the publicly 
available binaries for SharpSvn and SlikSvn. 

Somewhere in the Subversion repository there is a perl script that should also 
be able to help with building on Windows, but I don't have experience with that 
script.

Bert

RE: The XML response contains invalid XML

[Bert Huijben]

 -Original Message-
 From: OlePinto [mailto:olepinto+...@gmail.com]
 Sent: woensdag 22 april 2015 16:25
 To: users@subversion.apache.org
 Subject: RE: The XML response contains invalid XML
 
 Bad news: it has happened again. I haven't installed anything, or changed
any
 setting since yesterday. Right now I don't have the needed time to redo
the
 TCP reset + restart and try again, just for the sake of knowing if it
would
 work again for a while.
 If someone would like any information, traces or whatever, feel free to
ask
 and I'll try to oblige.

Just to be sure: you get this error during an update?

Not during a commit?

If it is during a commit: Are you committing to an xml file?

Bert

RE: Tortoise Subversion Exception, Help Needed

[Bert Huijben]

Hi,

 

This tells us that somehow your working copy has some invalid state stored.

 

This specific error message was replaced with an error message that contains
more data in December 2011 (backport to 1.7.x in r1213745), so I would
recommend you to upgrade your Subversion client (read: TortoiseSVN). If
possible I would recommend directly upgrading to 1.8.x as 1.7.x may be out
of support within a few months.

 

 

Most likely the actual problem has been fixed around that time as well as I
haven't seen error reports for this specific error in years.

 

Bert

 

From: Shahbaz Akhter [mailto:shahbaz.akh...@spanservices.com] 
Sent: woensdag 22 april 2015 09:14
To: users@subversion.apache.org
Subject: Tortoise Subversion Exception, Help Needed

 

Hello Users,

 

Please look into below issues I got during clean up ,Suddenly I ran into is
this. I was doing clean up and I got below issue.

 



 

Looking forward for your reply

 

Regards,

Shahbaz Akhter

DISCLAIMER: This email message and all attachments are confidential and may
contain information that is Privileged, Confidential or exempt from
disclosure under applicable law. If you are not the intended recipient, you
are notified that any dissemination, distribution or copying of this email
is strictly prohibited.  If you have received this email in error, please
notify us immediately by return email to mailad...@spanservices.com
mailto:mailad...@spanservices.com  and destroy the original message.
Opinions, conclusions and other information in this message that do not
relate to the official of SPAN, shall be understood to be nether given nor
endorsed by SPAN.

RE: The XML response contains invalid XML

[Bert Huijben]

 -Original Message-
 From: OlePinto [mailto:olepinto+...@gmail.com]
 Sent: dinsdag 21 april 2015 12:20
 To: users@subversion.apache.org
 Subject: Re: The XML response contains invalid XML
 
 We have finally fixed it, although we sadly do not really know what the
 problem was.
 The magic medicine has been: run /netsh int ip reset c:\filename.log/,
 reset, reconfigure the network, and done!
 So it seems it was a client problem, but I don't really know even what
kind
 of problem it was.
 Did it help anyone else?

What kind of virusscanner / firewall do/did you run on this machine?

This command removes custom settings on the IP stack, which may include
third party hooks. Adding this information to this thread may help resolve
the problem in the future.

There might be valuable information in the 'c:\filename.log' file created by
running this command. Did you check that file?

Bert

RE: Subversion Exception diff_editor.c 1626

[Bert Huijben]

This doesn't provide us enough information to reproduce your problem. 

(And 'large tree' is not well defined. For some users that could be thousand
files, while for others that would be hundreds of thousands of files)

 

To reproduce and fix your problem we need more information:

 

In this case interesting information might include:

 

Do you have externals in this working copy?

Do you use a normal Subversion server? 

Or something that just simulates Subversion. E.g. GitHub, Codeplex,
SvnBridge?

 

Are there incomplete nodes in your working copy (See: svn status)

 

But really we could use as much information as possible to reproduce your
problem.

 

Bert

 

From: Tony Hailes [mailto:tony.hai...@ttp.com] 
Sent: vrijdag 17 april 2015 16:48
To: users@subversion.apache.org
Subject: Subversion Exception diff_editor.c 1626

 

Whilst doing diff with url on a large tree with some files branched from
the trunk:

---

Subversion Exception!

---

Subversion encountered a serious problem.

Please take the time to report this on the Subversion mailing list

with as much information as possible about what

you were trying to do.

But please first search the mailing list archives for the error message

to avoid reporting the same problem repeatedly.

You can find the mailing list archives at

http://subversion.apache.org/mailing-lists.html

 

Subversion reported the following

(you can copy the content of this dialog

to the clipboard using Ctrl-C):

 

In file

'D:\Development\SVN\Releases\TortoiseSVN-1.8.11\ext\subversion\subversion\li
bsvn_wc\diff_editor.c'

line 1626: internal malfunction

---

OK   

---

RE: Path-based authorization ignores most specific path

[Bert Huijben]

 -Original Message-
 From: all-li...@stefan-klinger.de [mailto:all-li...@stefan-klinger.de]
 Sent: zondag 12 april 2015 12:47
 To: users@subversion.apache.org
 Subject: Path-based authorization ignores most specific path
 
 Hello!
 
 --Summary--
 
 Path-based authorization seems to not work as documented
 currently:  The most specific path is *not* used.
 
 Version: server=1.6.17, client=1.8.8 or 1.8.13
 
 Might be a reincarnation of (closed?) Issue 3242:
 
 http://svn.haxx.se/users/archive-2010-01/0124.shtml
 http://subversion.tigris.org/issues/show_bug.cgi?id=3242
 
 
 --Description--
 
 The documentation says (for all versions since 1.5):
 
 The thing to remember is that the most specific path always
 matches first.
 

http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
 
 I'm having the following lines concerning repository `proj` in my
 `access` file.  As you can see, `/pub` should be publicly readable,
 but nothing else:
 
 Current access file contains:
 
 [groups]
 proj_staff = [...]
 proj_other = [...]
 
 [proj:/]
 @proj_staff = rw
 @proj_other = r
 
 [proj:/pub]
 * = r
 @proj_staff = rw
 
 [proj:/eval]
 @proj_other =
 
 [proj:/group]
 @proj_other = rw
 
 [proj:/group/foo]
 foo = rw
 
 The problem is:
 
   * I can *NOT* `svn co https://...proj/pub` without authentification.

For the record: I don't see anything in your config that you setup anonymous
authentication. Even with a * = r line some operations might still need to
know who you are, even though everybody has access to read.


For 1.8.x a checkout will retrieve inherited properties from all ancestor
directories of where you checked out (see release notes for the new features
that provides), so I'm not surprised that the client asks for your
credentials if you only provide access to those other directories if a user
is authenticated. (Not being able to read the properties is not an issue...
But the client will try to read them, which will produce a prompt)

If there is something on the server side related to your issue everybody
will recommend you to upgrade to a supported Subversion release first. We
only actively support the last revision and the one before that with
bugfixes, so that would be Subversion 1.8.x and 1.7.x. (and soon just 1.9.x
and 1.8.x).

Bert

RE: Changing external to sub-directory yields W155007 and E205011

[Bert Huijben]

You are adding a directory ‘ext’, which makes it a versioned path *inside* the 
repository/working copy and then in the parent directory you set a property 
that it is something *external*.

 

A path can’t be versioned as part of the working copy and be an external at the 
same time. 

 

Once a path is versioned, you can’t shadow it with an external.

(Technically externals aren’t in your working copy… they are a higher level 
abstraction and a working copy by itself)

 

 

As far as I can tell this works as expected.

 

Bert

 

From: Christian K. [mailto:christian.k.2...@gmail.com] 
Sent: woensdag 8 april 2015 17:13
To: users@subversion.apache.org
Subject: Changing external to sub-directory yields W155007 and E205011

 

Dear all,

 

using svn 1.8.11 changing an existing svn:externals property to a sub-directory 
thereof will result in an ... is not a working copy root (combination of 
W20, W155007 and E205011). The attached sequence of commands [1] will 
reproduce the behavior from scratch (Windows batch syntax).

 

The final svn update will result in the attached output [2].

 

Is this regular behavior of svn or is this a bug related to the processing of 
svn:externals?

 

I would expect that changing the value of svn:externals from something valid to 
something else valid should be handled by svn.

 

Thanks and best regards,

 

Christian

 

[1]

svnadmin create repo

svn co file:///%CD%/repo file:///\\%CD%25\repo  wc

 

mkdir wc\foo

mkdir wc\ext

mkdir wc\ext\subdir

 

svn add wc\foo

svn add wc\ext

svn ci -m  wc

 

svn ps svn:externals ^/ext ext wc\foo

svn ci -m  wc

svn up wc

 

svn ps svn:externals ^/ext/subdir ext/subdir wc\foo

svn ci -m  wc

svn up wc

 

 

 

 

[2]

Updating 'wc':

 

Fetching external item into 'wc\foo\ext\subdir':

External at revision 3.

 

svn: warning: W20: Error handling externals definition for 
'wc\foo\ext\subdir':

svn: warning: W155007: 'C:\Temp\wc\foo\ext\subdir' is not a working copy root

Removed external 'wc\foo\ext'

Updated to revision 3.

svn: E205011: Failure occurred processing one or more externals definitions

RE: E160000 due to empty revisions when requesting log by date range (v. 1.8.11)

[Bert Huijben]

Hi,

 

In many cases like this the server really returns an HTTP status 500, but with 
a detailed error report that the client should parse to find the detailed 
error. I’m guessing this error parsing issue is already fixed for 1.9, that is 
now in beta, where the whole error handling in our http/https layer was 
refactored to be more effective.

 

The problem you see is that Subversion doesn’t really have an index on dates 
and tries to perform a binary search on the revision properties to find out 
which revision you really want based on the date you passed. 

 

In theory you would be able to fix this by setting some appropriate svn:date on 
all the revisions that now don’t have one, as I assume your commits in 
chronological order.

(I’m guessing just copying the last seen date to all revisions that don’t have 
a date would work for you)

 

Beer

 

 

From: Eric Johnson [mailto:e...@tibco.com] 
Sent: donderdag 2 april 2015 23:56
To: users@subversion.apache.org
Subject: E16 due to empty revisions when requesting log by date range (v. 
1.8.11)

 

I've got a repository that has quite a number of revisions that are empty. 
Although I don't know the exact history, I'm guessing this is because we dumped 
the repository, and ran it through svndumpfilter, but without the 
--drop-all-empty-revs option, and without the --renumber-revs option. (Since we 
have bug reports that almost certainly refer to the commit #, this seems like 
desired situation.)

 

However, now, when one of my users tries to do:

 

svn log -r {2014-06-10}:{2014-06-15} 

 

... Subversion fails.

 

If I perform the request with HTTP access, Subversion reports:

svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on 
'_/!svn/me'

 

svn: E175002: Additional errors:

svn: E175002: REPORT request on '__/!svn/me' failed: 500 Internal Server 
Error

 

If I perform the request with file:/// file:///\\  access, Subversion reports

svn: E16: Failed to find time on revision __

 

Since Subversion ostensibly supports empty revisions (otherwise svndumpfilter 
shouldn't have the options to preserve them), it seems like a definite bug that 
the date range log request fails.

 

It also seems like a bug that Subversion reports a 500 Internal Server Error 
when used via HTTP. Since Subversion actually detected the error, it should 
pass that error back to the client, so the client has more information about 
the failure.

 

I looked for bugs that match this, and didn't find any. Should I file a bug? Or 
am I doing / configuring something wrong, and there's a way to fix this?

 

I suppose one sort of work-around would be to go through each revision with no 
date, and set the revprop date where it doesn't have one Does someone have 
a script for that already?

 

Eric.

 

 

 

RE: 411 Length Required error thrown, yet Subersion server is not Fronted by proxy or reverse proxy

[Bert Huijben]

Hi,

 

My guess would be that you somehow still use some transparent proxy. Squid is 
commonly setup in this way. A network dump should show you headers in this case.

 

It really depends on your setup, but in most cases the easiest workaround is to 
use https as in general that avoids all proxy issues by encrypting the lower 
layers.

 

What kind of ‘error 400’ do you get when you disable http-chunked-requests? 
Usually this should avoid errors in this case, but without the actual message 
the number 400 doesn’t provide enough information for further investigation.

 

Bert

 

From: Nolan Anderson [mailto:n.ander...@bit-group.com] 
Sent: donderdag 2 april 2015 21:20
To: users@subversion.apache.org
Subject: 411 Length Required error thrown, yet Subersion server is not Fronted 
by proxy or reverse proxy

 

​Dear all,
I am having a fairly bizarre issue (at least bizarre to me) with respect to SVN 
version 1.8.11 and libapache2-svn version 1.8.11-1+WANdisco.
I am running Ubuntu 12.04 LTS and apache 2.2.22 
When I downgrade the libapache2-svn version to 1.6.17dfsg-3ubuntu3.4, 
everything is fine -- however, when I upgrade libapache2-svn, the 411 error 
gets thrown. I've tried changing the http-chunked-requests to 'yes', and I 
still get the same error ('no' gives me the 400 error), I've tried setting the 
http-library option to serf, and there was no change. 
Any help or suspicions would be much appreciated

Thanks so much!
-Nolan  

RE: Branching slow 1.8.11 https

[Bert Huijben]

 -Original Message-
 From: Johan Corveleyn [mailto:jcor...@gmail.com]
 Sent: dinsdag 31 maart 2015 14:13
 To: users@subversion.apache.org
 Cc: Bert Huijben; Philip Martin; Ben Reser
 Subject: Re: Branching slow 1.8.11 https
 
 On Tue, Mar 31, 2015 at 2:19 AM, Johan Corveleyn jcor...@gmail.com
 wrote:
  On Sun, Mar 29, 2015 at 7:57 PM, Johan Corveleyn jcor...@gmail.com
 wrote:
  On Sat, Mar 28, 2015 at 5:09 PM, Bert Huijben b...@qqmail.nl wrote:
 
 
  -Original Message-
  From: Johan Corveleyn [mailto:jcor...@gmail.com]
  Sent: vrijdag 27 maart 2015 22:03
  To: users@subversion.apache.org
  Subject: Branching slow 1.8.11 https
 
  Does the following ring a bell for someone?
 
  Recently upgraded our server (on Solaris 10 SPARC) from 1.5.4 to
  1.8.11 (CollabNet package). Some time after that, we discovered that
  branching was very slow. I'm talking about pure server-side branching
  ('svn copy $URL/trunk $URL/branches/br1'). I'm testing with a 1.8.11
  client (tried both from same machine as the server, and from another
  machine on the LAN (100 Mbit)).
 
  - Branching trunk (containing many directories and files): 6-8 minutes
  - Branching a subfolder of trunk: 20-30 seconds (still very slow)
  - Branching a single file is fast ( 0.5s or so).
 
  So it seems the performance degrades depending on the depth or size of
 the
  tree.
 
  Now, it gets more interesting:
  - The resulting rev file on the server is always very small (as it
  should be, it contains only a lightweight 'copy' of the trunk node).
  - Our repos is currently served via https (Apache 2.2.29).
  - Branching with file:/// urls is fast (branching trunk takes 0.6s).
  - When starting an svnserve instance serving the same repository, and
  branching with svn:// urls, it's fast as well (also 0.6s).
  - We reproduced it on a copy of the production repo.
  - Experimenting with the test copy, we found that
  $repos/dav/activities.d contains ~2000 files. When we clear that
  directory, the branching times go down by more than half (~2 minutes
  for trunk, ~10s for subdir of trunk --- i.e. still slow, but it
  definitely has an impact).
  - With a 1.7 client connecting with neon, the problem is the same.
  - During the 'svn copy', an httpd child consumes a lot of cpu (around
  half a core).
  - There is no authz configured for this repo (SVNPathAuthz off).
  - Backend is still in 1.5 format (we have not run svnadmin upgrade
  yet, a dump+load is planned in a couple of weeks).
 
  So it seems clearly mod_dav_svn related (and not for instance related
  to the FSFS backend).
 
  I don't think we have anything special in our httpd config:
  [[[
 Location /test_svn
SVNInMemoryCacheSize 131072
SVNCacheFullTexts on
SVNCacheTextDeltas on
SSLRequireSSL
AuthName TEST Subversion Repository
AuthType Basic
AuthBasicProvider ldap
AuthBasicAuthoritative off
AuthLDAPURL ldap://redacted:389;
AuthLDAPBindDN redacted
AuthLDAPBindPassword redacted
Require ldap-group redacted
DAV svn
SVNPath /path/to/test_repos
SVNPathAuthz off
 /Location
  ]]]
 
  Any ideas?
  Why the cpu usage by the server, what's it doing?
  What is the dav/activities.d directory for? How come it contains so
  many files? Is it ok to purge the old files from that directory?
 
  Httpd's mod_dav was updated in some recent version to do a full lock
 traversal on copies and moves. I think we already applied some optimizations,
 but the real fix would be that mod_dav shouldn't do this work (which our repos
 layer already does).
 
  I'm not sure which release we applied the first set of optimizations.
 
 
  Thanks for refreshing my memory.
 
  So the problem is known as issue #4531 (server-side copy (over dav)
  uses too much memory) [1]. The memory usage issue has been fixed in
  SVN 1.8.11 and 1.7.19 (see CHANGES), but a performance problem remains
  (copy is no longer O(1), but depends on the size of the tree being
  copied). That's a direct violation of one of Subversion's old selling
  points vs. CVS: that branching / tagging is O(1). Branching / tagging
  taking several minutes brings back fond memories from CVS' days.
 
  As Philip pointed out in his last comment on #4531 [2]: This issue is
  related to a change in mod_dav in 2.2.25 to fix PR54610 which
  added a walk over the copy source looking for lock tokens. (also
  released in 2.4.5; so both httpd 2.2.25+ and 2.4.5+ are affected --
  older httpd's won't have this problem I guess).
 
  Again quoting Philip: Apache knows in advance that the walk is
  redundant in cases such as Subversion's URL-to-URL copy but Subversion
  cannot avoid the read access. We should attempt to fix mod_dav to
  avoid the walk where possible.
 
  So my hope rests with Philip and others who might have the necessary
  knowledge to fix this in mod_dav. It's really not acceptable that
  branching / tagging (or I'm guessing

RE: Branching slow 1.8.11 https

[Bert Huijben]

 -Original Message-
 From: Johan Corveleyn [mailto:jcor...@gmail.com]
 Sent: vrijdag 27 maart 2015 22:03
 To: users@subversion.apache.org
 Subject: Branching slow 1.8.11 https
 
 Does the following ring a bell for someone?
 
 Recently upgraded our server (on Solaris 10 SPARC) from 1.5.4 to
 1.8.11 (CollabNet package). Some time after that, we discovered that
 branching was very slow. I'm talking about pure server-side branching
 ('svn copy $URL/trunk $URL/branches/br1'). I'm testing with a 1.8.11
 client (tried both from same machine as the server, and from another
 machine on the LAN (100 Mbit)).
 
 - Branching trunk (containing many directories and files): 6-8 minutes
 - Branching a subfolder of trunk: 20-30 seconds (still very slow)
 - Branching a single file is fast ( 0.5s or so).
 
 So it seems the performance degrades depending on the depth or size of the
 tree.
 
 Now, it gets more interesting:
 - The resulting rev file on the server is always very small (as it
 should be, it contains only a lightweight 'copy' of the trunk node).
 - Our repos is currently served via https (Apache 2.2.29).
 - Branching with file:/// urls is fast (branching trunk takes 0.6s).
 - When starting an svnserve instance serving the same repository, and
 branching with svn:// urls, it's fast as well (also 0.6s).
 - We reproduced it on a copy of the production repo.
 - Experimenting with the test copy, we found that
 $repos/dav/activities.d contains ~2000 files. When we clear that
 directory, the branching times go down by more than half (~2 minutes
 for trunk, ~10s for subdir of trunk --- i.e. still slow, but it
 definitely has an impact).
 - With a 1.7 client connecting with neon, the problem is the same.
 - During the 'svn copy', an httpd child consumes a lot of cpu (around
 half a core).
 - There is no authz configured for this repo (SVNPathAuthz off).
 - Backend is still in 1.5 format (we have not run svnadmin upgrade
 yet, a dump+load is planned in a couple of weeks).
 
 So it seems clearly mod_dav_svn related (and not for instance related
 to the FSFS backend).
 
 I don't think we have anything special in our httpd config:
 [[[
Location /test_svn
   SVNInMemoryCacheSize 131072
   SVNCacheFullTexts on
   SVNCacheTextDeltas on
   SSLRequireSSL
   AuthName TEST Subversion Repository
   AuthType Basic
   AuthBasicProvider ldap
   AuthBasicAuthoritative off
   AuthLDAPURL ldap://redacted:389;
   AuthLDAPBindDN redacted
   AuthLDAPBindPassword redacted
   Require ldap-group redacted
   DAV svn
   SVNPath /path/to/test_repos
   SVNPathAuthz off
/Location
 ]]]
 
 Any ideas?
 Why the cpu usage by the server, what's it doing?
 What is the dav/activities.d directory for? How come it contains so
 many files? Is it ok to purge the old files from that directory?

Httpd's mod_dav was updated in some recent version to do a full lock traversal 
on copies and moves. I think we already applied some optimizations, but the 
real fix would be that mod_dav shouldn't do this work (which our repos layer 
already does).

I'm not sure which release we applied the first set of optimizations.

Bert
 
 --
 Johan

RE: Apache Subversion 1.9.0-beta1 released

[Bert Huijben]

 -Original Message-
 From: Ben Reser [mailto:bre...@apache.org]
 Sent: donderdag 19 maart 2015 04:58
 To: Subversion Development; users@subversion.apache.org;
 annou...@subversion.apache.org; annou...@apache.org
 Subject: Apache Subversion 1.9.0-beta1 released
 
 I'm happy to announce the release of Apache Subversion 1.9.0-beta1.
 Please choose the mirror closest to you by visiting:
 
 http://subversion.apache.org/download/#pre-releases

For whoever is interested in testing this on Windows. The SlikSvn builds of 
1.9.0-beta1 are now available as:
https://sliksvn.com/pub/Slik-Subversion-1.9.0-beta1-win32.msi (x86 version)
https://sliksvn.com/pub/Slik-Subversion-1.9.0-beta1-x64.msi (x86_x64 version)
(as usual full debug symbols are available in the 
https://sliksvn.com/pub/symbols/ directory)

Installing these miss will automatically upgrade your previous version of 
SlikSvn to this version.


To avoid an installer error on downgrading back to 1.8.x *) manually deinstall 
this version from the Software control panel, before (re)installing the older 
version.

 
Bert

*) The problem is just that setup fails because it can't install with a newer 
version installed.