Re: Can't connect to github anymore

[Branko Čibej]

On 14.01.2024 20:52, Nico Kadel-Garcia wrote:

On Sun, Jan 14, 2024 at 2:27 PM sean  wrote:

On 2024-01-13 16:11, Nico Kadel-Garcia wrote:


There are not many compelling reasons
to use Subversion anymore, except the ability to check out only
subdirectories from a branch and the insistence that a single central
repository is the only source of truth.

The ability to `svn lock` files is very useful if your repo has a lot of
non-mergeable files, like say MS Office documents.

I have never once found that feature to be useful since I first used
Subversion back around 2001.  Mind you, I'd treat Word documents as
binaries objects and not consider them suitable for incremental
changes in a source control system.


X: There's this useful feature that  has but  doesn't.
Y: I've never used that feature so it's useless.

You gotta love that kind of reasoning.

-- Brane

Re: filename encodings and conversion failure

[Branko Čibej]

On 26.12.2022 22:26, Karl Berry wrote:

I certainly don't expect such fundamental behavior to change, but I
can't help but respond a little. Just ignore me :).

 All the world is not Unix
 ...
 the problem of cross-platform compatibility.
 
Of course.  Precisely the reason why storing filenames as bytes would be

more portable than forcing any particular encoding, in principle, seems
to me.



Well my point is that this would not work everywhere. Blame it on 
Subversion's insisting on cross-platform compatibility. The thing that 
stores filenames as bytes is called something else. :)


-- Brane

Re: filename encodings and conversion failure

[Branko Čibej]

On 24.12.2022 21:49, Karl Berry wrote:

 The most classic example is "FILE.TXT" versus "file.txt". According to

To repeat: I'm not talking about case clashes and similar underlying
filesystem problems; other people brought those up.

I'm asking specifically about the failure of the unasked-for
"UTF-8 conversion", which, so far as I can tell, is spontaneously
induced by svn. There is no filesystem problem kind in this case
(standard xfs). That is, I can touch/copy/remove/whatever the file that
svn refuses to work with. -k


Yes there is. Windows file systems (well, at least NTFS) require file 
names in some sort of Unicode encoding. All the world is not Unix and 
even some Unix file systems store file names in UTF-8 (zfs comes to 
mind). Subversion does its best to conform to whatever the local rules 
are, but as you noticed, there are edge cases where that will cause 
problems.


The case you're describing, with some file names in SJIS and some in 
UTF-8, seems simply impossible to me, because we store file names in 
UTF-8 in the repository. So unless someone hacked the Subversion server, 
committing a SJIS file name should be impossible.


Regarding "spontaneously induced", well, this is how Subversion behaves, 
the reasons for that stem from the problem of cross-platform 
compatibility. It's also documented [1]. So assuming you can do some 
magic with file name encoding and expect Subversion to deal with it is, 
let's say, using the wrong tool for the job.


-- Brane

[1] https://svnbook.red-bean.com/en/1.7/svn.advanced.l10n.html

Re: Windows, svn propset svn:ignore *

[Branko Čibej]

On 28.08.2022 14:39, Daniel Sahlberg wrote:
Den fre 26 aug. 2022 kl 15:13 skrev Jon Daley 
:


I don't use Windows, so I can't help you on the escaping of the *,
but I
often use propedit, rather than propset (partly because I can never
remember the order of the directory and the property value), so
that would
be easy enough for a one-off solution.

Also, if you are using TortoiseSVN, can't you just right-click the
directory and set the property that way and avoid the command-line
usage
entirely?


I missed a critical point: This is run as part of an automated script 
(a BAT file). Both the suggestions above work fine, except they 
require manual input in the middle of the script which I'm trying to 
avoid.


Thanks for bringing up these options!

/Daniel



Write the * to a temporary file and use 'svn propset -F'.

-- Brane

Re: subversion 1.14.0 : svn list command takes more time to execute in windows 2012, 2016

[Branko Čibej]

On 12.08.2022 09:44, Channakeshavala, Sriharsha wrote:


Hi Subversion Team,

We have compiled the *subversion 1.14.0* source code successfully with 
below dependent libraries:


 1. Expat 2.2.9
 2. Zlib 1.2.8
 3. Sqlite 3.28.0
 4. Apr 1.6.5
 5. apr-util-1.6.0

*Compilation Machine details:*

Windows 2012 R2

Visual studio 2015

32 bit binaries are generated.

*we see the below issue :*

When we try to execute the below command on Windows 2012 , Windows 2016

*svn.exe list svn://localhost:/svn_repository/AXb0jRxpPUGu.4 
--username LCMUser --password lcmpassword --xml --no-auth-cache*


There is time delay in executing the command:

Whereas with the same binaries, if we execute it in windows 2019. It 
is much faster.


Could you please let us know, what can be the root cause of this issue ?

We even tried with binary packages below:

  * CollabNet
 (supported and
certified by CollabNet ;
/requires registration/)
  * SlikSVN  (32- and 64-bit
client MSI; maintained by Bert Huijben
, SharpSvn project
)

We still see the issue here on windows 2012.

This delay is impacting the performance of our application. Please 
look into this issue as very high priority and let us know.

kindly let us know if you need any further details.

*Other trails:
*We have compiled the subversion 1.14.2 source code successfully with 
below dependent libraries:**


 1. Expat 2.4.8
 2. Zlib 1.2.12
 3. Sqlite 3.39.0100
 4. Apr 1.7.0
 5. apr-util 1.6.1**
 6. apr-iconv 1.2.2**

*Compilation Machine details:*

Windows 2016

Visual studio 2015

Both 32 bit & 64 bit binaries are generated.

There is no difference in performance in executing the svn list 
command as explained above.




Depending on how your machine is configured, resolving the name 
'localhost' could involve a DNS lookup, which (again, depending how your 
network is configured) could be slow. It's not likely to "just" be a 
difference between the Windows versions.


-- Brane

Re: Using IIS as a reverse proxy in front of Apache/SVN

[Branko Čibej]

On 10.06.2021 07:44, Daniel Sahlberg wrote:
Den tors 10 juni 2021 kl 02:23 skrev Daniel Shahaf 
mailto:d...@daniel.shahaf.name>>:


Daniel Sahlberg wrote on Wed, Jun 09, 2021 at 08:18:04 +0200:
> Hi,
>
> We are using VisualSVN server (basically Apache 2.4.48 and
Subversion
> 1.14.1 on Windows) on https://svn.companyname.tld
, listening on port 443.
> Currently this is on a separate server. I need to consolidate
the servers
> and would like to move Subversion to another server already
running IIS
> (serving multiple sites on both port 80 and 443).
>
> My thinking is that IIS should listen for the new hostname, do SSL
> offloading and forward the traffic to 127.0.0.1:[some new port
for Apache].
> I would like to avoid publishing the new port for Apache, since
that would
> mean to relocate all existing working copies.
>
> Does anyone have experience in using IIS as reverse proxy in
front of
> Apache?

Not what you asked, but running the test suite under a reverse proxy
configuration might be informative.


Thanks! I will try to find some time to look at it.

Thinking of it, I guess the question could be generalized as: Is it 
possible to run Subversion behind /any/ kind of reverse proxy?


Yes, it is possible. Subversion doesn't do anything magic. Some time 
ago, many reverse/caching proxies didn't understand some of the 
DAV-related HTTP methods that Subversion uses. I'd hope this is no 
longer the case ... especially as, AFAIK, IIS can be a WebDAV server.


-- Brane

Re: A more permanent home for the add-a-password-to-a-cached-username script? (was: Re: using svn cli with --non-interactive (in scripts) securely, without exposing password)

[Branko Čibej]

On 23.02.2021 17:46, Daniel Shahaf wrote:

If a cron job needs authentication, its credentials need to be stored
somewhere, either in plaintext or in "as good as" plaintext.  I think
storing the passwords in unobfuscated plaintext was a deliberate
decision, informed by CVS's design choices in this regard, but I wasn't
around in the early days.


It was deliberate. Reading those passwords requires access to the 
filesystem, so an attacker either has the affected user's credentials -- 
in which case they probably have access to any encrypted password store 
as well -- or they're root, and in _that_ case all bets are off anyway.


Note that recently operating systems have gone in the direction of _not_ 
letting root do everything without extra checks, so maybe the second 
assumption needs to be reconsidered.


In any case, encrypted or otherwise protected password stores have 
master passwords that have to be stored somewhere for unattended 
operation, so that's just moving the problem one level of indirection away.


-- Brane

Re: upgrading from repo format 1

[Branko Čibej]

On 28.06.2020 13:35, Ben Elliston wrote:
> On Sun, Jun 28, 2020 at 11:04:18AM +, Daniel Shahaf wrote:
>
>> Branko ??ibej wrote on Sun, 28 Jun 2020 11:20 +0200:
>> What are the differences between f1 and f3?  Would «echo 3 > format»
>> (plus perhaps some manual edits) allow current svnadmin's to dump the
>> repository?
> Nope, after echo 3 > format:
>
> svn: E160027: Malformed node-revision skeleton

Right, for pre-1.0 format bumps it's pretty much a given that the
repositories are not compatible.

-- Brane

Re: upgrading from repo format 1

[Branko Čibej]

On 27.06.2020 15:04, Ben Elliston wrote:
> I was a very early SVN user. I have a repo last timestamped January
> 2003 that I want to get files and data out of. When I run svn upgrade,
> I get:
>
> svnadmin: E165005: Expected repository format '3' or '5'; found format '1'


Repository format 1 is really, really old; older, in fact, than
Subversion 1.0, which used format 3 and did not offer backward
compatibility with pre-1.0 repositories.


> Do I need to install an intermediate version of SVN in order to
> upgrade? If so, which version would you advise that I use?

The latest version that I can find that used format 1 is 0.27.0:

https://svn.apache.org/repos/asf/subversion/tags/0.27.0

If you can build that version (which is probably going to be quite
challenging, given its dependencies -- IIRC we still used APR-0.9 and
some old, probably now unavailable version of Berkeley DB), you can then
dump the repository with that old version of 'svnadmin'. It's likely
that the current svnadmin can read such old dumps.

(And if not -- surely that's a bug and can be fixed because we do
promise to support repository dump formats indefinitely.)

-- Brane

Re: Bug: Svn client will no longer connect to old SVN server

[Branko Čibej]

On 15.06.2020 09:43, Michael Back wrote:
> Hello Subversion folks,
>
> When I upgraded to the latest version of my Linux OS (Ubuntu 20.04)
> and installed Subversion 1.13.0 client, svn could no longer connect to
> our company's old subversion server via https.
>
> $ svn --version
> svn, version 1.13.0 (r1867053)
>    compiled Mar 24 2020, 12:33:36 on x86_64-pc-linux-gnu
>
> Copyright (C) 2019 The Apache Software Foundation.
> This software consists of contributions made by many people;
> see the NOTICE file for more information.
> Subversion is open source software, see http://subversion.apache.org/
>
> The following repository access (RA) modules are available:
>
> * ra_svn : Module for accessing a repository using the svn network
> protocol.
>   - with Cyrus SASL authentication
>   - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
>   - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV protocol
> using serf.
>   - using serf 1.3.9 (compiled with 1.3.9)
>   - handles 'http' scheme
>   - handles 'https' scheme
>
> The following authentication credential caches are available:
>
> * Gnome Keyring
> * GPG-Agent
> * KWallet (KDE)
> $ svn update
> Updating '.':
> svn: E170013: Unable to connect to a repository at URL
> 'https://something.something.com/repos/something/trunk'
> svn: E120171: Error running context: An error occurred during SSL
> communication
>
> Doing a checkout results in the same error.
>
> The server (I am told) is running RHEL 6.10 with OpenSSL 1.0.1.
>
> I understand that the old server is limited to using the old insecure
> TLSv1...  I'm not IT though with no power to upgrade the server... and
> I just want to use our internal system.  How do I configure the new
> svn to connect to the old server?


I think that TLSv1 is no longer supported by newer versions of OpenSSL.
You'll either have to somehow downgrade OpenSSL on your client (*not*
recommended!) or get your IT to upgrade the server. Which they should've
done years ago.

-- Brane

Re: Ignore every file except XX*

[Branko Čibej]

On 13.06.2020 12:09, Daniel Shahaf wrote:
> Branko Čibej wrote on Sat, 13 Jun 2020 09:51 +00:00:
>> On 13.06.2020 11:15, Daniel Shahaf wrote:
>>> Daniel Sahlberg wrote on Fri, 12 Jun 2020 21:14 +0200:
>>>>> Care to move this over to dev@ with a patch?
>>>>>  
>>>> Will do, it might take a few days.
>>>>
>>>> Thanks to the other users for their suggestions but I don't think they'll
>>>> be general enough for my use case.
>>> Care to explain why patterns with negated character classes wouldn't work?
>> There's a difference between saying, "ignore everything except '*.doc'"
>> and "ignore '*.[^d][^o][^c]'".
> Did you read my previous message in this thread?  If you have, then
> you've just committed a strawman, and that's unlike you.
>
> (And for the record, the complement of «*.doc» is 
> «*[^c]|*[^o]c|*[^d]oc|*[^.]doc|».)

|? There's no such operator in glob patterns.

>> You can't get the same result with negated character classes as with
>> pattrerns.
> I'm aware of that, and have said so in so many words, but the problem
> statement was "Ignore everything except XX* and YY*", and that _can_ be
> achieved with negated patterns.

Well ok, sure, for any concrete pattern you can theoretically construct
its inverse with negated character classes (assuming an "or" operator
exists). But it's not always trivial nor practical. I think it's worth
exploring possible solutions that are also user-friendly.

> At this point I'd rather wait for Daniel to answer my question and
> clarify his problem statement.

I rather suspect that XX* and YY* were just general examples, not
concrete ones.

-- Brane

Re: Ignore every file except XX*

[Branko Čibej]

On 13.06.2020 11:15, Daniel Shahaf wrote:
> Daniel Sahlberg wrote on Fri, 12 Jun 2020 21:14 +0200:
>>> Care to move this over to dev@ with a patch?
>>>  
>> Will do, it might take a few days.
>>
>> Thanks to the other users for their suggestions but I don't think they'll
>> be general enough for my use case.
> Care to explain why patterns with negated character classes wouldn't work?

There's a difference between saying, "ignore everything except '*.doc'"
and "ignore '*.[^d][^o][^c]'". You can't get the same result with
negated character classes as with pattrerns.

-- Brane

Re: Ignore every file except XX*

[Branko Čibej]

On 12.06.2020 08:24, Matt Simmons wrote:
> Have you considered a pre-commit hook to deny anything not matching
> your rule?

A pre-commit hook doesn't see the contents of the working copy, it's
completely unsuitable for this use case.

-- Brane


> On Thu, Jun 11, 2020 at 11:21 PM Branko Čibej  <mailto:br...@apache.org>> wrote:
>
> On 12.06.2020 07:30, Daniel Sahlberg wrote:
> > Hi,
> >
> > Thanks for your quick response!
> >  
> >
> >     The way I solve a similar case is to set svn:ignore to '*',
> i.e., to
> >     ignore everything, then just 'svn add' the files I want
> under version
> >     control. It's not ideal, as you'd miss the files you're
> interested in.
> >
> >
> > Already doing this. But sometimes we forget to 'svn add' a new file
> > which then doesn't show up as modified. User error, surely, but
> if the
> > mistake can be avoided :-)
> >  
> >
> >     About feature design -- unfortunately we can't just invent a
> >     syntax that
> >     would invert the meaning of the glob patterns in svn:ignore,
> as that
> >     would break backward compatibility. Any ideas for a solution
> would be
> >     most welcome.
> >
> >
> > Exactly my thoughts. The only solution I see is to add a new
> property
> > svn:unignore which is applied after (or in conjunction with) the
> > svn:ignore property. A file is ignored if it matches the svn:ignore
> > glob pattern AND NOT matches the svn:unignore glob pattern. If
> > svn:unignore is empty (or non-existent), the behaviour should be
> > exactly the same as today.
> >
> > The code should be reasonably simple (but I have not analyzed if it
> > would affect anything in the public interface) - only question if
> > maintainers think a new property is a good idea.
>
> I can't think of a way to solve this without introducing a new
> property
> (actually, two new properties, the other has to be the opposite of
> svn:global-ignores). The code would, indeed, be quite simple; the
> complex part has already been done, and adding the additional "and not
> matches X" logic should be trivial.
>
> Care to move this over to dev@ with a patch?
>
> -- Brane
>
> -- 
> "Today, vegetables... Tomorrow, the world!" 

Re: Ignore every file except XX*

[Branko Čibej]

On 12.06.2020 07:30, Daniel Sahlberg wrote:
> Hi,
>
> Thanks for your quick response!
>  
>
> The way I solve a similar case is to set svn:ignore to '*', i.e., to
> ignore everything, then just 'svn add' the files I want under version
> control. It's not ideal, as you'd miss the files you're interested in.
>
>
> Already doing this. But sometimes we forget to 'svn add' a new file
> which then doesn't show up as modified. User error, surely, but if the
> mistake can be avoided :-)
>  
>
> About feature design -- unfortunately we can't just invent a
> syntax that
> would invert the meaning of the glob patterns in svn:ignore, as that
> would break backward compatibility. Any ideas for a solution would be
> most welcome.
>
>
> Exactly my thoughts. The only solution I see is to add a new property
> svn:unignore which is applied after (or in conjunction with) the
> svn:ignore property. A file is ignored if it matches the svn:ignore
> glob pattern AND NOT matches the svn:unignore glob pattern. If
> svn:unignore is empty (or non-existent), the behaviour should be
> exactly the same as today.
>
> The code should be reasonably simple (but I have not analyzed if it
> would affect anything in the public interface) - only question if
> maintainers think a new property is a good idea.

I can't think of a way to solve this without introducing a new property
(actually, two new properties, the other has to be the opposite of
svn:global-ignores). The code would, indeed, be quite simple; the
complex part has already been done, and adding the additional "and not
matches X" logic should be trivial.

Care to move this over to dev@ with a patch?

-- Brane

Re: Ignore every file except XX*

[Branko Čibej]

On 11.06.2020 10:46, Daniel Sahlberg wrote:
> Hi,
>
> Not sure if this belongs in users or in dev so I follow the guidelines
> and post here first.
>
> I would like to svn:ignore every file (in a certain path) except files
> starting with XX or YY.
>
> This question seems to have been asked in 2006 ("inverse of svn:ignore
> property"). I've tried to trace the code and it seems nothing came out
> of this.
>
> Considering there has been 14 years of development, is there another
> way to solve this nowadays?

There's no explicit "inverse of svn:ignore" property, or any magic
syntax that would invert the match.

The way I solve a similar case is to set svn:ignore to '*', i.e., to
ignore everything, then just 'svn add' the files I want under version
control. It's not ideal, as you'd miss the files you're interested in.

About feature design -- unfortunately we can't just invent a syntax that
would invert the meaning of the glob patterns in svn:ignore, as that
would break backward compatibility. Any ideas for a solution would be
most welcome.

-- Brane

Re: Rescue Linux tool svnwcrev from abandoning. Does someone have a copy we can add to github ?

[Branko Čibej]

On 05.06.2020 14:22, Roelof Berg wrote:
> Update: Topic solved.
>
> I will create a script named SubWCRev.sh with a content like:
>
> #!/bin/bash
> echo -n "{\""
> echo -n `svn info | grep -e "^URL: " | sed 's/URL: //g'`
> echo -n "\",\""
> echo -n `svn info | grep -e "^Revision: " | sed 's/Revision: //g'`
> echo "\",\"\"}"

Depending on your version of the client, 'svn info' might accept a
--show-item option that will make parsing its output quite a bit easier:
the first instance becomes

    svn info --show-item=url


and the second instance

    svn info --show-item=revision


and you no longer need 'grep' or 'sed'. See: 'svn help info'.

-- Brane

> Thanks for your support, I don’t need access to svnwcrev anymore.
>
>> Am 05.06.2020 um 13:51 schrieb Roelof Berg > >:
>>
>> Update: I figured out, I need only an app that generates something
>> like this line:
>>
>> {"http://svnsrv/svn/entangled_amplifier/Src/spatial_folder","2",""}, 
>>
> […]
>>>
 On Thu, Jun 4, 2020 at 10:05 AM Roelof Berg
 mailto:rb...@berg-solutions.de>> wrote:
> ++
> + Does someone have a copy left of svnwcrev ? +
> ++
>
> […]
>

Re: svn cleanup --remove-unversioned throws E720005 in Windows When Attempting To Delete a Junction

[Branko Čibej]

On 06.05.2020 05:16, Ace Olszowka wrote:
>> If you make a junction pointed at a different folder, not the %TEMP% folder, 
>> does it still fail to cleanup unversioned items?
> Yes; in the actual repo we point to a folder within the source root.
>
>> Also, do you (or someone else) happen to have a Subversion client 
>> (preferably 1.13) that is built with APR 1.6.5 (or any APR prior to 1.7.0) 
>> and if so, could you test this scenario with that client and let us know if 
>> it still fails?
> Unfortunately this is where my skill is lacking, we have for a long
> time depended on the binary drop of TortoiseSVN to give us the CLI
> subversion tooling.
>
> Looking online it appears that VisualSVN has a binary drop
> (https://www.visualsvn.com/files/Apache-Subversion-1.13.0.zip) however
> they are not as detailed on their versioning (at least not in an
> easily accessible manner). Assuming that the Properties Dialog for
> `libapr-1.dll` is reporting correctly the file version indicates
> 1.6.5. This version of the binary still produces the same error.
>
> `svn --version` reports:


Try 'svn --version --verbose', this will show the APR and APR-Util
versions, too.

They'll probably be the same that TortoiseSVN reports.

-- Brane

Re: Who else is using SVN for large-binary-asset storage?

[Branko Čibej]

On 25.04.2020 20:18, Daniel Shahaf wrote:
> Mark Phippard wrote on Sat, 25 Apr 2020 18:01 +00:00:
>> But the final goal should be something like this (in order of importance):
>>
>> 1. Do not store a pristine in working copy for the file
>> 2. Do not do deltification on the client when committing
>> 3. Do not do compression on server when storing
>> 4. Do not do deltification on server
> Does #4 apply to commits, updates, or both?

#3 and #4 are both moderately pink herrings. The problem with
compression and deltification on the server (for in-repository storage)
is that it's currently done synchronously at transaction-commit time.
There are good reasons to change that to asynchronous post-processing,
possibly as part of 'svnadmin pack'.

-- Brane

Re: Who else is using SVN for large-binary-asset storage?

[Branko Čibej]

On 25.04.2020 20:01, Mark Phippard wrote:
> While hand-waving on all of the details, it seems like if we had some
> property one could put on a file


Not to step on anyone's enthusiasm, but it would be much better if
people could find a way to identify files that are "large binaries" in
an way that doesn't require users to set file properties at 'svn add'.
(Inherited) auto-props are one mechanism that we already have, but:

    what is a large binary file that shouldn't be deltified?

is the important question here. The idea is to have reasonable default
behaviour out of the box, without adding mandatory configuration knobs.

-- Brane

Re: svn:ignore of checked in files and commit

[Branko Čibej]

On 15.04.2020 13:27, Attila Kinali wrote:
> Hi,
>
> In the days of old, like several years back...
> When we had files that needed to be edited localy for each user/developer,
> we used to check them in normally, then set svn:ignore to ignore those
> files. This would result `svn commit` to ignore those files unless 
> forced to by explicitly mentioning the filename (e.g., `svn commit 
> ignoredfile`).

I don't remember svn:ignore *ever* working the way you describe. Can you
tell us which version of Subversion you were using? Are you absolutely
sure it wasn't modified to behave as you describe?



> Apparently this doesn't work anymore and svn commit happily still
> uses the ignored file and commits it... causing problems.
>
> Is there a specific reason this behaviour changed?

Like I said, it did not change. Files that are already
version-controlled cannot be ignored. This was part of the original
svn:ignore design spec, and the behaviour is actually based on .cvsignore.


> Is there a workaround that we can use?

Sure, don't commit the files that you don't want in the repository.
Instead, create a template that each user can rename to an (ignored)
local name.



> Shall I submit a bugreport for this?

It's not a bug.

-- Brane

Re: differ file in SVN checkout and export

[Branko Čibej]

On 18.02.2020 14:39, Tatyana Irzun wrote:
>
> /We got difference in the same revision and same file but taken by
> export and checkout in SVN client version more or equal than 1.10:/
>
> /$ svn co https://svn-test.net/svn/test/ -r9 checkout
> Checked out revision 9.
> $ svn export https://svn-test.net/svn/test/ -r9 export
> A export
> A export/EmptyStandbyList.exe
> Exported revision 9.
> $ diff checkout/EmptyStandbyList.exe export/EmptyStandbyList.exe/
>
> /$ md5sum export/EmptyStandbyList.exe
> 10ab6937e720856efd4a315f0f06fcfb  export/EmptyStandbyList.exe
> $ md5sum checkout/EmptyStandbyList.exe
> 10ab6937e720856efd4a315f0f06fcfb  checkout/EmptyStandbyList.exe
>
> /
>
> /no difference as we see/
>
> /$ svn --version
> svn, version 1.9.7 (r1800392)
> compiled Mar 28 2018, 08:49:13 on x86_64-pc-linux-gnu
> $ cd checkout/
> $ svn proplist EmptyStandbyList.exe -v
> Properties on 'EmptyStandbyList.exe':
> svn:special
> *
>
> /
>

Try removing the 'svn:special' property; it shouldn't be set on normal
files.


> /Now we repeat on other version of client:/
>
> /$ svn --version
> svn, version 1.11.1 (r1850623)
> compiled Jun 17 2019, 17:51:58 on x86_64-pc-linux-gnu
> $ svn co https:/svn-test.net//svn/test/ -r9 checkout
> $ svn export https:/svn-test.net//svn/test/ -r9 export
> $ diff checkout/EmptyStandbyList.exe export/EmptyStandbyList.exe
> Binary files checkout/EmptyStandbyList.exe and
> export/EmptyStandbyList.exe differ/
>
> /$ md5sum export/EmptyStandbyList.exe
> 5ddd018068333a4fa03e08b5451b1d52  export/EmptyStandbyList.exe/
>

Please also look at the size of the file and the contents.


> /$ md5sum checkout/EmptyStandbyList.exe
> 10ab6937e720856efd4a315f0f06fcfb  checkout/EmptyStandbyList.exe
>
> /
>
> /$ cd checkout/
> $ svn proplist EmptyStandbyList.exe -v
> Properties on 'EmptyStandbyList.exe':
> svn:special
> *
> /
>
>
> //( also we repeated tests on different client versions and systems
> with the same result)//
>
> /
> How we simulate situation:
> 1) we made a link to file in linux system
> $ ln -s ../EmptyStandbyList.exe EmptyStandbyList.exe
> $ ll
> EmptyStandbyList.exe -> ../EmptyStandbyList.exe
> 2) commit this
> $ svn add EmptyStandbyList.exe
> $ svn commit -m "add link"
> 3) in windows client Tortoise  we just replaced link by actual binary
> file and committed again
> /
>

... and did not remove the svn:special property at the same time.

Maybe Subversion should just error out when it sees that the contents of
a "symlink" changed in a way that it clearly is no longer a valid link
description?

-- Brane

Re: Why option --diff and -q of svn log are mutually exclusive

[Branko Čibej]

On 22.12.2019 04:55, Daniel Shahaf wrote:
> wuzhouhui wrote on Sun, 22 Dec 2019 03:29 +00:00:
>> When I use
>>
>> svn log -q --diff
>>
>> to display only different of every revision, the svn report error:
>>
>> svn: E205000: Try 'svn help log' for more information
>> svn: E205000: 'quiet' and 'diff' options are mutually exclusive
>>
>> I just don't understand why option --diff and -q are mutually exclusive?
>> Can we remove this limitation?
> I don't see any reason for this restriction either, and the combination
> does seem to work, once the check is removed.  Why should this
> restriction be kept?

I don't think there's any good reason, except perhaps for considerations
about documenting the behaviour. 'svn log -q -v' works ... by the
principle of least surprise, 'svn log -q --diff' should work, too.

At a glance, the help message doesn't need changing, either.

-- Brane

Re: How do I enable storing of plaintext passwords?

[Branko Čibej]

On 15.12.2019 22:49, Barry wrote:
>
>> On 15 Dec 2019, at 15:29, Branko Čibej  wrote:
>>
>> On 15.12.2019 14:46, Barry Scott wrote:
>>> I'm doing some testing and want to test with plaintext passwords.
>>>
>>> It seems that storing plaintext passwords can be compiled out. Is that why 
>>> I cannot configure it back on?
>>
>> https://subversion.apache.org/docs/release-notes/1.12.html#client-server-improvements
> Aha, that explains why it works on some systems with older svn. Been working 
> on Centos 7 with svn 1.7 for some tests.
>
>> If you want to use plaintext passwords on disk, you'll have to build
>> Subversion from source and explicitly enable that feature.
> What had me confused for a while is that if the svn.simple/123... file was 
> written by an earlier svn then 1.12 with a plaintext password that password 
> is used with the newer svn versions.

Yes, existing password records are still used, but new ones will not be
written by 1.12 and newer versions.

-- Brane

Re: How do I enable storing of plaintext passwords?

[Branko Čibej]

On 15.12.2019 14:46, Barry Scott wrote:
> I'm doing some testing and want to test with plaintext passwords.
>
> It seems that storing plaintext passwords can be compiled out. Is that why I 
> cannot configure it back on?


https://subversion.apache.org/docs/release-notes/1.12.html#client-server-improvements


If you want to use plaintext passwords on disk, you'll have to build
Subversion from source and explicitly enable that feature.

-- Brane

Re: What is the permissible character set for @group references in path-based auth?

[Branko Čibej]

On 15.12.2019 11:43, sebb wrote:
> On Sun, 15 Dec 2019 at 00:52, Branko Čibej  <mailto:br...@apache.org>> wrote:
>
> On 14.12.2019 14:08, sebb wrote:
> > On Sat, 14 Dec 2019 at 12:03, Daniel Shahaf
> mailto:d...@daniel.shahaf.name>
> > <mailto:d...@daniel.shahaf.name <mailto:d...@daniel.shahaf.name>>>
> wrote:
> >
> >     sebb wrote on Sat, 14 Dec 2019 09:12 +00:00:
> >     > The only documentation I could find [1] defines a key using
> >     :
> >     >
> >     >  ::= (any character except )
> >     >
> >     > However the character domain is not specified as far as I
> can tell.
> >
> >     I don't know where you're quoting that from.  It's not on
> the linked
> >     page or anywhere else that I can find.  It's also patently false
> >     because '=' and ' '
> >     can't be parts of a group name, because if they were then
> «@foo =
> >     rw» would
> >     be misparsed.
> >
> >
> > I should have been clearer.
> > I did not mean that a key consists of text-char only.
> >
> > The key is defined in BNF in the Formal Definition section (once
> opened).
> > Follow the BNF through, and one of refs is :
> >
> > key => key-cont => key-char => text-char
> > (where => means refers to)
> >
> > i.e. the key definition uses text-char.
> >
> > So in order to know what is allowed in a key, one needs to know
> what a
> > character is.
>
> So what exactly is missing from the definition: "any character
> except "?
>
>
> The character set.

We don't define that, on purpose, as I already explained.

> Is it ASCII or UTF-8 or something else?

I explained that, too.

> Can one use CR, NUL or DEL in keys?


I don't know. Probably. There's no code that I'm aware of that would
prevent you from using them.

Well, NUL would very likely cause problems since the implementation
relies on C string semantics. Good catch.


> Have such characters been tested?

No. The idea is that these are normal text files. If you have a
particular need to use bytes that are not normal in text, feel free to
test them and report your findings here.

 
>
> Subversion doesn't define the source character set. It does implicitly
> expect it to be a superset of ASCII, and uses UTF-8 internally. That
> document intentionally doesn't define what a "character" is except for
> special codes that the parser recognizes as delimiters, depending on
> context.
>
> -- Brane
>

Re: What is the permissible character set for @group references in path-based auth?

[Branko Čibej]

On 14.12.2019 14:08, sebb wrote:
> On Sat, 14 Dec 2019 at 12:03, Daniel Shahaf  > wrote:
>
> sebb wrote on Sat, 14 Dec 2019 09:12 +00:00:
> > The only documentation I could find [1] defines a key using
> :
> >
> >  ::= (any character except )
> >
> > However the character domain is not specified as far as I can tell.
>
> I don't know where you're quoting that from.  It's not on the linked
> page or anywhere else that I can find.  It's also patently false
> because '=' and ' '
> can't be parts of a group name, because if they were then «@foo =
> rw» would
> be misparsed.
>
>
> I should have been clearer.
> I did not mean that a key consists of text-char only.
>
> The key is defined in BNF in the Formal Definition section (once opened).
> Follow the BNF through, and one of refs is :
>
> key => key-cont => key-char => text-char
> (where => means refers to)
>
> i.e. the key definition uses text-char.
>
> So in order to know what is allowed in a key, one needs to know what a
> character is.

So what exactly is missing from the definition: "any character except "?

Subversion doesn't define the source character set. It does implicitly
expect it to be a superset of ASCII, and uses UTF-8 internally. That
document intentionally doesn't define what a "character" is except for
special codes that the parser recognizes as delimiters, depending on
context.

-- Brane

Re: Bug in docs regarding case-sensitivity?

[Branko Čibej]

On 14.12.2019 14:38, sebb wrote:
> On Sat, 14 Dec 2019 at 13:33, Daniel Shahaf  > wrote:
>
> sebb wrote on Sat, 14 Dec 2019 13:17 +00:00:
> > On Sat, 14 Dec 2019 at 11:51, Daniel Shahaf
> mailto:d...@daniel.shahaf.name>> wrote:
> > > sebb wrote on Sat, 14 Dec 2019 09:20 +00:00:
> > >  > The code comment here [1] and the wiki [2] both state that
> section name
> > >  > matching is case-insensitive.
> > >  >
> > >  > However my reading of the document here [3] says this
> changed in version 1.7.
> > >
> > >  Thank you for taking the time to point out the specific text
> within that
> > >  page you had in mind, to save us all looking for it. (It's
> the first
> > >  "No Entry" box.)
> > >
> > >  > These docs don't seem consistent to me.
> > >
> > >  The two documents describe different layers. [1] and [2]
> describe the
> > >  configuration parsing module (svn_config_*), whereas [3] —
> says that
> > >  the implementation of authz (≤1.6) did case conversions
> before or after
> > >  calling svn_config_*().
> > >
> >
> > However [2] says:
> >
>
> [2] is not normative.  The C API docs are normative.  The API errata,
> release notes, and CVE advisories are all fair game.  But the wiki
> serves
> as the whiteboard in our virtual office; it isn't API documentation.
>
> However [1] says:
>
> "Section and option names are case-insensitive, but case is preserved."


Configuration files and authz files no longer use the same
representation. Since you've been reading the section on config files in
the wiki, I propose you also read this:

https://cwiki.apache.org/confluence/display/SVN/Path-Based+Access+Control

It's far from finished, but it *does* describe the differences in syntax
and semantics.

-- Brane

Re: error 'Network connection closed unexpectedly' while svn update

[Branko Čibej]

On 09.12.2019 13:54, Detlef Braungardt wrote:
> Hi Nathan,
>
>
> thanks for your information.
>
> I tried the TortoiseSVN version 1.13.1 now. But the failure persists.


The issue Nathan linked to was a server-side problem, changing the
client version would not be expected to make a difference.


> It is not so easy to update the subversion version on the server. This
> is a production system.
> I will try to set up a test system and repeat the test. And then I
> will send you an anwer.


Thanks for that. It's sometimes really difficult to reproduce a failure
without access to the original dataset.

-- Brane

Re: Remove revision range from repository

[Branko Čibej]

On 05.12.2019 13:01, Josef Wolf wrote:
> Thanks for your answer, Branko!
>
> On Thu, Dec 05, 2019 at 12:11:38PM +0100, Branko Čibej wrote:
>> On 05.12.2019 10:56, Josef Wolf wrote:
>>> I need to permanently remove a range of revisions from a repository, which 
>>> are
>>> not the latest.
>> Take a look at the 'svndumpfilter' tool. It can preserve empty revisions
>> in the output.
> Unfortunately, svndumpfilter can do only path based filtering. Thus, I'd need
> another way to "inject" such empty revisions.

Yes, indeed, you have to do multiple dumps the way you've already
suggested, and for one range of revisions you'd just tell svndumpfilter
to filter all paths. It's not really elegant, but should work.

-- Brane

Re: Remove revision range from repository

[Branko Čibej]

On 05.12.2019 10:56, Josef Wolf wrote:
> Hello,
>
> I need to permanently remove a range of revisions from a repository, which are
> not the latest.
>
> None of the working copies have such a revision checked out (I guess, that
> might be a show-stopper).
>
>
> I know, I can do:
>
> # svnadmin dump /original/repo -r0:1234  > /path/to/dumpfile_1.dmp
> # svnadmin dump /original/repo -r2345:HEAD --incremental > 
> /path/to/dumpfile_2.dmp
> # svnadmin create /new/repo
> # svnadmin load /new/repo <  /path/to/dumpfile_1.dmp 
> # svnadmin load /new/repo <  /path/to/dumpfile_2.dmp
>
> But that would renumber the revisions of the second load command.
>
> Is there any way to insert empty revisions, so that the revision numbers would
> be stable?


Take a look at the 'svndumpfilter' tool. It can preserve empty revisions
in the output.


> BTW: I guess, I'd need to set the uuid to the uuid of the old repository if I
>  don'w want existing working copies to get into trouble?

Any existing working copies may be in trouble in any case. A working
copy that contains an item from a revision that you'll exclude from the
repository will no longer be able to commit or update. Other working
copies will be fine (if you update the UUID).

-- Brane

Re: svn error E720145 with svn cleanup --remove-unversioned

[Branko Čibej]

On 27.11.2019 11:24, LUGNIER, Cédric (CA-CIB) wrote:
>
> Hi,
>
>  
>
> We sometimes have the following error when we do use svn cleanup
> –remove-unversioned under Windows:
>
> svn: E720145: Can't remove directory
> 'C:\dev\Jenkins\workspace\qlib_full
> \Sources\x12ComInterface\_compilation\vc17_Release': The directory is
> not empty.
>

Check the contents of that directory. There may be things in there that
have a very long path name. Windows APIs have a fairly short path-length
limit.

I've seen this problem before when running Subversion tests on Windows
... my solution was to move the whole build tree to the root of the
drive (or use 'subst', sometimes that helps).

-- Brane

Re: Bug in Microsoft Application -Subversion

[Branko Čibej]

On 21.11.2019 10:23, Anantha Chitradurga Venkatesh (Tata Consultancy
Services Limi) wrote:
>
> Hi
>
> This is regarding Bug 438116
> :
> [Subversion]Test blocked - Need test steps - Unable to get
> notifications in channel.
>
> Our internal testing team has come across bug with your Subversion
> application in Teams we were hoping you could address. Please let us
> know if you have any questions or need help, we also have a developer
> support team that can be reached at: microsoftteams...@microsoft.com
> .Can you please let me know
> once this is fixed so I can go in and close this bug?
>
>  
>
> You can also read our documentation here.
> 
>
>
> *Issue*: Unable to get the notifications in channel as the provided
> steps were not clear.
>
> *Repro Steps:​*
>
> 1.Open teams.microsoft.com.​​
>
> 2. Go to teams>>channel.​​
>
> 3. Set up the connector.​​
>
> 4.Enter a name for Subversion ​
>
> 5.Do changes in Subversion portal like New commit.​
>
> ​​
>
> *Actual*: Not able to get notifications after configuring connector in
> the channel​​
>
> *Expected*: User should get notifications for actions performed in
> Subversion site.
>


Problems with "Microsoft Teams" should be reported to Microsoft,
specifically, in one of the ways described here:

https://docs.microsoft.com/en-us/microsoftteams/platform/feedback


-- Brane

Re: Windows 10 November 2019 security updates affecting file:// to Win2003 shares?

[Branko Čibej]

On 20.11.2019 16:17, jimbobmcgee wrote:
> HI all;
>
> Appreciating the woefully out-of-date/unsupported nature of my setup, I 
> thought it might be worth dropping a line to see if anyone else out there 
> might be experiencing issues since this month's Patch Tuesday release.
>
> Prior to the November 2019 updates, our Windows 10 users were successfully 
> using Subversion and/or TortoiseSVN to commit to some old v1.6 repositories 
> stored on a Windows Server 2003 R2 file share, using the file:// protocol.  
> After the November 2019 updates, they are now all told that we "Can't write 
> '/pathto/repo/db/txn-current' atomically: Permission denied" (paraphrased).
>
> No changes were made to the Windows Server (i.e. this isn't a case of the 
> permissions being changed on the server without our knowing).
>
> Running a Procmon (SysInternals) trace during the commit process suggests 
> that the updated Win10 clients are getting a different behaviour when the 
> txn-HEX file is renamed to txn-current.  Procmon reports that a 
> SetRenameInformationFile operation gets a 0xC0D5 error, where not-updated 
> clients do not get an error.
>
> I can't find much on the error code 0xC0D5, except in a NTSTATUS values 
> reference, where it suggests that the source file might already have been 
> renamed.
>
> We've tried here with svn.exe builds (from sliksvn.com) and TortoiseSVN 
> builds at both v1.11.1 and v1.13.0.  Commits to another Win2008R2 server are 
> successful, as are commits from anyone who hasn't installed the November 2019 
> updates.
>
> Not expecting anything to be done to support such an old setup, of course -- 
> we have now moved all our repositories to another server -- but I thought I'd 
> see if anyone else was experiencing the same issue?  At least it might be 
> searchable for future generations!


This is actually interesting, and thanks for describing the issue. It
appears that Windows is not backward-compatible with itself. :)

-- Brane

Re: Windows 10 November 2019 security updates affecting file:// to Win2003 shares?

[Branko Čibej]

On 20.11.2019 18:57, Nathan Hartman wrote:
> On Wed, Nov 20, 2019 at 10:59 AM jimbobmcgee
>  > wrote:
>
> HI all;
>
> Appreciating the woefully out-of-date/unsupported nature of my
> setup, I thought it might be worth dropping a line to see if
> anyone else out there might be experiencing issues since this
> month's Patch Tuesday release.
>
> Prior to the November 2019 updates, our Windows 10 users were
> successfully using Subversion and/or TortoiseSVN to commit to some
> old v1.6 repositories stored on a Windows Server 2003 R2 file
> share, using the file:// protocol.  
>
>
> Have you considered running svnserve on that Windows Server 2003 box
> and then accessing the repository from your client machines via the
> svn:// protocol?
>
> This will require either re-checking-out working copies on the client
> machines or updating their URLs with

No, just pointing to the new URL will be enough.


> svn switch --relocate (or through TortoiseSVN).

  2. The '--relocate' option is deprecated. This syntax is equivalent to
 'svn relocate FROM-PREFIX TO-PREFIX [PATH]'.



So, 'svn relocate', not 'svn switch --relocate'. :)

-- Brane

Re: Building subversion runs svnversion, which fails

[Branko Čibej]

On 18.11.2019 16:14, Ryan Schmidt wrote:
> On Nov 18, 2019, at 08:44, Ryan Schmidt wrote:
>
>> The relevant part in the log is where it says:
>>
>> (subversion/svnversion/svnversion . 2> /dev/null ||  \
>>   svnversion . 2> /dev/null ||\
>>   echo "unknown"; \
>>  ) > 
>> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_subversion/subversion/work/destroot/opt/local/include/subversion-1/svn-revision.txt
>> /bin/sh: line 1: 61814 Abort trap: 6   
>> subversion/svnversion/svnversion . 2> /dev/null
> And just to be clear, it should work if it were changed so that it ran:
>
> (DYLD_LIBRARY_PATH=where/the/built/libs/are subversion/svnversion/svnversion 
> . 2> /dev/null ||  \
>svnversion . 2> /dev/null ||\
>echo "unknown"; \
>   ) > 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_subversion/subversion/work/destroot/opt/local/include/subversion-1/svn-revision.txt
>

As I wrote earlier, the real problem is that 'revision-install' runs
before 'local-install' has finished. The binaries have RPATH to the
install location embedded in them, so clearly the libraries haven't been
installed at the point where svnversion is run.

-- Brane

Re: Building subversion runs svnversion, which fails

[Branko Čibej]

On 17.11.2019 22:24, Nathan Hartman wrote:
> On Sun, Nov 17, 2019 at 2:47 PM Ryan Schmidt  2...@ryandesign.com > wrote:
> > Hi, I noticed this bug in subversion on macOS. I reported it here:
> > 
> > https://trac.macports.org/ticket/59712
> > 
> > But it's really an upstream issue so I would like to report it here
> > as well.
> > 
> > The subversion build evidently runs the just-built svnversion at
> > some point. This crashes, because the libraries it's linked with
> > haven't been installed yet, and I guess it's not setting
> > DYLD_LIBRARY_PATH to the path where the built libraries are. I
> > assume that the fix will be setting that variable.
>
> I am not an expert on this subject but IIRC setting DYLD_LIBRARY_PATH
> will *not* help because of something called SIP (System Integrity
> Protection) on macOS.


SIP only affects how DYLD_LIBRARY_PATH works for system binaries, not
stuff you build yourself. For example, our test suite runs just fine in
the build directory with DYLD_LIBRARY_PATH set, but the Python (2)
bindings test suite does not, because it's run by the system Python binary.


Anyway: the short-term solution would be to run 'make install' with
'-j1' so that local-install runs before revision-install. The long-term
solution is to either remove that useless stanza from the Makefile, or
add proper dependencies between those two targets.

-- Brane

Re: svn copy twice to same folder creates unexpeted subfolder in destination

[Branko Čibej]

On 07.11.2019 14:16, Roger Périat wrote:
> Hi all
>
> Not sure if this is a bug or not.
>
> Doing a svn copy twice to same destination, does create an unexpected
> subfolder in destination.
>
> 1) first step
>
> (The tags folder exists and is empty)
>
> svn copy file:///D:/tmp/myrepo/trunk file:///D:/tmp/myrepo/tags/v1 -m
> "this is v1"
>
> What we see:
>
> - v1 is created in tags by this command
>
> - v1 contains a copy of trunk after this command
>
> - All ok until now.
>
> 2) second step
>
> Issuing the same command once more, I would expect an error saying the
> destination folder ('v1') already exists. But this is not the case,
> the command ends normally.
>
> svn copy file:///D:/tmp/myrepo/trunk file:///D:/tmp/myrepo/tags/v1 -m
> "Redoing the tag v1, without deleting the tag before."
>
> What we see:
>
> In the tags/v1 subfolder a new folder is created by this command,
> named ‘trunk’ which contains a copy of the trunk. URL of new folder:
> /tags/v1/trunk
>
> If I issue the command once more, the command fails with E160020 (with
> text Path file:///D:/v1/trunk already exists)
>
>
> Why does the svn copy command not fail at step 2?
>
> Subversion 1.12.2 running here
>
> Thank you for your time!


Because that's how 'svn copy' is supposed to work, and is also
documented. It works the same way as a recursive copy on a filesystem on
Unix:

$ mkdir -p foo/bar
$ touch foo/qux foo/bar/baz
brane@zulu:~/src/test$ find foo
foo
foo/qux
foo/bar
foo/bar/baz
$ cp -R foo zzz
$ find zzz
zzz
zzz/qux
zzz/bar
zzz/bar/baz
$ cp -R foo zzz$ find zzz
zzz
zzz/qux
zzz/foo
zzz/foo/qux
zzz/foo/bar
zzz/foo/bar/baz
zzz/bar
zzz/bar/baz




-- Brane

Re: Limit on Number of Users

[Branko Čibej]

On 17.10.2019 20:25, Shamoon, Danial wrote:
>
> Hi,
>
>  
>
> My team at work uses SVN to manage our software releases.  We recently
> added several users to the repository and now there seems to be a
> user-limit issue.  From what I’ve read on the forums, there does not
> seem to be a limit regarding number of users on SVN.  But our European
> team claims they have reached a maximum of 15 users and are now trying
> to inquire purchasing a license to extend that.  Can you please help
> shed some light on our issue and what I would need to purchase to
> resolve it?
>

Subversion is open source and you're not required to pay anything to use it.

You must be using some commercial product that includes Subversion and
has some sort of licensing scheme. You'll have to talk to the vendor of
that product and also think carefully if what you get for your money (on
top of Subversion itself, which is free) is worth the cost.

-- Brane

Re: Questions about a script for regular backups

[Branko Čibej]

On 14.10.2019 15:25, Anton Shepelev wrote:

>> See the example mentioned in the 1.8 release notes [1]:
>>
>>   svnadmin freeze /svn/my-repos -- rsync -av /svn/my-repos /backup/my-repos
> Hmm.  I should also expect a simple freeze/unfreeze pair
> with the caller resposible for unfreezing a fronzen repo...

Nope, you don't need that. If you do need a long-running,
explicitly-unfrozen freeze, you can easily implement it with a smart
enough command. Although, frankly, that way lies a ton of opportunities
for error.

-- Brane

Re: Bug in authz exclusion markers

[Branko Čibej]

On 07.10.2019 13:49, Grierson, David (Lead Engineer) wrote:
> Hi,
>
> I've just deployed Subversion v1.11.1 and have run into an issue with the use 
> of the exclusion marker within authz files.
>
> See the attached authz file for data for the test cases.
>
> This file contains two groups:
>   1. "user-group" is a list of users (which might be used for specific 
> repository access later in the file); membership : namedUser
>   2. "blocked-group" is a list of users who are to be blocked : membership: 
> blockedUser
>
> The authz file contains a rule for the top level access which declares that 
> anyone NOT in the blocked-group should get read-write access. Users in the 
> blocked-group should only get read-only access.
>
> TEST CASES:
>  1. What access does namedUser have?
>
> $ svnauthz accessof svn_access_test --username namedUser
> rw
>
> Result: PASS
>
>  2. What access does blockedUser have?
>
> $ svnauthz accessof svn_access_test --username blockedUser
> r
>
> Result: PASS
>
>  3. What access does unnamedUser (a user who is authenticated to access 
> Subversion but not mentioned in the authz file) have?
>
> $ svnauthz accessof svn_access_test --username unnamedUser
> r
>
> Result: FAIL
>
> My interpretation of this is a bug in the authz validation - can anyone else 
> confirm that my thinking on this is correct or am I missing something with 
> this?


It's hard to say without seeing the actual authz and group definition
files. The authnz handling is interesting enough that we really need
complete information to reproduce and debug. Sometimes the correct
behaviour is not intuitive.

-- Brane

Re: correct API to get current textual WC modifications, for parsing postprocessing

[Branko Čibej]

On 30.09.2019 22:20, Jens Frederich wrote:
> I try to get all line changes in the current changeset. Not sure what
> the right API is.  I have created a delta tree with the following to
> see if it is a file and textual modifications. How do I get the content?
>
>   SVN_ERR(svn_fs_revision_root(_root, fs, base_rev, pool));
>   SVN_ERR(svn_repos_node_editor(, _baton, repos,
> base_root, root, pool, edit_pool)));
>   SVN_ERR(svn_repos_replay2(root, "", SVN_INVALID_REVNUM, TRUE,
> editor, edit_baton, NULL, NULL, edit_pool));
>   *tree = svn_repos_node_from_baton(edit_baton);


You should be looking at the svn_client API, specifically, one of the
svn_client_diff variants. The functions you mentioned above are reading
data from the repository, not from the working copy.

-- Brane

Re: Python 3.X bindings for Subversion on MacOS?

[Branko Čibej]

On 24.09.2019 22:40, Eric Johnson wrote:
> I'm writing some python hook scripts to work with Subversion.
>
> I've used MacPorts to install Subversion. Looking around I see that
> MacPorts only has a package for "subversion-python27bindings", and
> none for python37. Is this just a limitation of MacPorts packaging of
> the official python bindings? From the mailing list, it looks like
> this might have been a limitation as little as six months ago
> .
>
> I could not find a python packaging of the official python bindings on
> pypi.
>
> Should I use subvertpy instead, or maybe pysvn? What's the right
> approach here?

Support for Python 3 bindings is in the works, actually quite close to
being ready for merge to trunk. I expect it to be included in Subversion
1.14. In the meantime, you can still use Python 2.7, it won't magically
stop working.

-- Brane

Re: Perforce checksum mismatch error while importing in svn

[Branko Čibej]

On 23.09.2019 13:20, Kumar, Raushan wrote:
>
> Hi Team,
>
>
> I created a perforce dump using p42svn perl script, it created
> successfully as showing in below screen.
>
> it is created successfully but while importing it on svn server
> showing checksum mismatch error, as showing in below screen.
>

This is obviously a bug in the p42svn script. It's calculating the
checksums incorrectly, and there's not much Subversion can do after the
fact.

Sure, we could add an option to 'svnadmin load' to ignore checksums in
the dump file, but IMO that would be a really silly thing to do, because
the purpose of those checksums is verifying data integrity, and without
that verification one might as well move the repository to /dev/null.

You really should report this to the authors of the p42svn script.

-- Brane

Re: mod_dav_dvn+SVNParentPath with non-repo subdirs

[Branko Čibej]

On 11.06.2019 20:15, Thorsten Schöning wrote:
> Hi all,
>
> I'm hosting SVN-repos using svnserve and by providing the argument
> "--root" with the parent dir of all my repos. In the past, all repos
> have been placed as a direct child of the given path, but recently I
> refactored that to manage repos by customers, topics and stuff. This
> works pretty easy with svnserve as it simply forwards all URLs given
> by clients into the file system, so one can really simply move repos
> into additional subdirs and those get published instantly.
>
> This doesn't work with mod_dav_svn:
>
>> Using this syntax, Apache will delegate the handling of all URLs
>> whose path portions begin with /svn/ to the Subversion DAV provider,
>> which will then assume that any items in the directory specified by
>> the SVNParentPath directive are actually Subversion repositories.
> http://svnbook.red-bean.com/en/1.8/svn.serverconfig.httpd.html
> https://stackoverflow.com/questions/2701915/svn-multiple-repositories-in-subfolders


Indeed, svnserve's --root option has a completely different meaning; it
restricts the search for repositories to a specific subtree of the
filesystem. SVNParentPath requires all repositories to be in one directory.


> I was unable to find reasons and discussions about why things are
> implemented differently,

It's most likely due to hysterical ... pardon me, historical reasons.


>  if changes have already been suggested etc.
> Currently I'm placing a lot "SVNParentPath" in the config of my httpd,
> but would be great if one could reduce that in future.
>
> So, is there a reason why mod_dav_svn doesn't support additional
> subdirs? Is that likely to be changed?

Basically it's as likely as someone contributing a patch for that. Note
that this may not be trivial due to backwards-compatibility concerns,
not only about how repositories are found on disk but also (as Daniel
mentioned) how their names are used in path-based authz rules.

Because of these compatibility issues, it's possible that we couldn't
just change the semantics of SVNParentPath but would have to invent a
third option (SVNRoot?).


> Is it likely that svnserve will stop supporting addiitonal child dirs?

No.


-- Brane

Re: Svn client configuration file

[Branko Čibej]

On 18.09.2019 03:48, William Muriithi wrote:
> Hi Brane,
>
> > The location hierarchy is explained in the book here:
> >
> > http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html
>
> But instead, use a recent client and put auto-props definitions
> into the
> repository instead.
>
>
> Would 1.9.7 clients qualify as a recent client?
>

For auto-props in the repository, yes, they were introduced in 1.8:

https://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config

-- Brane

Re: Svn client configuration file

[Branko Čibej]

On 17.09.2019 21:26, Mark Phippard wrote:
> On Tue, Sep 17, 2019 at 3:21 PM William Muriithi
> mailto:william.murii...@gmail.com>> wrote:
>
> Hello
>
> I want to make sure all the svn clients are using the same
> auto-props.  I am aware this can be set on users home directory
> but prefer to set it up globally in a host.
>
> Do svn clients look for a global file for configuration?
>
>
> The location hierarchy is explained in the book here:
>
> http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html

But instead, use a recent client and put auto-props definitions into the
repository instead.

-- Brane

Re: Breaking svnsync mirrors

[Branko Čibej]

On 06.09.2019 13:23, Grierson, David (Lead Engineer) wrote:
> Hi,
>
> We're in the process of migrating & upgrading our Subversion installation. In 
> doing so we're encountering a handful of repos which were impacted by issue 
> 4129 (https://subversion.apache.org/docs/issue4129).
>
> The fix for this (to dump & reload) has been successful with most of the 
> repos, however to do this you need to have sufficient storage to duplicate 
> the repos; and one of the repos in question is over 700GB in size!
>
> As an alternative, I'm looking to use svnsync to fix this repository; I'm 
> just looking to clarify the process for completing this.
>
> On new host:
>   1) svnadmin create /path/to/new-repo
>   2) Create /path/to/new-repo/pre-revprop-change hook
>   3) svnsync init file:///path/to/new-repo https://url/to/old-repo
>   4) svnsync sync file:///path/to/new-repo
>
> Allow the data to copy across ... then ...
>   5) svnsync copy-revprops --skip-unchanged file:///path/to/new-repo
>
> At this point there will be a copy of the existing repository. Periodically 
> we'll then be able to run the 'svnsync sync' and 'svnsync copy-revprops' to 
> copy across any new revisions.
>
> We'll then schedule the cutover weekend so would perform something like:
>
>   1) Disable access to repos on old host.
>   2) Perform final 'svnsync sync ...' & 'svnsync copy-revprops ...' on new 
> host.
>   3) Shutdown Subversion on old host.
>   4) Remove the following revision properties from revision 0 on 
> /path/to/new-repo
>svn:sync-from-url
>svn:sync-from-uuid
>svn:sync-last-merged-rev
>svn:sync-lock
>
> I just want to confirm that my process seems sensible and that what I've 
> described regarding breaking the svnsync mirror is correct.
>
> If anyone can see anything that I might have wrong or missed?

Looks both sensible and correct to me, except that you seem to be
missing one step:

    5) Copy httpd and/or svnserve configuration and hooks from the old host.

You don't want to keep hooks for the synced repository in the production
repository.

-- Brane

Re: Trying to build svn 1.12.2 from tarball

[Branko Čibej]

On 04.09.2019 15:20, swdev wrote:
> I downloaded serf-1.3.9 and built it using
> scons APR=/home/jonny/subversion APU=/home/jonny/subversion
> ZLIB=/home/jonny/subversion OPENSSL=/home/jonny/subversion
> PREFIX=/home/jonny/subversion
> I then ran a scons check and got the following
> There were 14 failures:
> 1) test_ssl_trust_rootca: test/test_util.c:456: expected <0> but was
> <120199>
> 2) test_ssl_certificate_chain_with_anchor: test/test_util.c:456:
> expected <0> but was <120199>
> 3) test_ssl_certificate_chain_all_from_server: test/test_util.c:456:
> expected <0> but was <120199>
> 4) test_ssl_no_servercert_callback_allok: test/test_util.c:456:
> expected <0> but was <120170>
> 5) test_ssl_large_response: test/test_util.c:456: expected <0> but was
> <120170>
> 6) test_ssl_large_request: test/test_util.c:456: expected <0> but was
> <120170>
> 7) test_ssl_client_certificate: test/test_util.c:456: expected <0> but
> was <120170>
> 8) test_ssl_future_server_cert: test/test_util.c:456: expected <0> but
> was <120199>
> 9) test_setup_ssltunnel: test/test_util.c:456: expected <0> but was
> <120170>
> 10) test_ssltunnel_basic_auth: test/test_context.c:2138: expected <0>
> but was <120170>
> 11) test_ssltunnel_basic_auth_server_has_keepalive_off:
> test/test_context.c:2138: expected <0> but was <120170>
> 12) test_ssltunnel_basic_auth_proxy_has_keepalive_off:
> test/test_context.c:2138: expected <0> but was <120170>
> 13) test_ssltunnel_basic_auth_proxy_close_conn_on_200resp:
> test/test_context.c:2138: expected <0> but was <120170>
> 14) test_ssltunnel_digest_auth: test/test_util.c:456: expected <0> but
> was <120170>
>
> !!!FAILURES!!!
> Runs: 66 Passes: 52 Fails: 14
>
> So, some progress, but I am not sure if I should cary on sown this
> path, or should I use openssl-1.0.x and serf-1.3.8? or some other
> combination?

If you use Serf 1.3.x, then use the latest, 1.3.9, with the latest
OpenSSL 1.0.x.

It's perfectly safe to use the current code on the Serf 1.4.x branch
with OpenSSL 1.1.x. It hasn't been officially released but it's quite
stable and extensively tested on many platforms.

-- Brane

Re: Trying to build svn 1.12.2 from tarball

[Branko Čibej]

On 04.09.2019 15:03, swdev wrote:
> Just downloaded serf-1.3.2 (by editing get-deps.sh).
> Trying to build  serf give the same error as per my original post.
> I think I will send a message to the serf mailing list to see if they
> can shed any light on the matter.

We can, and I just did. :)

-- Brane

Re: Trying to build svn 1.12.2 from tarball

[Branko Čibej]

On 04.09.2019 14:17, Mark Phippard wrote:
> On Wed, Sep 4, 2019 at 8:11 AM swdev  > wrote:
>
> Thanks for all the replies.
> I haven't got quoting right in gmail.
>
> Nathan Hartman
>   I used git clone git://git.openssl.org/openssl.git
>  ., so I guess I am using the
> latest development version.
>   I will see if I can use a tagged version.
>
>
>
> I do not recall if you mentioned the OpenSSL version either.  Last I
> knew, Subversion still requires 1.0.x.  Maybe use the OpenSSL release
> tarball?

Not Subversion, but Serf 1.3.9 does, sort of. There's some support for
OpenSSL 1.1.x in that release, but it doesn't seem to be complete.

However, both Serf trunk and the (unreleased) 1.4.x branch do support
OpenSSL 1.1.x.

-- Brane

Re: Decompression of svndiff data failed

[Branko Čibej]

On 30.08.2019 15:14, Michael Ditum wrote:
> Hi Brane,
>
> Thanks for the reply. Interestingly Daniel's reply had given me the
> idea to try pretty much what you suggested and I gave it a go this
> morning and it seems to be working.
>
> Stopping svnsync in the right place wasn't hard as i dies as soon as
> it tried to get the binary diff but before it's made any changes.
>
> The one bit I didn't do was update the svnsync metadata. When I
> resumed the sync it just automatically carried on with the revision
> after the one I had just committed. Hopefully that won't cause any
> problems, it seems to be working ok as I'm a lot further syncing than
> I've ever managed before (crazy how many times we've had svndiff
> errors, luckily fsfsverify has fixed all of the others so far).
>
> Thanks for everyone's help!

Great that it works. :)

I'm curious though ... have you any idea what caused the decompression
errors? The message you posted came from zlib -- not Subversion's code
-- and that has been very, very stable literally for decades.

Is it possible that you just had the bad luck to have a broken version
of zlib, way back in the dawn of time? If it had been a problem with the
storage, I'm pretty sure you'd have noticed other issues, too.

-- Brane

Re: Pre-commit hook assistance

[Branko Čibej]

On 30.08.2019 15:01, William Muriithi wrote:
> Morning, 
>
> I am attempting to write a pre-commit hook that enforces a policy to
> some group and warns the rest of the team. The hook is in python and
> it just check that jira ticket exist on the commit log.
>
> The problem I am facing is I am not able to both warn and error for
> some reason. If I exit, the failure reason is displayed to the user.
>
> If I don't exit, but attempts to send a warning to the client, 
> nothing show up even in the logs.
>
> I am using sys.stderr.write and sys.stdout.write for error and warning
> respectively. Is it technically possible to do this? Would be grateful
> for your help on this.

This is clearly documented in the pre-commit hook template:

# If the hook program exits with success, the txn is committed; but
# if it exits with failure (non-zero), the txn is aborted, no commit
# takes place, and STDERR is returned to the client.



So, no, you can't send "warnings" by writing to stdout, and stderr is
only piped to the client if the hook fails.

For warnings, you'll have to use some other channel.

-- Brane

Re: Decompression of svndiff data failed

[Branko Čibej]

On 29.08.2019 20:49, Michael Ditum wrote:
> Apart from using fsfsverify I also tried recreating the diff by
> creating a Fedora 7 VM, running svnsync on it to copy the repo up to
> that point and then manually committing the file and copying the
> revision over to the copy of my original repo.

Yikes. No, that definitely won't work.

> Whilst this allows svnsync to get past that revision I then started
> having lots of problems with incorrect byte offsets in later revisions
> and once I (think I correctly) fixed started getting checksum errors.

And that's why ... binary deltas rely on previously stored data, but
unlike a text diff they have no context. You changed the source of the
delta and that corrupted everything that depends on it in later revisions.


> Does anyone have any ideas on how I can fix this revision? As I
> mentioned before, the file gets deleted a couple of revisions later so
> I don't really care about the contents of the revision but I'm
> currently stuck and can't get any further in my svnsync.

Daniel made the best suggestion, it would work like this:

  * create a new repository
  * svnsync up to the revision just before the broken one (stopping
svnsync is the tricky part here)
  * commit that one file to the _synced_ repository, and update
svnsync's metadata (in revision properties on r0) to skip the
offending revision on the next run
  * svnsync to the end.

You can do a similar trick with svnadmin dump and (incremental) load;
the benefit of this is that there is no "stopping problem," but it will
be much, much slower than svnsync. You _could_ combine both methods,
i.e., initialize your target repo with a partial dump of the source up
to your offending rX, then commit rX to the target repo, then svnsync
from there.

-- Brane

Re: Recommended method to keep an svn mirror in sync per commit?

[Branko Čibej]

On 10.08.2019 21:57, Ryan Schmidt wrote:
> And you'll want the spawned task to be a wrapper script around svnsync that 
> somehow ensures (with some kind of lock?) that only one copy of the script is 
> running at a time.

'svnadmin freeze' on the target repository would do that.

-- Brane

Re: Is support officially over for subversion 1.9?

[Branko Čibej]

On 06.08.2019 16:08, ken edward wrote:
> Hello,
>
> As I read the SVN LTS policy, it states that support ends 4 years
> after the initial release. Since Subversion 1.9 was released on Aug 5,
> 2015, does that now mean subversion 1.9 will not longer receive
> security patches (now that it is Aug 6th)?

We haven't decided yet, but it's likely that the answer will be "yes".

I'll make sure we send an announcement when we do decide.

-- Brane

Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?

[Branko Čibej]

On Sat, 20 Jul 2019, 11:51 Stefan Sperling,  wrote:

>
> But as a user I find it infuriating when software I use contains
> artificial restrictions like this.



We recently disabled plaintext password storage (by default) in the build
configuration, making it effectively unavailable to users who don't build
from source. The rationale for that decision was the same as for not
permanently trusting certs with unknown failures.


We should assume our users know
> what they are doing. Subversion

is not a web browser.
>


I will refrain from spelling out the snide remark that immediately comes to
mind. :)

What we *should* do is use any platform APIs available for cert validation,
as I already mentioned on the other thread in my response to Evgeny's
commit. One might wish that OpenSSL through Serf took care of that, but
unfortunately it does not, so it's up to us. Given the growing popularity
of Let's Encrypt's server certs with 3 months validity, the potential for
user infuriation may be growing quite quickly.

-- Brane

>

Re: Same level externals not possible

[Branko Čibej]

On 07.05.2019 15:19, Osipov, Michael wrote:
>
>
> Am 2019-05-07 um 14:57 schrieb Branko Čibej:
>> On 07.05.2019 14:25, Osipov, Michael wrote:
>>>
>>>
>>> Am 2019-05-07 um 14:20 schrieb Branko Čibej:
>>>> On 07.05.2019 13:53, Osipov, Michael wrote:
>>>>> Hi folks,
>>>>>
>>>>> consider the following layout we need to solve for our legacy build:
>>>>>
>>>>> .
>>>>> |-- forms
>>>>> |-- src
>>>>> \-- inc
>>>>>
>>>>> inc shall point to forms as external. Wenn doing "svn ps" with "forms
>>>>> inc" or "./forms inc" I receive an error.
>>>>
>>>> Just to clarify, you want this:
>>>>
>>>> $ svn propset svn:externals './forms inc' .
>>>
>>> Correct. Expanded it is:
>>>
>>> /di1234/trunk
>>> |-- forms
>>> |-- src
>>> \-- inc
>>>
>>>> that is, on the parent directory of 'forms'?
>>>>
>>>>> Of course, according to the help output [1] this is not possible. But
>>>>> why can't I have same level externals? We currently apply the ugly
>>>>> workaround by creating 'inc' and adding externals beneath that.
>>>>
>>>> The reason you can't do that is that if we allowed the syntax you're
>>>> proposing, it will conflict with the old, pre-1.5 svn:externals
>>>> format,
>>>> where the first parameter was the external name and the second was the
>>>> full URL.
>>>
>>> I'd be happy if this compat-mode could be turned off via compile time
>>> option to make the case work as expected. I don't know how much effort
>>> that is since I don't know the Subversion codebase.
>>
>> Well, I would be quite unhappy with that because then every time someone
>> reported a problem with externals, we'd have to ask how they compiled
>> their client ... and the answer would probably be "I don't know."
>>
>> One simply doesn't design features that way. :)
>
> Fair enough ;-)
>
> Any chances that this will go way with the next LTS release? 1.5 is
> really really old...

We promise backward compatibility across 1.x, so not likely.

>> If your clients are UNIX-ish machines, you can commit 'inc' as a symlink
>> to 'forms'. Or creating the link (even on Windows) could be part of a
>> script that prepares the working copy for your legacy build.
>
> The software runs on HP-UX only, so yes we have real UNIX. We have
> also considered symlinks, but wanted actually the portable --
> Subversion -- way.

Understood. If you can come up with a syntax for what you want that is
backwards-compatible and unambiguous, feel free to write up a proposal
and send it to the dev@ list. For reference, what we currently support
is documented here:

http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html

-- Brane

Re: Same level externals not possible

[Branko Čibej]

On 07.05.2019 14:25, Osipov, Michael wrote:
>
>
> Am 2019-05-07 um 14:20 schrieb Branko Čibej:
>> On 07.05.2019 13:53, Osipov, Michael wrote:
>>> Hi folks,
>>>
>>> consider the following layout we need to solve for our legacy build:
>>>
>>> .
>>> |-- forms
>>> |-- src
>>> \-- inc
>>>
>>> inc shall point to forms as external. Wenn doing "svn ps" with "forms
>>> inc" or "./forms inc" I receive an error.
>>
>> Just to clarify, you want this:
>>
>> $ svn propset svn:externals './forms inc' .
>
> Correct. Expanded it is:
>
> /di1234/trunk
> |-- forms
> |-- src
> \-- inc
>
>> that is, on the parent directory of 'forms'?
>>
>>> Of course, according to the help output [1] this is not possible. But
>>> why can't I have same level externals? We currently apply the ugly
>>> workaround by creating 'inc' and adding externals beneath that.
>>
>> The reason you can't do that is that if we allowed the syntax you're
>> proposing, it will conflict with the old, pre-1.5 svn:externals format,
>> where the first parameter was the external name and the second was the
>> full URL.
>
> I'd be happy if this compat-mode could be turned off via compile time
> option to make the case work as expected. I don't know how much effort
> that is since I don't know the Subversion codebase.

Well, I would be quite unhappy with that because then every time someone
reported a problem with externals, we'd have to ask how they compiled
their client ... and the answer would probably be "I don't know."

One simply doesn't design features that way. :)

If your clients are UNIX-ish machines, you can commit 'inc' as a symlink
to 'forms'. Or creating the link (even on Windows) could be part of a
script that prepares the working copy for your legacy build.

-- Brane

Re: Same level externals not possible

[Branko Čibej]

On 07.05.2019 13:53, Osipov, Michael wrote:
> Hi folks,
>
> consider the following layout we need to solve for our legacy build:
>
> .
> |-- forms
> |-- src
> \-- inc
>
> inc shall point to forms as external. Wenn doing "svn ps" with "forms
> inc" or "./forms inc" I receive an error.

Just to clarify, you want this:

$ svn propset svn:externals './forms inc' .

that is, on the parent directory of 'forms'?

> Of course, according to the help output [1] this is not possible. But
> why can't I have same level externals? We currently apply the ugly
> workaround by creating 'inc' and adding externals beneath that.

The reason you can't do that is that if we allowed the syntax you're
proposing, it will conflict with the old, pre-1.5 svn:externals format,
where the first parameter was the external name and the second was the
full URL.

-- Brane

Re: Fwd: Error during Migrating from Perforce to SVN

[Branko Čibej]

On 06.05.2019 21:59, Ibrahim Ibbu wrote:

> [root@sce-github svn-repos]# pwd
>
> /SVN/svn-repos
>
> [root@sce-github svn-repos]# ls -lrt
>
> total 24
>
> drwxr-xr-x 2 root root 4096 May  5 02:41 locks
>
> -rw-r--r-- 1 root root  229 May  5 02:41 README.txt
>
> drwxr-xr-x 2 root root 4096 May  5 02:41 conf
>
> -r--r--r-- 1 root root    2 May  5 02:41 format
>
> drwxr-xr-x 2 root root 4096 May  5 02:41 hooks
>
> drwxr-sr-x 6 root root 4096 May  5 02:43 db
>
>  
>
> I could not see any source code here, Please verify it once as I am
> not sure on SVN stuff.
>

Of course you couldn't, this is the repository. You have to check out a
working copy somewhere to get the repository contents.

-- Brane

Re: Subversion 1.9.10/1.10.4 choke on non-ASCII resources on HP-UX

[Branko Čibej]

On 07.05.2019 08:45, Osipov, Michael wrote:
>
>
> Am 2019-05-03 um 11:53 schrieb Branko Čibej:
>> On 02.05.2019 11:40, Osipov, Michael wrote:
>>> Hi Branko,
>>>
>>> Am 2019-05-01 um 02:17 schrieb Branko Čibej:
>>>> On 30.04.2019 20:18, Osipov, Michael wrote:
>>>>
>>>>> The terminal and locale are fine though:
>>>>>> $ locale
>>>>>> LANG=de_DE.utf8
>>>>>> LC_CTYPE="de_DE.utf8"
>>>>>> LC_COLLATE="de_DE.utf8"
>>>>>> LC_MONETARY="de_DE.utf8"
>>>>>> LC_NUMERIC="de_DE.utf8"
>>>>>> LC_TIME="de_DE.utf8"
>>>>>> LC_MESSAGES="de_DE.utf8"
>>>>>> LC_ALL=
>>>>
>>>> LC_ALL should probably not be empty. Could be that on HP-UX, the empty
>>>> value causes Subversion to use the default C (or POSIX) locale. Try
>>>> setting
>>>>
>>>>   LC_ALL="de_DE.utf8"; export LC_ALL
>>>>
>>>> Subversion tries setlocale(LC_ALL, "") first and only if that
>>>> fails, it
>>>> tries setlocale(LC_CTYPE, ""). Evidently the first call succeeds,
>>>> which
>>>> is strange but not strictly wrong. I think.
>>>
>>> Doesn't really work out.
>>>
>>> Here is the old server:
>>>> $ hostname
>>>> blnn724x
>>>> $ svn --version -q
>>>> 1.9.4
>>>> $ locale
>>>> LANG=de_DE.utf8
>>>> LC_CTYPE="de_DE.utf8"
>>>> LC_COLLATE="de_DE.utf8"
>>>> LC_MONETARY="de_DE.utf8"
>>>> LC_NUMERIC="de_DE.utf8"
>>>> LC_TIME="de_DE.utf8"
>>>> LC_MESSAGES="de_DE.utf8"
>>>> LC_ALL=
>>>> $ svn ls https://deblndw011x.ad001.siemens.net/repos/svn/Playground
>>>> README.txt
>>>> a/
>>>> c.txt
>>>> hallo.c
>>>> keyword-test.txt
>>>> test1234/
>>>> testprogramm.c
>>>> привет.txt
>>>
>>> the export didn't change anything, it still fails:
>>>> $ hostname
>>>> deblndw024v
>>>> $ svn --version -q
>>>> 1.9.4
>>>> $ locale
>>>> LANG=de_DE.utf8
>>>> LC_CTYPE="de_DE.utf8"
>>>> LC_COLLATE="de_DE.utf8"
>>>> LC_MONETARY="de_DE.utf8"
>>>> LC_NUMERIC="de_DE.utf8"
>>>> LC_TIME="de_DE.utf8"
>>>> LC_MESSAGES="de_DE.utf8"
>>>> LC_ALL=de_DE.utf8
>>>> $ svn ls https://deblndw011x.ad001.siemens.net/repos/svn/Playground
>>>> README.txt
>>>> a/
>>>> c.txt
>>>> hallo.c
>>>> keyword-test.txt
>>>> test1234/
>>>> testprogramm.c
>>>> {U+043F}{U+0440}{U+0438}{U+0432}{U+0435}{U+0442}.txt
>>>
>>>
>>> Here is a basic program:
>>>> 0# cat locale.c
>>>> #include 
>>>> #include 
>>>> #include 
>>>>
>>>> int main(void) {
>>>>  char *l = NULL;
>>>>  l = setlocale(LC_ALL, "");
>>>>  printf("%s\n", l);
>>>>  char *nl = NULL;
>>>>  nl = nl_langinfo(CODESET);
>>>>  printf("%s\n", nl);
>>>>
>>>>  return 0;
>>>> }
>>>> # aCC -o locale locale.c
>>> # ./locale
>>> C.utf8 C.utf8 C.utf8 C.utf8 C.utf8 C.utf8
>>> utf8
>>>> # LC_ALL=de_DE.utf8 ./locale
>>>> de_DE.utf8 de_DE.utf8 de_DE.utf8 de_DE.utf8 de_DE.utf8 de_DE.utf8
>>>> utf8
>>>
>>> Looks good to me, doesn't it?
>>
>> It does ...
>>
>>> Anything else I can try? Bad libiconv or libapr?
>>
>> Either libiconv or apr_xlate don't handle UTF-8 on HP-UX? It would be
>> strange but not impossible.
>>
>> Given the earlier warning from msgfmt that
>> "Charset "UTF-8" is not supported" I suspect libiconv, since gettext
>> doesn't use APR.
>>
>> Is it possible that you're using a mis-configured GNU libiconv instead
>> of the stock system version? Since locale() does support UTF-8, I'd
>> expect the stock libiconv to support it, too. However, IIRC GNU tools
>> don't like the POSIX libiconv API very much.
>>
>> Subversion doesn't care; for string conversion, whatever stock libiconv
>> does (through apr_xlate) should be enough; it doesn't depend on NLS
>> being enabled.
>
> Given your pointers, that was it. For some reason I have screwed up
> the stack around the GNU stuff. Recompiling everyting again to PREFIX
> made it work. Subversion perfectly works now on HP-UX.

Great!

-- Brane

Re: Subversion 1.9.10/1.10.4 choke on non-ASCII resources on HP-UX

[Branko Čibej]

On 02.05.2019 11:40, Osipov, Michael wrote:
> Hi Branko,
>
> Am 2019-05-01 um 02:17 schrieb Branko Čibej:
>> On 30.04.2019 20:18, Osipov, Michael wrote:
>>
>>> The terminal and locale are fine though:
>>>> $ locale
>>>> LANG=de_DE.utf8
>>>> LC_CTYPE="de_DE.utf8"
>>>> LC_COLLATE="de_DE.utf8"
>>>> LC_MONETARY="de_DE.utf8"
>>>> LC_NUMERIC="de_DE.utf8"
>>>> LC_TIME="de_DE.utf8"
>>>> LC_MESSAGES="de_DE.utf8"
>>>> LC_ALL=
>>
>> LC_ALL should probably not be empty. Could be that on HP-UX, the empty
>> value causes Subversion to use the default C (or POSIX) locale. Try
>> setting
>>
>>  LC_ALL="de_DE.utf8"; export LC_ALL
>>
>> Subversion tries setlocale(LC_ALL, "") first and only if that fails, it
>> tries setlocale(LC_CTYPE, ""). Evidently the first call succeeds, which
>> is strange but not strictly wrong. I think.
>
> Doesn't really work out.
>
> Here is the old server:
>> $ hostname
>> blnn724x
>> $ svn --version -q
>> 1.9.4
>> $ locale
>> LANG=de_DE.utf8
>> LC_CTYPE="de_DE.utf8"
>> LC_COLLATE="de_DE.utf8"
>> LC_MONETARY="de_DE.utf8"
>> LC_NUMERIC="de_DE.utf8"
>> LC_TIME="de_DE.utf8"
>> LC_MESSAGES="de_DE.utf8"
>> LC_ALL=
>> $ svn ls https://deblndw011x.ad001.siemens.net/repos/svn/Playground
>> README.txt
>> a/
>> c.txt
>> hallo.c
>> keyword-test.txt
>> test1234/
>> testprogramm.c
>> привет.txt
>
> the export didn't change anything, it still fails:
>> $ hostname
>> deblndw024v
>> $ svn --version -q
>> 1.9.4
>> $ locale
>> LANG=de_DE.utf8
>> LC_CTYPE="de_DE.utf8"
>> LC_COLLATE="de_DE.utf8"
>> LC_MONETARY="de_DE.utf8"
>> LC_NUMERIC="de_DE.utf8"
>> LC_TIME="de_DE.utf8"
>> LC_MESSAGES="de_DE.utf8"
>> LC_ALL=de_DE.utf8
>> $ svn ls https://deblndw011x.ad001.siemens.net/repos/svn/Playground
>> README.txt
>> a/
>> c.txt
>> hallo.c
>> keyword-test.txt
>> test1234/
>> testprogramm.c
>> {U+043F}{U+0440}{U+0438}{U+0432}{U+0435}{U+0442}.txt
>
>
> Here is a basic program:
>> 0# cat locale.c
>> #include 
>> #include 
>> #include 
>>
>> int main(void) {
>>     char *l = NULL;
>>     l = setlocale(LC_ALL, "");
>>     printf("%s\n", l);
>>     char *nl = NULL;
>>     nl = nl_langinfo(CODESET);
>>     printf("%s\n", nl);
>>
>>     return 0;
>> }
>> # aCC -o locale locale.c
> # ./locale
> C.utf8 C.utf8 C.utf8 C.utf8 C.utf8 C.utf8
> utf8
>> # LC_ALL=de_DE.utf8 ./locale
>> de_DE.utf8 de_DE.utf8 de_DE.utf8 de_DE.utf8 de_DE.utf8 de_DE.utf8
>> utf8
>
> Looks good to me, doesn't it?

It does ...

> Anything else I can try? Bad libiconv or libapr?

Either libiconv or apr_xlate don't handle UTF-8 on HP-UX? It would be
strange but not impossible.

Given the earlier warning from msgfmt that
"Charset "UTF-8" is not supported" I suspect libiconv, since gettext
doesn't use APR.

Is it possible that you're using a mis-configured GNU libiconv instead
of the stock system version? Since locale() does support UTF-8, I'd
expect the stock libiconv to support it, too. However, IIRC GNU tools
don't like the POSIX libiconv API very much.

Subversion doesn't care; for string conversion, whatever stock libiconv
does (through apr_xlate) should be enough; it doesn't depend on NLS
being enabled.

-- Brane

Re: Subversion 1.9.10/1.10.4 choke on non-ASCII resources on HP-UX

[Branko Čibej]

On 30.04.2019 20:18, Osipov, Michael wrote:
> Hi folks,
>
> I am facing an issue a previously not had with 1.9.4 on another HP-UX
> machine. Installed a new one and compiled 1.10.4, does not work and
> downgraded to 1.9.10 same issue.
>
> Using HP-UX 11.31 with "aCC: HP C/aC++ B3910B A.06.29 [Oct 18 2016]".
>
> configure:
>> export PREFIX=/opt/ports
>> export LIBDIR=$PREFIX/lib/hpux32
>> export CC=/opt/aCC/bin/aCC
>> export CONFIGURE="./configure --prefix=$PREFIX --libdir=$LIBDIR"
>> export CPPFLAGS="-I$PREFIX/include"
>> export LDFLAGS="-L$LIBDIR"
>> $CONFIGURE --with-apr=$PREFIX --with-apr-util=$PREFIX --without-apxs
>> --without-berkeley-db --with-serf=$PREFIX --disable-nls
>
> Everything compiles fine besides that the portable object files cannot
> properly converted to machine objects:
>> bash-5.0# /opt/ports/bin/msgfmt -c -o subversion/po/zh_TW.mo
>> subversion/po/zh_TW.po
>> subversion/po/zh_TW.po: warning: Charset "UTF-8" is not supported.
>> msgfmt relies on iconv(),
>>  and iconv() does not support "UTF-8".
>>  Installing GNU libiconv and then
>> reinstalling GNU gettext
>>  would fix this problem.
>>  Continuing anyway.
>
> Therefore, I have disabled nls for now. (installed GNU libiconv,
> didn't make a change)

You'd most likely have to recompile (or at least relink) gettext to use
the GNU libiconv.

> All other deps have been compiled on the same machine with the most
> recent version. I have also run the utf8proc tests (swapped getline()
> for fgets()):

utf8proc doesn't convert between encodings, it just handles the Unicode
transformation forms. It's completely self-contained and doesn't use
libiconv.

>> bash-5.0# gmake check
>> gmake -C bench
>> gmake[1]: Entering directory
>> '/tmp/system-compile/apache/utf8proc/utf8proc-2.3.0-patched/bench'
>> gmake[1]: Nothing to be done for 'all'.
>> gmake[1]: Leaving directory
>> '/tmp/system-compile/apache/utf8proc/utf8proc-2.3.0-patched/bench'
>> test/normtest data/NormalizationTest.txt
>> line 42: Part0 # Specific cases
>> line 70: Part1 # Character by character test
>> checking line 1000...
>> checking line 2000...
>> checking line 3000...
>> checking line 4000...
>> checking line 5000...
>> checking line 6000...
>> checking line 7000...
>> checking line 8000...
>> checking line 9000...
>> checking line 1...
>> checking line 11000...
>> checking line 12000...
>> checking line 13000...
>> checking line 14000...
>> checking line 15000...
>> checking line 16000...
>> line 16969: Part2 # Canonical Order Test
>> checking line 17000...
>> checking line 18000...
>> line 18696: Part3 # PRI #29 Test
>> Passed tests after 18874 lines!
>> test/graphemetest data/GraphemeBreakTest.txt
>> checking line 100...
>> checking line 200...
>> checking line 300...
>> checking line 400...
>> checking line 500...
>> checking line 600...
>> Passed tests after 630 lines!
>> test/charwidth
>> Mismatches with system wcwidth (not necessarily errors):
>>    ... (positive widths for 135297 chars unknown to wcwidth) ...
>> Character-width tests SUCCEEDED.
>> test/misc
>> NFC "ṛ̇" -> "ṛ̇" vs. "ṛ̇"
>> NFD "ṛ̇" -> "ṛ̇" vs. "ṛ̇"
>> NFKC_Casefold "X⁥È­ᴬ" -> "xèa" vs. "xèa"
>> NFKC_Casefold "X⁥È­ᴬ" -> "x⁥èa" vs. "x⁥èa"
>> Unicode version: Makefile has 12.0.0, has API 12.0.0
>> Misc tests SUCCEEDED.
>> test/valid
>> Validity tests SUCCEEDED.
>> test/iterate
>> utf8proc_iterate tests SUCCEEDED, (673) tests passed.
>> test/case
>> More up-to-date than OS unicode tables for 2746 tests.
>> utf8proc case conversion tests SUCCEEDED.
>> test/custom
>> mapped "AaSbａ" -> "abssba"
>> map_custom tests SUCCEEDED.
>
> Here is the failure:
>> $ svn co https://deblndw011x.ad001.siemens.net/repos/svn/Playground
>> A    Playground/test1234
>> A    Playground/a
>> A    Playground/{U+043F}{U+0440}{U+0438}{U+0432}{U+0435}{U+0442}.txt
>> A    Playground/a/b.txt
>> svn: E155009: Failed to run the WC DB work queue associated with
>> '/net/home/osipovmi/Playground/a', work item 1 (file-install 16
>> {U+043F}{U+0440}{U+0438}{U+0432}{U+0435}{U+0442}.txt 1 0 1 1)
>> svn: E22: Safe data '/net/home/osipovmi/Playground/' was followed
>> by non-ASCII byte 208: unable to convert to/from UTF-8
>
> but SQLite works:
>> $ sqlite3 Playground/.svn/wc.db
>> SQLite version 3.28.0 2019-04-16 19:49:53
>> Enter ".help" for usage hints.
>> sqlite> select * from WORK_QUEUE;
>> 1|(file-install 16 привет.txt 1 0 1 1)
>> 2|(file-install a/b.txt 1 0 1 1)
>> sqlite> .quit
>
> The terminal and locale are fine though:
>> $ locale
>> LANG=de_DE.utf8
>> LC_CTYPE="de_DE.utf8"
>> LC_COLLATE="de_DE.utf8"
>> LC_MONETARY="de_DE.utf8"
>> LC_NUMERIC="de_DE.utf8"
>> LC_TIME="de_DE.utf8"
>> LC_MESSAGES="de_DE.utf8"
>> LC_ALL=

LC_ALL should probably not be empty. Could be that on HP-UX, the empty
value causes Subversion to use the default C (or POSIX) locale. Try setting

    LC_ALL="de_DE.utf8"; export 

Re: configure: error: failed to recognize APR_INT64_T_FMT on this platform

[Branko Čibej]

On 24.04.2019 19:43, ken edward wrote:
> Does anyone have an idea how to fixthis error:
>
>
> ./configure --with-sqlite=/u01/tomcat/scm/sqlite-autoconf
> --with-apxs=/u01/tomcat/scm/apache2.4.39kerb/bin/apxs
> --prefix=/u01/tomcat/scm/subversion --enable-javah
> l --with-jdk=/u01/weblogic/java/jdk1.8.0_201
> --with-zlib=/u01/tomcat/scm/zlib-1.2.11
> --with-apr-util=/u01/tomcat/scm/apr-util-1.6.1/bin/apu-1-config
> --with-apr=/u01/tomcat/scm/apr-1.7.0/bin/apr-1-con
> fig --with-lz4=internal --with-utf8proc=internal  CPPFLAGS=-DHAVE
>
> configure: Configuring python swig binding
> checking for Python includes... -I/usr/include/python2.7
> checking for compiling Python extensions... gcc -pthread -fPIC
> checking for linking Python extensions... gcc -pthread -shared -Wl,-z,relro
> checking for linking Python libraries... -Wl,-z,relro
> checking for apr_int64_t Python/C API format string...
> configure: error: failed to recognize APR_INT64_T_FMT on this platform

Don't use APR 1.7.0. It changed the way it sets APR_INT64_T_FMT in a way
that interferes with Subversion's configuration for the Python bindings.
This is fixed in our trunk, but not in 1.12.

-- Brane

Re: Possible issue: Out of date output from svn help remove

[Branko Čibej]

On 18.04.2019 18:17, Richard Cavell wrote:
> Hello.  I believe that the output of svn help remove on my machine is
> out of date.  It says that each item is scheduled for deletion.  But
> this has been changed over the years as subversion has evolved.  Now,
> the item is deleted right away.

That is simply not true. Subversion has _not_ changed in the way you
think it has.

"Scheduled for deletion" means that contents are removed from the
working copy, but not from the repository until the deletion is committed.

-- Bane

Re: svn and svnserve hanging

[Branko Čibej]

On 11.04.2019 10:17, Vincent Lefevre wrote:
> On 2019-04-11 04:22:29 +0200, Branko Čibej wrote:
>> I think that svnserve would only use that function to find the current
>> user's home directory, to locate the config files. And that seems wrong
>> because svnserve has no business looking at the client's config area ...
> I think that it would be better to honor the value of $HOME
> for that purpose.

I disagree. For a daemon, $HOME shouldn't be set in the first place. But
in any case, we don't really care what APR or glibc do under the covers;
that's our platform abstraction.


>
>> Still, I don't see from the code how it could hang. The homedir is
>> either found or not, and if it's not, it's ignored.
> So it would mean that it is at the glibc level that it blocks.

I don't know, I'm only guessing, since I have no way to reproduce the
problem. Getting a call stack from the blocked svnserve process would
help diagnose the reason.


-- Brane

Re: svn and svnserve hanging

[Branko Čibej]

On 10.04.2019 11:21, Vincent Lefevre wrote:
> On 2019-04-10 04:06:08 +0200, Branko Čibej wrote:
>> On 10.04.2019 03:29, Vincent Lefevre wrote:
>>> On 2019-04-09 20:09:26 +0200, Branko Čibej wrote:
>>>> The only problem with that idea is that svnseve doesn't use unscd at
>>>> all, or any kind of LDAP access.
>>> Are you so sure about that? A "strace svnserve -t"[*] shows it
>>> reads the /etc/nsswitch.conf file. With "ltrace", I can see that
>>> svn_user_get_name is called, and I'm wondering whether this is
>>> the cause.
>>
>> That just calls apr_uid_name_get(), so the call chain is
>> svnserve->APR->glibc. The latter's implementation would look at
>> nsswitch.conf. That suggests that is is related to user configuration
>> somehow. But I don't know much about that topic.
>>
>> The name caching daemon is something glibc would use directly, most likely.
> Yes, what happens to get the user name depends on the nsswitch.conf.
> The user name is not stored on this machine, so I assume that the
> glibc function yields a connection to this daemon. Then I don't know
> whether the hang occurs there or an error is reported but somewhere
> the error makes the process hang.

I think that svnserve would only use that function to find the current
user's home directory, to locate the config files. And that seems wrong
because svnserve has no business looking at the client's config area ...

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

-- Brane

Re: svn and svnserve hanging

[Branko Čibej]

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


That just calls apr_uid_name_get(), so the call chain is
svnserve->APR->glibc. The latter's implementation would look at
nsswitch.conf. That suggests that is is related to user configuration
somehow. But I don't know much about that topic.

The name caching daemon is something glibc would use directly, most likely.

-- Brane

Re: svn and svnserve hanging

[Branko Čibej]

On 09.04.2019 17:22, Vincent Lefevre wrote:
> I got interesting information from the sysadmin of the server:
> what the logs show is that a cron job reloads the unscd daemon
> every 10 minutes, a multiple of 10.
>
> So, the hanging svnserve was started at about the same time as the
> reload of the unscd daemon. This was also the case when I had the
> problem in the past. And when I looked at the other "svnserve -t"
> processes that were started a long time ago on the machine, except
> for 2 users (which seemed to be particular as having many svnserve
> processes), the start times were also multiples of 10 minutes.
>
> Thus it seems to be a bug in svnserve (or a library it uses to connect
> to this daemon), which doesn't seem to handle failures correctly.

The only problem with that idea is that svnseve doesn't use unscd at
all, or any kind of LDAP access. You'll have to start looking at how
your authentication is set up, since you're doing this through SSH,
you're bypassing svnserve's authentication entirely, right?

-- Brane

Re: svn and svnserve hanging

[Branko Čibej]

On 08.04.2019 18:38, Stefan Sperling wrote:
>> Well, I forgot, there's at least an issue with svnserve. I got that
>> in the past, and could reproduce it: once I kill the svn client
>> with Ctrl-C and kill the SSH master too, the sshd terminates, but
>> svnserve is still running, and now has 1 as its PPID:
>>
>> UIDPID  PPID  C STIME TTY  TIME CMD
>> vlefevre 48724 1  0 12:40 ?00:00:00 svnserve -t
> Hmm... that looks like the svnserve process was in zombie state
> and is not being terminated. It is the init system's job to call
> waitpid() for such processes.

Yes, but only if the process notices that it's a zombie. Could be we
don't notice the broken pipe when the tunnel closes?

-- Brane

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

[Branko Čibej]

On 07.03.2019 17:36, Vincent Lefevre wrote:
> On 2019-03-07 05:26:48 -0600, Ryan Schmidt wrote:
>> I had this problem once when I ran a recursive sed command over my
>> working copy, not considering that it would modify the contents of
>> the .svn directory too.
> Would it be a good idea to protect the .svn directory by default?
> I mean that Subversion would unprotect it before an operation and
> protect it again just after.

How would you do that, realistically? I can't think of any way other
than changing permissions on all files within that directory.

-- Brane

Re: Feature Request: svn update --accept failure

[Branko Čibej]

On 07.03.2019 04:24, Branko Čibej wrote:
> On 07.03.2019 04:08, Marc Pawlowsky wrote:
>> Sometimes failure is an option.
>>
>> I am working inside a complex scripting environment.  It would be
>> better if when svn update detects a conflict that the update did not
>> occur and that the command would fail.  The versioned versions of the
>> file could still be crated and maybe another one that would have the
>> standard conflict markers, but the original file should be unchanged
>> versus copied into the .mine.
>
> I understand what you want, but this feature would require rather
> fundamental changes to how update works. It's not atomic.
>
> However, if you can live with just the individual conflicted files
> remaining unchanged, then I believe the option is --accept=mine-full.
> But I don't think that would be very useful.


The work on shelving and  checkpointing SHOULD eventually add this
feature (just not as a switch for 'svn update').

-- Brane

Re: Feature Request: svn update --accept failure

[Branko Čibej]

On 07.03.2019 04:08, Marc Pawlowsky wrote:
> Sometimes failure is an option.
>
> I am working inside a complex scripting environment.  It would be
> better if when svn update detects a conflict that the update did not
> occur and that the command would fail.  The versioned versions of the
> file could still be crated and maybe another one that would have the
> standard conflict markers, but the original file should be unchanged
> versus copied into the .mine.


I understand what you want, but this feature would require rather
fundamental changes to how update works. It's not atomic.

However, if you can live with just the individual conflicted files
remaining unchanged, then I believe the option is --accept=mine-full.
But I don't think that would be very useful.

-- Brane

Re: How to open specified inside .svn

[Branko Čibej]

On 02.03.2019 15:18, wuzhouhui wrote:
>> On Mar 2, 2019, at 10:09 PM, wuzhouhui  wrote:
>>
>>> On Mar 2, 2019, at 9:41 PM, Branko Čibej  wrote:
>>>
>>> On 02.03.2019 05:29, wuzhouhui wrote:
>>>>> On Mar 2, 2019, at 8:21 AM, Daniel Shahaf  wrote:
>>>>>
>>>>> wuzhouhui wrote on Fri, Mar 01, 2019 at 17:46:55 +0800:
>>>>>>> -Original Messages-
>>>>>>> From: "Branko Čibej" 
>>>>>>> Sent Time: 2019-03-01 17:16:40 (Friday)
>>>>>>> To: users@subversion.apache.org
>>>>>>> Cc: 
>>>>>>> Subject: Re: How to open specified inside .svn
>>>>>>>
>>>>>>> There are no such generic functions. The svn_wc API isn't really meant
>>>>>>> to be public, so you'll have to write your own access functions. Look at
>>>>>>> how the svn_client implementations do it, or for example
>>>>>>> svn_wc__get_pristine_contents_by_checksum in svn_wc_private.h.
>>>>>> Actually, I'm hacking Subversion client command line tool, so it
>>>>>> doesn't matter whether the API is public or private.
>>>>> The difference isn't just visibility.  We don't promise compatibility
>>>>> for private APIs, not even across patch releases in the same minor line
>>>>> (1.A.x and 1.A.y).
>>>> Thanks for your reminding. I have implement client side pre-commit hook.
>>>> The implementation maybe ugly, but it works at least.
>>>>
>>>> In case of someone have interests, you can find my customized Subversion
>>>> in https://github.com/wuzhouhui/subversion. Please forgive me about using
>>>> Git to version control Subversion :-)
>>>
>>> Using git is not a problem. Calling it Subversion _is_ a problem. Please
>>> rename it to something else.
> Ok, I understand your point. The "Subversion" is registered name of Apache, so
> I couldn't use this name casually.
>
> Thanks for your reminding.


Actually the possible confusion worries me more than the registered
trademark. Thanks for renaming it!

-- Brane


>
>> Calling it Subversion may confusing people (is it your concern?), rename it 
>> to
>> WuSVN. I hope this new name won't introduce any trouble.
>>
>> Thanks.
>>
>>> -- Brane

Re: How to open specified inside .svn

[Branko Čibej]

On 02.03.2019 05:29, wuzhouhui wrote:
>> On Mar 2, 2019, at 8:21 AM, Daniel Shahaf  wrote:
>>
>> wuzhouhui wrote on Fri, Mar 01, 2019 at 17:46:55 +0800:
>>>> -Original Messages-
>>>> From: "Branko Čibej" 
>>>> Sent Time: 2019-03-01 17:16:40 (Friday)
>>>> To: users@subversion.apache.org
>>>> Cc: 
>>>> Subject: Re: How to open specified inside .svn
>>>>
>>>> There are no such generic functions. The svn_wc API isn't really meant
>>>> to be public, so you'll have to write your own access functions. Look at
>>>> how the svn_client implementations do it, or for example
>>>> svn_wc__get_pristine_contents_by_checksum in svn_wc_private.h.
>>> Actually, I'm hacking Subversion client command line tool, so it
>>> doesn't matter whether the API is public or private.
>> The difference isn't just visibility.  We don't promise compatibility
>> for private APIs, not even across patch releases in the same minor line
>> (1.A.x and 1.A.y).
> Thanks for your reminding. I have implement client side pre-commit hook.
> The implementation maybe ugly, but it works at least.
>
> In case of someone have interests, you can find my customized Subversion
> in https://github.com/wuzhouhui/subversion. Please forgive me about using
> Git to version control Subversion :-)


Using git is not a problem. Calling it Subversion _is_ a problem. Please
rename it to something else.

-- Brane

Re: Replacing directory by circular symlink produces malformed XML

[Branko Čibej]

On 01.03.2019 11:53, Stefan Sperling wrote:
> On Thu, Feb 28, 2019 at 10:44:25PM +0100, Denis Excoffier wrote:
>> Hello,
>>
>> The situation of the replacement of a directory by a circular symlink
>> generates an XML fragment which is invalid, hence triggers a failure
>> within the calling system. See hereafter the recipe.
>>
>> Starting from a clean folder, do the following:
>>
>> % svn mkdir 1
>> A 1
>> % rmdir 1
>> % ln -s 1 1
>> % touch 2
>> % svn status --xml
>> 
>> 
>> >path=".">
>> >path="1">
>> >item="obstructed"
>>revision="-1"
>>props="none">
>> 
>> 
>> svn: E62: Can't open directory '/Users/dexco/svntest/svn/1': Too many 
>> levels of symbolic links
>> %
>>
>> There is a missing end tag for  and .
>> Another issue is missing output: path '2' is not listed.
>>
>> The correction of these issues will be much appreciated (i use 1.11.1).
>>
>> Regards,
>>
>> Denis Excoffier.
> Hi Denis,
>
> This problem is not specific to symbolic links.
> There are quite a few cases where --xml produces invalid XML
> when it runs into some kind of error. Perhaps the command
> line client should be fixed to close open XML tags when an
> error occurs, though this also risks people or scripts not
> noticing such errors.
>
> I suppose that, ideally, our XML output would embed errors
> inside the XML stream in a well-defined manner, as well as
> printing errors on stderr.
>
> So fixing this would require some non-trivial amount of effort.
> Would you have time and skills to work on this issue?

My advice is to leave well enough alone. Any callers of our tools
_should_ check the exit code before assuming that the output is valid.
Just streaming the output through a SAX parser isn't the best strategy.

-- Brane

Re: Replacing directory by circular symlink produces malformed XML

[Branko Čibej]

On 28.02.2019 22:44, Denis Excoffier wrote:
> Hello,
>
> The situation of the replacement of a directory by a circular symlink
> generates an XML fragment which is invalid, hence triggers a failure
> within the calling system. See hereafter the recipe.
>
> Starting from a clean folder, do the following:
>
> % svn mkdir 1
> A 1
> % rmdir 1
> % ln -s 1 1
> % touch 2
> % svn status --xml
> 
> 
> path=".">
> path="1">
> item="obstructed"
>revision="-1"
>props="none">
> 
> 
> svn: E62: Can't open directory '/Users/dexco/svntest/svn/1': Too many 
> levels of symbolic links
> %
>
> There is a missing end tag for  and .
> Another issue is missing output: path '2' is not listed.
>
> The correction of these issues will be much appreciated (i use 1.11.1).


You can't expect valid output from a command that fails. I'd have
thought that was obvious?

-- Brane

Re: How to open specified inside .svn

[Branko Čibej]

On 01.03.2019 04:58, wuzhouhui wrote:
>> -Original Messages-
>> From: "Ralph Seichter" 
>> Sent Time: 2019-03-01 11:46:52 (Friday)
>> To: users@subversion.apache.org
>> Cc: 
>> Subject: Re: How to open specified inside .svn
>>
>> * wuzhouhui:
>>
>>> Could someone remind me that which function can be used to open
>>> .svn/Adir/Afile in client?
>> I'm not sure I understand what you are trying to achieve? The .svn
>> directories (and contents) should not be accessed directly. That's what
>> the SVN client is for.
> I want svn to support working copy hooks (just for my own use), so I want
> svn to execute .svn/hooks/pre-commit if possible. I want to know which
> functions can be used to open and execute .svn/hooks/pre-commit.


There are no such generic functions. The svn_wc API isn't really meant
to be public, so you'll have to write your own access functions. Look at
how the svn_client implementations do it, or for example
svn_wc__get_pristine_contents_by_checksum in svn_wc_private.h.

-- Brane

Re: svn cleanup options

[Branko Čibej]

On 15.02.2019 10:23, Cooke, Mark wrote:
>> -Original Message-
>> From: Branko Čibej [mailto:br...@apache.org]
>> Sent: Friday, February 15, 2019 7:43 AM
>>
>> On 15.02.2019 08:02, Cooke, Mark wrote:
>>>> -----Original Message-
>>>> From: Branko Čibej [mailto:br...@apache.org]
>>>> Sent: Thursday, February 14, 2019 3:17 PM
>>>>
>>>> On 14.02.2019 15:33, Stefan Sperling wrote:
>>>>> On Thu, Feb 14, 2019 at 03:29:20PM +0100, Stefan Sperling wrote:
>>>>>> On Thu, Feb 14, 2019 at 01:55:10PM +, Cooke, Mark wrote:
>>>>>>> Is there any way to say "ignore errors" or "ignore read-only" or even 
>>>>>>> "remove read-only"?
>>>>>>>
>>>>>> Well, it should already work without errors.
>>>>>> I am not sure why it does not work for you :-/
>>>>> Oh, if I remember correctly, Windows has this odd quirk where it is
>>>>> unable to delete files which are being held open by an application.
>>>>>
>>>>> Is this is happening in your case? If so, you will need to close these
>>>>> files first. This is not Subversion-specific; every program on Windows
>>>>> is affected by this issue.
>>> Sorry Stefan, I did not see your reply.  I have been bitten by that before 
>>> and I am fairly confident these files
>> are not open.
>>>> That's true but 'open by an application' and 'has read-only flag set'
>>>> are two different things. Still, Subversion's 'make file read/write'
>>>> will clear the Windows read-only flag specifically for this reason.
>>>> Perhaps the read-only files are in some unversioned directory? We might
>>>> have missed this case.
>>>>
>>>> -- Brane
>>> Thanks Brane, you are right, the read-only items are in a sub-folder that 
>>> is copied in as part of the setup (and
>> then set as read-only).  Some of the run time files are stored outside the 
>> source tree and then copied in to the
>> required locations before building the setup executables.
>>> As it happens I am only really bothered about a specific sub-folder, so I 
>>> have updated the script to clear the
>> read-only flag before running the svn commands.
>>> The issue you have identified is still there but is it worth fixing?
>>
>> Yes, it's worth fixing, because it's a bug. :) If we have the
>> --remove-unversioned option and it happens not to work because we fail
>> to clear the read-only bit on files within unversioned directories,
>> well, we should fix that.
>>
>> Can you file an issue in https://issues.apache.org/jira/projects/SVN please?
>>
>> -- Brane
> Thanks Brane: https://issues.apache.org/jira/browse/SVN-4806


This is now fixed on trunk for 1.12.0, and proposed for the next 1.9.x,
1.10.x and 1.11.x releases.

-- Brane

Re: svn cleanup options

[Branko Čibej]

On 15.02.2019 08:02, Cooke, Mark wrote:
>> -Original Message-
>> From: Branko Čibej [mailto:br...@apache.org]
>> Sent: Thursday, February 14, 2019 3:17 PM
>>
>> On 14.02.2019 15:33, Stefan Sperling wrote:
>>> On Thu, Feb 14, 2019 at 03:29:20PM +0100, Stefan Sperling wrote:
>>>> On Thu, Feb 14, 2019 at 01:55:10PM +, Cooke, Mark wrote:
>>>>> Is there any way to say "ignore errors" or "ignore read-only" or even 
>>>>> "remove read-only"?
>>>>>
>>>> Well, it should already work without errors.
>>>> I am not sure why it does not work for you :-/
>>> Oh, if I remember correctly, Windows has this odd quirk where it is
>>> unable to delete files which are being held open by an application.
>>>
>>> Is this is happening in your case? If so, you will need to close these
>>> files first. This is not Subversion-specific; every program on Windows
>>> is affected by this issue.
> Sorry Stefan, I did not see your reply.  I have been bitten by that before 
> and I am fairly confident these files are not open.
>
>> That's true but 'open by an application' and 'has read-only flag set'
>> are two different things. Still, Subversion's 'make file read/write'
>> will clear the Windows read-only flag specifically for this reason.
>> Perhaps the read-only files are in some unversioned directory? We might
>> have missed this case.
>>
>> -- Brane
> Thanks Brane, you are right, the read-only items are in a sub-folder that is 
> copied in as part of the setup (and then set as read-only).  Some of the run 
> time files are stored outside the source tree and then copied in to the 
> required locations before building the setup executables.
>
> As it happens I am only really bothered about a specific sub-folder, so I 
> have updated the script to clear the read-only flag before running the svn 
> commands.
>
> The issue you have identified is still there but is it worth fixing?


Yes, it's worth fixing, because it's a bug. :) If we have the
--remove-unversioned option and it happens not to work because we fail
to clear the read-only bit on files within unversioned directories,
well, we should fix that.

Can you file an issue in https://issues.apache.org/jira/projects/SVN please?

-- Brane

Re: svn cleanup options

[Branko Čibej]

On 14.02.2019 15:33, Stefan Sperling wrote:
> On Thu, Feb 14, 2019 at 03:29:20PM +0100, Stefan Sperling wrote:
>> On Thu, Feb 14, 2019 at 01:55:10PM +, Cooke, Mark wrote:
>>> Is there any way to say "ignore errors" or "ignore read-only" or even 
>>> "remove read-only"?
>>>
>> Well, it should already work without errors.
>> I am not sure why it does not work for you :-/
> Oh, if I remember correctly, Windows has this odd quirk where it is
> unable to delete files which are being held open by an application.
>
> Is this is happening in your case? If so, you will need to close these
> files first. This is not Subversion-specific; every program on Windows
> is affected by this issue.


That's true but 'open by an application' and 'has read-only flag set'
are two different things. Still, Subversion's 'make file read/write'
will clear the Windows read-only flag specifically for this reason.
Perhaps the read-only files are in some unversioned directory? We might
have missed this case.

-- Brane

Re: Is it possible to specify an external to the same repository?

[Branko Čibej]

On 05.02.2019 12:26, David Aldrich wrote:
> Hi
>
> In our embedded projects we have a register interface maintained by
> our HW team and software that uses that register interface maintained
> by our SW team.  As the interface is constantly changing, we want the
> software source files to reference a fixed version of the interface.
>
> In some projects the register interface and software are in separate
> repositories. So the software simply references the register interface
> using an svn external with fixed revision number.
>
> In other projects the register interface and software are in the same
> repository.  It is inconvenient to instruct all developers and users
> to peg specific revisions of the register interface within their
> working copies.  Can we use externals in this situation, or is there
> another solution?

Of course you can use externals that point to the same repository. Even
better, you can use 'relative' externals for such cases. See:

http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html

-- Brane

Re: svn problem

[Branko Čibej]

On 03.02.2019 16:42, Chagai Nota wrote:
>
> Hi support,
>
>  
>
> I’m new to use mailing list so if it’s not the right address please
> assist me where to do it.
>
>  
>
> I have a strange problem just with one user from all of our organztioan.
>
>  
>
> When he trying to do svn up or svn cleanup its takes very long time
> comparing to others.
>
> When I explore his problem I pay attenation (with strace command) that
> just for him it goes over pristine folder and go over each file there.
>
> Every time he open new checkout and after some period the problem back.
>


The first thing to do is to check what's happening to the system clock
on that computer. The effect you observe may be caused by the system
time changing unpredictably.

-- Brane

Re: Homebrew SVN 1.11 not working

[Branko Čibej]

On 25.01.2019 13:11, Branko Čibej wrote:
> On 25.01.2019 12:28, Mark Phippard wrote:
>>> On Jan 25, 2019, at 6:26 AM, Branko Čibej  wrote:
>>>
>>> On 25.01.2019 12:20, Mark Phippard wrote:
>>>>> AFAIK it does install from a bottle, but --with-javahl forces a build
>>>>> from source (all other bindings are bottled). You could request an
>>>>> improvement from the Homebrew folks, they're moderately responsive.
>>>> Apparently JavaHL has now been removed from the package:
>>>>
>>>> https://github.com/Homebrew/homebrew-core/pull/36217
>>>>
>>>> I have not submitted a PR to them before. Would you be willing to put
>>>> one together that adds the JavaHL library back to the build without
>>>> the option?  If you do not have time, I will take a crack later today.
>>>>
>>>> I do not see any reason that JavaHL could not just be part of the
>>>> package. There is nothing especially difficult about distributing it.
>>> Java is not installed by default on macOS.
>> Yes, but so what?  All this option would do is add the .dylib and JAR to the 
>> bottle and spit out a message telling you to create a symlink if you want to 
>> use it.  None of this would matter if you do not use Java.  It is just a 
>> library.  It actually seems easier than is the case for the Python and Ruby 
>> bindings.
>
> My only suggestion is to take this up with the Homebrew maintainers ...
> I don't pretend to understand the decisions they make.

Duh.

https://github.com/Homebrew/homebrew-core/issues/31510


You're right, it'd be best to restore the JavaHL build and make it
always available, + document usage.

-- Brane

Re: Homebrew SVN 1.11 not working

[Branko Čibej]

On 25.01.2019 12:28, Mark Phippard wrote:
>> On Jan 25, 2019, at 6:26 AM, Branko Čibej  wrote:
>>
>> On 25.01.2019 12:20, Mark Phippard wrote:
>>>> AFAIK it does install from a bottle, but --with-javahl forces a build
>>>> from source (all other bindings are bottled). You could request an
>>>> improvement from the Homebrew folks, they're moderately responsive.
>>> Apparently JavaHL has now been removed from the package:
>>>
>>> https://github.com/Homebrew/homebrew-core/pull/36217
>>>
>>> I have not submitted a PR to them before. Would you be willing to put
>>> one together that adds the JavaHL library back to the build without
>>> the option?  If you do not have time, I will take a crack later today.
>>>
>>> I do not see any reason that JavaHL could not just be part of the
>>> package. There is nothing especially difficult about distributing it.
>> Java is not installed by default on macOS.
> Yes, but so what?  All this option would do is add the .dylib and JAR to the 
> bottle and spit out a message telling you to create a symlink if you want to 
> use it.  None of this would matter if you do not use Java.  It is just a 
> library.  It actually seems easier than is the case for the Python and Ruby 
> bindings.


My only suggestion is to take this up with the Homebrew maintainers ...
I don't pretend to understand the decisions they make.

-- Brane

Re: Homebrew SVN 1.11 not working

[Branko Čibej]

On 25.01.2019 12:20, Mark Phippard wrote:
>> AFAIK it does install from a bottle, but --with-javahl forces a build
>> from source (all other bindings are bottled). You could request an
>> improvement from the Homebrew folks, they're moderately responsive.
>
> Apparently JavaHL has now been removed from the package:
>
> https://github.com/Homebrew/homebrew-core/pull/36217
>
> I have not submitted a PR to them before. Would you be willing to put
> one together that adds the JavaHL library back to the build without
> the option?  If you do not have time, I will take a crack later today.
>
> I do not see any reason that JavaHL could not just be part of the
> package. There is nothing especially difficult about distributing it.

Java is not installed by default on macOS.

-- Brane

Re: Subversion 1.10.4

[Branko Čibej]

On 22.01.2019 14:29, Joachim Poppe wrote:
> Hi,
>
> there is no valid release date within CHANGES file of this version:
>
> Version 1.10.4
> (?? ??? 2019, from /branches/1.10.x)
> http://svn.apache.org/repos/asf/subversion/tags/1.10.4
>
> ...
>
> Is this LTS version released or not?

Yes, it is. The missing date is an oversight.

-- Brane

Re: Homebrew SVN 1.11 not working

[Branko Čibej]

On 17.01.2019 21:35, Mark Phippard wrote:
> On Thu, Jan 17, 2019 at 7:04 AM Branko Čibej  <mailto:br...@apache.org>> wrote:
>
> On 16.01.2019 21:51, Mark Phippard wrote:
>> On Wed, Jan 16, 2019 at 2:54 PM Mark Phippard > <mailto:markp...@gmail.com>> wrote:
>>
>> On Wed, Jan 16, 2019 at 2:10 PM Branko Čibej
>> mailto:br...@apache.org>> wrote:
>>
>> On 16.01.2019 15:39, Mark Phippard wrote:
>> > I am trying to update my Homebrew and it looks like it
>> wants to move
>> > me from SVN 1.10 to 1.11 but it is failing.  I do not
>> recall even
>> > asking it to install the Ruby bindings but perhaps I
>> did once. I
>> > thought I just had --with-java since I do need JavaHL. 
>> Any ideas?
>>
[... elided some history ...]
>
> The only thing I can suggest is that you install Xcode whether you
> use it or not. I never use it but I do install it and run it every
> now and then to install updates.
>
>
> Thanks, I gave this a try today, unfortunately it still fails.
>
> Is this a valid (and quicker) way to check my dev environment before
> trying to do the full build?
>
> /usr/bin/ruby -r mkmf -e 'exit(have_func("rb_hash_foreach") ? 0 : 1)'


As far as I know, yes, it is.


> Because this still gives the same error about the developer tools not
> being installed.  A Google search led me to this which looked promising:
>
> https://blog.driftingruby.com/updated-to-mojave/
>
> But unfortunately it wasn't. I even tried following a link in the
> comments to re-download the command line tools and that did not help
> either.  I will just go back to editing the subversion.rb for now.


I tried all of those suggestions, when I saw this problem in High
Sierra. Then I upgraded to Mojave (after the last Xcode update) and the
issue went away. I don't understand what's going on.


> BTW, do you know why SVN cannot be packaged as a bottle?  It might be
> the only formula I have installed that still builds from source. I
> would think it could just bundle everything and if the user does
> --with-java it creates the symlink otherwise it skips that.


AFAIK it does install from a bottle, but --with-javahl forces a build
from source (all other bindings are bottled). You could request an
improvement from the Homebrew folks, they're moderately responsive.

https://github.com/Homebrew/homebrew-core/issues

-- Brane

Re: Homebrew SVN 1.11 not working

[Branko Čibej]

On 16.01.2019 21:51, Mark Phippard wrote:
> On Wed, Jan 16, 2019 at 2:54 PM Mark Phippard  <mailto:markp...@gmail.com>> wrote:
>
> On Wed, Jan 16, 2019 at 2:10 PM Branko Čibej  <mailto:br...@apache.org>> wrote:
>
> On 16.01.2019 15:39, Mark Phippard wrote:
> > I am trying to update my Homebrew and it looks like it wants
> to move
> > me from SVN 1.10 to 1.11 but it is failing.  I do not recall
> even
> > asking it to install the Ruby bindings but perhaps I did once. I
> > thought I just had --with-java since I do need JavaHL.  Any
> ideas?
> >
> > ==> make swig-rb EXTRA_SWIG_LDFLAGS=-L/usr/lib
> > Last 15 lines from
> /Users//Library/Logs/Homebrew/subversion/14.make:
> > 2019-01-16 09:36:12 -0500
> >
> > make
> > swig-rb
> > EXTRA_SWIG_LDFLAGS=-L/usr/lib
> >
> > /bin/sh
> >
> 
> "/private/tmp/subversion-20190116-34242-xgy0wo/subversion-1.11.1/libtool"
> > --tag=CC --silent --mode=compile none
>  -I/usr/local/opt/sqlite/include
> > -I/usr/local/opt/readline/include
> -I/usr/local/opt/gettext/include
> > -I/usr/local/opt/openssl/include -F/usr/local/Frameworks
> -isysroot
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
>  -DDARWIN
> > -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10
> >
>  
> -I/private/tmp/subversion-20190116-34242-xgy0wo/subversion-1.11.1/subversion/bindings/swig/ruby/libsvn_swig_ruby
> > -prefer-pic -c -o subversion/bindings/swig/ruby/svn_client.lo
> > subversion/bindings/swig/ruby/svn_client.c
> >
> 
> /private/tmp/subversion-20190116-34242-xgy0wo/subversion-1.11.1/libtool:
> > line 1760: none: command not found
> > make: *** [subversion/bindings/swig/ruby/svn_client.lo] Error 1
> >
> >
> > I do not need these so ideas could include telling me how to
> > reconfigure my install so that it does not try to build
> these.  I only
> > need the SVN command line and JavaHL.  Do not care about any
> other
> > language bindings.
>
>
> https://github.com/Homebrew/homebrew-core/pull/33530
>
>
> I am not seeing what the solution was.  The last message seemed to
> be about unsetting SDKROOT but that seemed internal to Brew, not
> my env.
>
>
> FWIW, I decided to use $ brew edit subversion to stop the swig-rb from
> trying to build, but if there is some fix I can make to my local
> machine would appreciate knowing what that is for future versions. I
> looked through those PR's and it seemed like all of the "fixes" were
> made in the build scripts.  I only have the CLT installed:
>
> $ brew config
> HOMEBREW_VERSION: 1.9.2-9-g9141b15
> ORIGIN: https://github.com/Homebrew/brew.git
> HEAD: 9141b1509bb44da6c0a9683733ffe4a890690d8e
> Last commit: 12 hours ago
> Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
> Core tap HEAD: 82dc586c001a22051376ecbf8076473d67089370
> Core tap last commit: 9 hours ago
> HOMEBREW_PREFIX: /usr/local
> HOMEBREW_CASK_OPTS: --appdir=/Applications
> HOMEBREW_DEV_CMD_RUN: 1
> HOMEBREW_LOGS: /Users/markphip/Library/Logs/Homebrew
> CPU: octa-core 64-bit haswell
> Homebrew Ruby: 2.3.7 =>
> /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
> Clang: 10.0 build 1000
> Git: 2.20.1 => /usr/local/bin/git
> Curl: 7.54.0 => /usr/bin/curl
> Java: 1.8.0_60, 1.8.0_31
> macOS: 10.14.2-x86_64
> CLT: 10.1.0.0.1.1539992718
> Xcode: N/A
>
> $ xcode-select -v
> xcode-select version 2354.
>
> All updates are installed.

$ brew config
HOMEBREW_VERSION: 1.9.2-23-g609a91c
ORIGIN: https://github.com/Homebrew/brew.git
HEAD: 609a91c34547b0ccfdabde1cfdd39488b8d970c0
Last commit: 2 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 9c59062900e897cebbcbf3a95e86282df4feb509
Core tap last commit: 3 hours ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_DEV_CMD_RUN: 1
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_LOGS: /Users/brane/Library/Logs/Homebrew
HOMEBREW_NO_ANALYTICS: 1
CPU: octa-core 64-bit kabylake
Homebrew Ruby: 2.3.7 => 
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Clang: 10.0 build 1000
Git: 2.20.1 => /usr/local/bin/git
Curl: 7.54.0 => /usr/bin/curl
Java: 11, 1.8.0_191
macOS: 10.14.2-x86_64
CLT: 10.1.0.0.1.1539992718
Xcode: 10.1
XQuartz: 2.7.11 => /opt/X11

$ xcode-select -v
xcode-select v

Re: Homebrew SVN 1.11 not working

[Branko Čibej]

On 16.01.2019 20:54, Mark Phippard wrote:
> On Wed, Jan 16, 2019 at 2:10 PM Branko Čibej  <mailto:br...@apache.org>> wrote:
>
> On 16.01.2019 15:39, Mark Phippard wrote:
> > I am trying to update my Homebrew and it looks like it wants to move
> > me from SVN 1.10 to 1.11 but it is failing.  I do not recall even
> > asking it to install the Ruby bindings but perhaps I did once. I
> > thought I just had --with-java since I do need JavaHL.  Any ideas?
> >
> > ==> make swig-rb EXTRA_SWIG_LDFLAGS=-L/usr/lib
> > Last 15 lines from
> /Users//Library/Logs/Homebrew/subversion/14.make:
> > 2019-01-16 09:36:12 -0500
> >
> > make
> > swig-rb
> > EXTRA_SWIG_LDFLAGS=-L/usr/lib
> >
> > /bin/sh
> >
> "/private/tmp/subversion-20190116-34242-xgy0wo/subversion-1.11.1/libtool"
> > --tag=CC --silent --mode=compile none
>  -I/usr/local/opt/sqlite/include
> > -I/usr/local/opt/readline/include -I/usr/local/opt/gettext/include
> > -I/usr/local/opt/openssl/include -F/usr/local/Frameworks -isysroot
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk  -DDARWIN
> > -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10
> >
>  
> -I/private/tmp/subversion-20190116-34242-xgy0wo/subversion-1.11.1/subversion/bindings/swig/ruby/libsvn_swig_ruby
> > -prefer-pic -c -o subversion/bindings/swig/ruby/svn_client.lo
> > subversion/bindings/swig/ruby/svn_client.c
> >
> /private/tmp/subversion-20190116-34242-xgy0wo/subversion-1.11.1/libtool:
> > line 1760: none: command not found
> > make: *** [subversion/bindings/swig/ruby/svn_client.lo] Error 1
> >
> >
> > I do not need these so ideas could include telling me how to
> > reconfigure my install so that it does not try to build these. 
> I only
> > need the SVN command line and JavaHL.  Do not care about any other
> > language bindings.
>
>
> https://github.com/Homebrew/homebrew-core/pull/33530
>
>
> I am not seeing what the solution was.  The last message seemed to be
> about unsetting SDKROOT but that seemed internal to Brew, not my env.


I was just pointing out that this has been a problem with Homebrew for a
while. One that I don't understand; I build Subversion with no problems
on my laptop, both from our sources and from the Homebrew package, and
also from the macOS buildslave, which has Xcode 10 installed, too.

No, I don't understand what they changed to make their builds suddenly work.

-- Brane

Re: Homebrew SVN 1.11 not working

[Branko Čibej]

On 16.01.2019 20:10, Branko Čibej wrote:
> On 16.01.2019 15:39, Mark Phippard wrote:
>> I am trying to update my Homebrew and it looks like it wants to move
>> me from SVN 1.10 to 1.11 but it is failing.  I do not recall even
>> asking it to install the Ruby bindings but perhaps I did once. I
>> thought I just had --with-java since I do need JavaHL.  Any ideas?
>>
>> ==> make swig-rb EXTRA_SWIG_LDFLAGS=-L/usr/lib
>> Last 15 lines from /Users//Library/Logs/Homebrew/subversion/14.make:
>> 2019-01-16 09:36:12 -0500
>>
>> make
>> swig-rb
>> EXTRA_SWIG_LDFLAGS=-L/usr/lib
>>
>> /bin/sh
>> "/private/tmp/subversion-20190116-34242-xgy0wo/subversion-1.11.1/libtool"
>> --tag=CC --silent --mode=compile none  -I/usr/local/opt/sqlite/include
>> -I/usr/local/opt/readline/include -I/usr/local/opt/gettext/include
>> -I/usr/local/opt/openssl/include -F/usr/local/Frameworks -isysroot
>> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk  -DDARWIN
>> -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10
>>  
>> -I/private/tmp/subversion-20190116-34242-xgy0wo/subversion-1.11.1/subversion/bindings/swig/ruby/libsvn_swig_ruby
>> -prefer-pic -c -o subversion/bindings/swig/ruby/svn_client.lo
>> subversion/bindings/swig/ruby/svn_client.c
>> /private/tmp/subversion-20190116-34242-xgy0wo/subversion-1.11.1/libtool:
>> line 1760: none: command not found
>> make: *** [subversion/bindings/swig/ruby/svn_client.lo] Error 1
>>
>>
>> I do not need these so ideas could include telling me how to
>> reconfigure my install so that it does not try to build these.  I only
>> need the SVN command line and JavaHL.  Do not care about any other
>> language bindings.
>
> https://github.com/Homebrew/homebrew-core/pull/33530


TL;DR: Apple messed up royally with Xcode 10 and its command-line tools.

-- Brane

Re: Homebrew SVN 1.11 not working

[Branko Čibej]

On 16.01.2019 15:39, Mark Phippard wrote:
> I am trying to update my Homebrew and it looks like it wants to move
> me from SVN 1.10 to 1.11 but it is failing.  I do not recall even
> asking it to install the Ruby bindings but perhaps I did once. I
> thought I just had --with-java since I do need JavaHL.  Any ideas?
>
> ==> make swig-rb EXTRA_SWIG_LDFLAGS=-L/usr/lib
> Last 15 lines from /Users//Library/Logs/Homebrew/subversion/14.make:
> 2019-01-16 09:36:12 -0500
>
> make
> swig-rb
> EXTRA_SWIG_LDFLAGS=-L/usr/lib
>
> /bin/sh
> "/private/tmp/subversion-20190116-34242-xgy0wo/subversion-1.11.1/libtool"
> --tag=CC --silent --mode=compile none  -I/usr/local/opt/sqlite/include
> -I/usr/local/opt/readline/include -I/usr/local/opt/gettext/include
> -I/usr/local/opt/openssl/include -F/usr/local/Frameworks -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk  -DDARWIN
> -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10
>  
> -I/private/tmp/subversion-20190116-34242-xgy0wo/subversion-1.11.1/subversion/bindings/swig/ruby/libsvn_swig_ruby
> -prefer-pic -c -o subversion/bindings/swig/ruby/svn_client.lo
> subversion/bindings/swig/ruby/svn_client.c
> /private/tmp/subversion-20190116-34242-xgy0wo/subversion-1.11.1/libtool:
> line 1760: none: command not found
> make: *** [subversion/bindings/swig/ruby/svn_client.lo] Error 1
>
>
> I do not need these so ideas could include telling me how to
> reconfigure my install so that it does not try to build these.  I only
> need the SVN command line and JavaHL.  Do not care about any other
> language bindings.


https://github.com/Homebrew/homebrew-core/pull/33530

Re: subversion-1.11.1/subversion/libsvn_client/upgrade.c:353: poor error checking ?

[Branko Čibej]

On 12.01.2019 16:32, David Binderman wrote:
> Hello there,
>
> subversion-1.11.1/subversion/libsvn_client/upgrade.c:353] -> 
> [subversion-1.11.1/subversion/libsvn_client/upgrade.c:358]: (style) The if 
> condition is the same as the previous if condition
>
> Source code is
>
>   if (!err)
> externals_parent_url = svn_path_url_add_component2(
> externals_parent_repos_root_url,
> externals_parent_repos_relpath,
> iterpool);
>   if (!err)


Thanks! Fixed on trunk in r1851180.


> Maybe better code
>
>   if (!err)
> externals_parent_url = svn_path_url_add_component2(
> externals_parent_repos_root_url,
> externals_parent_repos_relpath,
> iterpool);
>
>   if (externals_parent_url)


Looks better but is unfortunately wrong. :)

-- Brane

Re: Problems with using a symbolic link for .svn folder on TSVN

[Branko Čibej]

On 10.01.2019 13:40, minxing...@gmail.com wrote:
> I see. Is it possible to change the implementation slightly as outlined by 
> Boost SVN? (https://svn.boost.org/trac10/ticket/6809). I believe this is the 
> same issue.


It is the same issue and no it is not possible to change the
implementation "slightly" because the integrity of the working copy
relies on atomic renames. That is why Subversion doesn't use the system-
(or user-) specific temporary directory (defined by %TMP% and %TEMP% on
Windows) for such files but creates them in .svn/, to make it as likely
as possible that they'll be on the same volume as the rest of the
working copy.

The only thing we could do would be to not create temporary files in
.svn/ but in the same directory as the target file, but then we'd have
problems with potential name collisions and with such temporary files
cluttering the working copy tree after aborted operations.

It's possible, but it's not a "slight" change like adding another flag
to MoveFileEx.

-- Brane


> -Original Message-
> From: Daniel Shahaf  
> Sent: Thursday, 10 January 2019 1:36 PM
> To: Oscar Lee ; users@subversion.apache.org
> Subject: Re: Problems with using a symbolic link for .svn folder on TSVN
>
> Oscar Lee wrote on Wed, 09 Jan 2019 19:10 +0100:
>> My company uses TortoiseSVN internally to keep our files updated. The 
>> .svn folder for the project I have is massive (250GB) and as such I 
>> had to move it off to an external HDD. I created a symbolic link to 
>> the new location so that TortoiseSVN 'should' still continue to work.
> How large are the working copy files not under the .svn/ directory?
>
> If they're substantially smaller than 250GB, you might be running into this:
> https://subversion.apache.org/docs/release-notes/1.7#wc-pristines
>
>> I managed to run a clean-up, but when I tried to revert a file, it 
>> gave me an error 'Failed to run the WC DB work queue associated with 
>> (file)" and "Can't move (tmp file) to ... (original file): The system 
>> cannot move the file to a different disk drive".
>>
>> I found that this error is caused by Windows not letting a file be 
>> renamed while it is being moved ( 
>> https://docs.microsoft.com/en-us/previous-versions/ms837428(v=msdn.10)).
>> Does anyone know a solution to this?
>> Why is this an issue that only occurs with a symbolic link setup?
> Subversion assumes that it is possible to atomically move a file from the 
> .svn directory to the working copy's checked out files.  That would not 
> possible when the .svn directory is on a different drive / filesystem.
>

Re: Problems with using a symbolic link for .svn folder on TSVN

[Branko Čibej]

On 09.01.2019 19:10, Oscar Lee wrote:
> Hi,
>
> I was told to post my issue here from a TSVN dev.
>
> My company uses TortoiseSVN internally to keep our files updated. The .svn
> folder for the project I have is massive (250GB) and as such I had to move
> it off to an external HDD. I created a symbolic link to the new location so
> that TortoiseSVN 'should' still continue to work.

Well, it "should" not, see below.

But if your .svn/ directory is much bigger than the rest of your working
copy, then 'svn cleanup --vacuum-pristines' will probably reduce its
size. In TSVN you'll have to select the checkbox "Vacuum pristine copies".

> I managed to run a clean-up, but when I tried to revert a file, it gave me
> an error 'Failed to run the WC DB work queue associated with (file)" and
> "Can't move (tmp file) to ... (original file): The system cannot move the
> file to a different disk drive".
>
> I found that this error is caused by Windows not letting a file be renamed
> while it is being moved (
> https://docs.microsoft.com/en-us/previous-versions/ms837428(v=msdn.10)).
> Does anyone know a solution to this? Why is this an issue that only occurs
> with a symbolic link setup?

This has nothing to do with symbolic links but with the fact that
Subversion, during normal operations, has to atomically rename (and
move) a file from somewhere in the .svn/ directory to its expected
location in the working copy. Windows can't do that if the source and
target of the rename are on different volumes, that's what the error
message is telling you. The explanation your link points to is
misleading, to put it mildly ... it's the move to a different volume
that fails, not the renaming of the file.

-- Brane

Re: svn warning

[Branko Čibej]

On 23.12.2018 09:54, Руслан Самигуллин wrote:
> Hello!
>
> I have a problem with svn. The problem appears when I run svn. I have two 
> computers on Windows 10 x64, and on Win10 x32 [Version 10.0.17763.195]. This 
> problem appears on both computers.
>
> The text from the console window is reduced below:
>
> svn: warning: cannot set LC_CTYPE locale
> svn: warning: environment variable LANG is not set
> svn: warning: please check that your locale name is correct
>
> I tried to set LANG=en_US.UTF-8 but it doesn`t work.
> Please help me. How can I fix this problem?


You haven't replied to my last message on the other thread about this
issue that you started. Please don't just repeat questions, follow up on
that thread instead.

-- Brane

Re: FW: Error with svn

[Branko Čibej]

On 20.12.2018 17:59, Branko Čibej wrote:
> On 20.12.2018 13:41, Руслан Самигуллин wrote:
>> I have running Subversion on 64-bit Win and on 32-bit Win. Maybe I am wrong 
>> for this command, I found it on this web site: 
>> https://stackoverflow.com/questions/11300633/svn-cannot-set-lc-ctype-locale
>
> This answer on StackOverflow is only for Debian Linux and related
> (Ubuntu, Mint, etc.). It won't work on Windows.
>
>
>> I said that I don`t know how to fix my problem on Win. Please help me. What 
>> command is needed to set “variable LANG” or another way to solve this 
>> problem?
> For some reason your regional setting on Windows are not correct.
> Subversion uses 'setlocale(LC_ALL, "")' and if that fails,
> 'setlocale(LC_CTYPE, "")'. This should always work on Windows; I don't
> know why it doesn't.
>
> See:
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale
>
> Are you sure you're using a native Windows binary of Subversion, not
> something built for Cygwin or WSL?
>
>
> -- Brane
>
>
>> From: Branko Čibej
>> Sent: Thursday, 20 December 2018 15:17
>> To: Руслан Самигуллин; users@subversion.apache.org
>> Subject: Re: Error with svn
>>
>> On 20.12.2018 11:31, Руслан Самигуллин wrote:
>>> Hello!
>>>
>>> I have a problem with svn. The problem appears when I run svn.exe. I have 
>>> Windows 10 x64, and this problem appears in Win10 x32.
>>>
>>> The text from the console window is reduced below:
>>>
>>> svn: warning: cannot set LC_CTYPE locale
>>> svn: warning: environment variable LANG is not set
>>> svn: warning: please check that your locale name is correct
>>>
>>> I found that have to install language pack like that: (sudo apt-get install 
>>> language-pack-en-base) and set it like that: (export LC_ALL=C) but I don`t 
>>> know how to do it. And in what catalogue I must write the command to 
>>> install in cmd?
>> I'm confused: You say you're running 32-bit Subversion binaries on
>> 64-bit Windows, but then you show the proposed 'fix' as commands that
>> would work on some Debian-based Linux distribution? That can't be right.
>> Where did you get those commands from?
>>


Руслан, please respond here instead of starting a new thread with the
same topic.

-- Brane

Re: FW: Error with svn

[Branko Čibej]

On 20.12.2018 13:41, Руслан Самигуллин wrote:
> I have running Subversion on 64-bit Win and on 32-bit Win. Maybe I am wrong 
> for this command, I found it on this web site: 
> https://stackoverflow.com/questions/11300633/svn-cannot-set-lc-ctype-locale


This answer on StackOverflow is only for Debian Linux and related
(Ubuntu, Mint, etc.). It won't work on Windows.


> I said that I don`t know how to fix my problem on Win. Please help me. What 
> command is needed to set “variable LANG” or another way to solve this problem?

For some reason your regional setting on Windows are not correct.
Subversion uses 'setlocale(LC_ALL, "")' and if that fails,
'setlocale(LC_CTYPE, "")'. This should always work on Windows; I don't
know why it doesn't.

See:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale

Are you sure you're using a native Windows binary of Subversion, not
something built for Cygwin or WSL?


-- Brane


> From: Branko Čibej
> Sent: Thursday, 20 December 2018 15:17
> To: Руслан Самигуллин; users@subversion.apache.org
> Subject: Re: Error with svn
>
> On 20.12.2018 11:31, Руслан Самигуллин wrote:
>> Hello!
>>
>> I have a problem with svn. The problem appears when I run svn.exe. I have 
>> Windows 10 x64, and this problem appears in Win10 x32.
>>
>> The text from the console window is reduced below:
>>
>> svn: warning: cannot set LC_CTYPE locale
>> svn: warning: environment variable LANG is not set
>> svn: warning: please check that your locale name is correct
>>
>> I found that have to install language pack like that: (sudo apt-get install 
>> language-pack-en-base) and set it like that: (export LC_ALL=C) but I don`t 
>> know how to do it. And in what catalogue I must write the command to install 
>> in cmd?
>
> I'm confused: You say you're running 32-bit Subversion binaries on
> 64-bit Windows, but then you show the proposed 'fix' as commands that
> would work on some Debian-based Linux distribution? That can't be right.
> Where did you get those commands from?

Re: Error with svn

[Branko Čibej]

On 20.12.2018 11:31, Руслан Самигуллин wrote:
> Hello!
>
> I have a problem with svn. The problem appears when I run svn.exe. I have 
> Windows 10 x64, and this problem appears in Win10 x32.
>
> The text from the console window is reduced below:
>
> svn: warning: cannot set LC_CTYPE locale
> svn: warning: environment variable LANG is not set
> svn: warning: please check that your locale name is correct
>
> I found that have to install language pack like that: (sudo apt-get install 
> language-pack-en-base) and set it like that: (export LC_ALL=C) but I don`t 
> know how to do it. And in what catalogue I must write the command to install 
> in cmd?


I'm confused: You say you're running 32-bit Subversion binaries on
64-bit Windows, but then you show the proposed 'fix' as commands that
would work on some Debian-based Linux distribution? That can't be right.
Where did you get those commands from?


-- Brane

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

[Branko Čibej]

On 19.12.2018 09:18, Thorsten Schöning wrote:
> Guten Tag Thorsten Schöning,
> am Mittwoch, 21. November 2018 um 15:23 schrieben Sie:
>
>> News:
> The following arrived today:
>
>> Just wanted to let you know that this issue should now be resolved!
>> Let us know how you go.
>> Cheers,
>> Simon
>> GitHub Support
> Things seem to work again for me using the most current version of
> TortoiseSVN. What's about the newly added CI-test? Should be fine now
> I guess.

Yes, in fact that test unexpectedly passing alerted me to the change on
GitHub sometime last night.

They added that 'DAV: 1' response header and are now passing
Subversion's checks again.

Thanks to everyone who helped track this down and nagged GitHub for the fix!

-- Brane