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

[Branko Čibej]

On 10.12.2018 15:09, Nathan Hartman wrote:
> On Mon, Dec 10, 2018 at 5:14 AM Stefan Sperling  wrote:
>
>> Perhaps Github's customers will just need to press a little bit
>> harder for a fix to be applied at Github's end?
>
> Agreed. The squeaky wheel gets the grease.

GitHub has fixed their Subversion bridge. This was the first indication:

https://ci.apache.org/builders/svn-x64-macosx-local/builds/2744/steps/Test%20ra_local%2Bfsfs/logs/faillog

And here's the proof:

$ svn --version --quiet
1.11.0
$ svn info https://github.com/apache/httpd/trunk/
Path: trunk
URL: https://github.com/apache/httpd/trunk
Relative URL: ^/trunk
Repository Root: https://github.com/apache/httpd
Repository UUID: 908ae0b0-d39a-fa95-1ef9-ce57b7db7bff
Revision: 59645
Node Kind: directory
Last Changed Author: stefan.eissing
Last Changed Rev: 59634
Last Changed Date: 2018-12-18 14:58:31 +0100 (Tue, 18 Dec 2018)


-- Brane

Re: Subversion Exception!

[Branko Čibej]

On 12.12.2018 19:07, Stefan Kueng wrote:
> On 12.12.2018 13:55, TortoiseSVN-dev on behalf of Julian Foad wrote:
 Subversion encountered a serious problem.
 Please take the time to report this on the Subversion mailing list
>> […]
 https://subversion.apache.org/mailing-lists.html
>>
>>> It is likely that this is a problem specific to TortoiseSVN, and not
>>> to core SVN. TortoiseSVN has its own mailinglists, so you should
>>> report your problem there:
>> (Cross-posting.)
>
> Since this happens in the project monitor, my best guess is that the
> path/url the user entered to be monitored is not correct.
>
>>
>> It makes me sad every time I see this pattern. Software is often
>> frustrating to use, but should at least aim to be polite to its
>> users. Telling the user "Please do X" and then when the user does X
>> saying "No, it's no good doing X; do Y" is not polite, and I would
>> not expect anyone but the most calm, patient and helpful of users to
>> gracefully comply with such a request.
>>
>> I'm not meaning to criticise Johan but rather our whole system.
>>
>> Can we please fix this problem. Both:
>> 1) Tsvn please change the message.
>
> Sorry, won't do that. Because I've argued multiple times over the
> years here that calling exit() or even abort() in a library is the
> worst idea ever. Especially if this can happen by having the user
> enter a wrong path/url.

It's not the user entering the wrong path or URL. It's the code that
uses the Subversion libraries — in this case TSVN — not validating and
de-tainting its input. Yes, this has been going on for years due to your
obstinately refusing to conform to our API specs. In the meantime,
*your* users are left hanging.

The rules are clear and consistent: pointers may not be NULL unless
specifically allowed, paths must be absolute and canonical, URLs must be
canonical, all strings must be encoded in UTF-8. We provide a wide range
of helper functions that make it easy for API consumers to encode the
parameters.


> Sorry if this message seems rude - but I'm tired of arguing the same
> over and over again.


You don't say.


-- Brane

Re: Are my repos properly using ZLIB compression level 9?

[Branko Čibej]

On 12.12.2018 10:40, Thorsten Schöning wrote:
> Hi all,
>
> I upgraded all my repos using dump/load and changed the compression
> settings to use ZLIB 9, because I manage some pretty good compressable
> files at a low commit rate and want to preserve as much storage as
> possible for those. I used the following version of svnadmin and
> changed the following setting in fsfs.conf only:
>
>> svnadmin, Version 1.9.3 (r1718519)
>> [deltification]
>> compression-level = 9
> Overall memory of all my repos dropped significantly,


^^^ this is a pretty good indicator that "something" is working as you
expect. :)

>  so I guess
> thinks work as expected. But I didn't have a look at each individual
> revision file, instead I simply committed some textual changes in some
> text file in some test repo and found clear, readable text as DELTA in
> the created revision file on the server.
>
> Is this expected behaviour? I would have thought that all datas are
> unreadable because of compression. Or is there some threshold or such?
> What do I need to look for to make sure that ZLIB 9 is used?

In general, you can't just look at the compressed data and guess what
the compression level setting was.

Regarding plain text in "compressed" data, it really depends on the size
of the changes and type of data. Many compression algorithms — including
the text-delta algorithm used by Subversion, and I presume ZLIB, too —
will at some point decide that it makes no sense to try compressing some
parts of the data, because the compressed representation would be larger
than the plain source (due to overhead for dictionaries etc.). However
if you're seeing pages of uncompressed plain text, then we'll have to
investigate further.

-- Brane

Re: Check Path based authorization

[Branko Čibej]

[Please do not top-post on this list.]

On 12.12.2018 09:25, Stuempfig, Thomas wrote:
> Hi Brane,
>
> sorry i cannot post the contents of VisualSVN-WinAuthz.ini file since it is 
> company security related.
> I will take some time to setup a separate Demo LDAP, but this will take some 
> time.
>
> But basically my observation is
>
> 1) You have ldap group "GroupA"
> 2) Within that group you have users user_a and user_b (memberOf Attribute)
>
> now
> 3)  you setup your  repo authz file
> *
> [/]
> user_a  rw
> GroupA  rw
> *
>
> (I explicity do not include something like Group_A=user_a,user_b and set 
> @Group_A rw in authz file as this would duplicate ldap definition
> of Group membership)
>
> svnauthz gives "rw" for user_a and "Result no" for user_b
>
>
>
> my guess is that svnauthz does not evaluate the actual ldap info and ony 
> cares about groups defined in authz file whereas "svn --username .. ." does 
> authenticate with the ldap-group.  If I am thinking about the svnauthz 
> commandline, svnauthz has no information about the ldap connection which sits 
> in apache httpd.conf.

As Johan already wrote, Subversion does not look anywhere but in its
authorisation files for group definitions. Not LDAP, nor AD, nor any
other group directory. If your groups are defined in LDAP, then you very
likely already have a tool that extracts them from there into the proper
format for Subversion; in that case, all you need to do is tell svnauthz
about that file, see the '--groups-file' option.


-- Brane



> -Original Message-
> From: Branko Čibej [mailto:br...@apache.org]
> Sent: Dienstag, 11. Dezember 2018 20:54
> To: Stuempfig, Thomas (DF PL S DE PSM EAI) ; 
> users@subversion.apache.org
> Subject: Re: Check Path based authorization
>
> On 11.12.2018 18:40, Stuempfig, Thomas wrote:
>> Hi Brane,
>> well after testing the tool does not actually do what i would like. But it 
>> is giving me a starting point / work around.
>> I tested the tool with Visualsvn Server on windows
>>
>>
>> Steps to reproduce
>> 1) configure basic windows authentication
>>
>> 2) grant" rw" access to the repository root path for AD group
>> Visualsvn server places the objectSid
>> S-1-1-11-1-1--1  of the group in the
>> VisualSVN-WinAuthz.ini file of the repository
>>
>> 3) svnauthz.exe accessof --username 
>> S-2-2-22-2--2-2 
>> d:\repositories\test\conf\VisualSVN-WinAuthz.ini
>>   Where username is a member of the AD group objectSid
>> S-1-1-11-1-1--1
>>  Result no
>>
>> But
>> 4) svnauthz.exe accessof --username
>> S-1-1-11-1-1--1  2
>> d:\repositories\test\conf\VisualSVN-WinAuthz.ini
>> Gives "rw"
> I really have no idea what the WinAuthz.ini file is and what VisualSVN does 
> with it. It's impossible to say if your result is expected if we don't see 
> the contents of the authz file.
>
> But yes, 'svnauthz' will calculate access for users, not for groups. A user 
> can be a member of several groups and the actual rights she has can be a 
> combination of rights granted to the groups.
>
> -- Brane
>
> -
> Siemens Industry Software GmbH; Anschrift: Franz-Geuer-Str. 10, 50823 Köln; 
> Gesellschaft mit beschränkter Haftung; Geschäftsführer: Urban August, Daniel 
> Trebes; Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht Köln, HRB 
> 84564

Re: Check Path based authorization

[Branko Čibej]

On 11.12.2018 10:24, Stuempfig, Thomas wrote:
> Hi all,
> We have a large organization many projects and quite a bit of history 
> (10years) with one of the repos… and after a while path based authorization 
> becomes quite difficult.
> I would like to ask if it is possible as an admin to check path based 
> authorization for a user x (ldap).
>
> It would be great if one could give (“none”,”rw”,”r”) or alike for path.
> Kind executing a call like the call below as admin.
>
> getactiveprivs usertocheck 
> http(s)://server.domain.com//svn/myproject/branches/branch_dev/
>
> I mean this is the core, there could be several variations of this call. Get 
> privs of ldap group members … as different members belong to different other 
> groups each of them have possibly different access rights. It would be really 
> great to have some table of active priviledges.


Is the 'svnauthz' tool not good enough? It's usually installed
separately from the core binaries, in some 'subversion-tools' package,
but it's intended for exactly this kind of test.


-- Brane

$ svnauthz accessof --help
accessof: Print or test the permissions set by an authz file.
usage: 1. svnauthz accessof TARGET
   2. svnauthz accessof -t TXN REPOS_PATH FILE_PATH

  1. Prints the access of USER to PATH based on authorization file at TARGET.
 TARGET can be a path to a file or an absolute file:// URL to an authz
 file in a repository, but cannot be a repository relative URL (^/).

  2. Prints the access of USER to PATH based on authz file at FILE_PATH in the
 transaction TXN in the repository at REPOS_PATH.

  USER is the argument to the --username option; if that option is not
  provided, then access of an anonymous user will be printed or tested.

  PATH is the argument to the --path option; if that option is not provided,
  the maximal access to any path in the repository will be considered.

Outputs one of the following:
 rwwrite access (which also implies read)
  rread access
 nono access

Returns:
0   when syntax is OK and '--is' argument (if any) matches.
1   when syntax is invalid.
2   operational error
3   when '--is' argument doesn't match

Valid options:
  -t [--transaction] ARG   : transaction id
  --username ARG   : username to check access of
  --path ARG   : path within repository to check access of
  --repository ARG : repository authz name
  --is ARG : instead of outputting, test if the access is
 exactly ARG
 ARG can be one of the following values:
rwwrite access (which also implies read)
 rread-only access
nono access
  --groups-file ARG: use the groups from file ARG
  -R [--recursive] : determine recursive access to PATH

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

[Branko Čibej]

On 10.12.2018 10:08, Thorsten Schöning wrote:
> Guten Tag Branko Čibej,
> am Sonntag, 9. Dezember 2018 um 19:27 schrieben Sie:
>
>> My current thinking is that if GitHub can't fix their protocol emulation
>> by the time of the planned Subversion 1.12 release, we'll have to
>> seriously consider including this patch.
> If they really didn't fix it until 1.12, they surely won't ever
> anymore. Maybe this gives you enough time to discuss this
> fundamentally and tell people what they can expect for issues like
> this one in future from the SVN-team?
>
> It seems clear to me that the issue would need to be fixed by GH, but
> your are able to workaround it somewhat easily. But this is only one
> issue, what in case of another one easy like this or more difficult?

Exactly, this is why I'd prefer not to implement a specific hack for
GitHub in our code. If we made it a policy to support one broken server,
everyone would expect us to do so for the N+1st broken server, too ...
it's simply unmanageable in the long run.


> In theory 1.12 could break something different for some reason and
> people would need to stick with 1.10 for at least a year then.

Ah, but we have a test in our test suite now (for this particular case). :)


> If you come to the conclusion that you don't do this kind of hacking
> anymore

Just to point out: it' snot "any more"; we've never had any
vendor-specific hacks in our code.

Well actually that's not quite true, we still have a (build-time) hack
for Microsoft's ASP.Net, which could not abide having the '.svn'
directory in its project tree; but that was a client-side, compile-time
hack for a misfeature that had no workaround.

>  or even at all including this issue, users of the SVN-bridge
> would simply need to change their workflow to something else. I'm
> only using the bridge because it was the easiest way to stay with my
> former workflow and how I manage some versioned libs.
>
> Or do you think it's not worth discussing that fundamentally (yet)?

It is surely worth discussing, but please, such discussions really
should happen on our dev@ list, not the users@ list. Feel free to start
a thread there.


-- Brane

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

[Branko Čibej]

On 09.12.2018 23:41, Nico Kadel-Garcia wrote:
> On Sun, Dec 9, 2018 at 1:27 PM Branko Čibej  wrote:
>> On 09.12.2018 19:14, Thorsten Schöning wrote:
>>> Guten Tag Thorsten Schöning,
>>> am Mittwoch, 21. November 2018 um 15:23 schrieben Sie:
>>>
>>>>> Thanks for following up. Our engineers have been able to reproduce
>>>>> the error on our CI system and are working on a fix.
>>> Another two weeks have passed without any hint to the status of this
>>> problem from GH and I don't have the feeling that they are really
>>> working on this.
>>>
>>> Does anyone have any other infos? If not, does the SVN-team has any
>>> plans to release their workaround mentioned in the following ticket?
>>>
>>> https://issues.apache.org/jira/browse/SVN-4789
>> So, as I said in one of the mails referred to in that issue ... I'd
>> really prefer not to do that. Yet on the other hand, that GitHub->SVN
>> bridge is useful to users who're not locked into the gitficionado world.
>>
>> My current thinking is that if GitHub can't fix their protocol emulation
>> by the time of the planned Subversion 1.12 release, we'll have to
>> seriously consider including this patch.
>>
>> But I'd still rather not ...
> I've reviewed the directions at
> https://help.github.com/articles/support-for-subversion-clients/ , and
> it's a fairly ugly hack, and work to do the integrated checkouts. The
> last person I met who used it switched, with my help, to using git,
> and using git-svn for access to their local Subversion repositories so
> that they could commit working changes locally before submitting them
> to the upstream Subversion repository. I recognize that this is *not*
> the standard Subversion workflow, but I understood his desire to
> publish upstream only the changes he wished to submit.
>
> I'm afraid that the Subversion gateways to github.com are a niche
> market, and not one likely to get eager support from github.com
> without a compelling business reason to support them. The learning
> curve to use git effectively is pretty steep, but the market for
> Subversion-only users has been shrinking profoundly over the last
> decade.

So, what you're saying is that we have to revive and finish the ra_git
branch. :)

-- Brane

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

[Branko Čibej]

On 09.12.2018 19:14, Thorsten Schöning wrote:
> Guten Tag Thorsten Schöning,
> am Mittwoch, 21. November 2018 um 15:23 schrieben Sie:
>
>>> Thanks for following up. Our engineers have been able to reproduce
>>> the error on our CI system and are working on a fix.
> Another two weeks have passed without any hint to the status of this
> problem from GH and I don't have the feeling that they are really
> working on this.
>
> Does anyone have any other infos? If not, does the SVN-team has any
> plans to release their workaround mentioned in the following ticket?
>
> https://issues.apache.org/jira/browse/SVN-4789

So, as I said in one of the mails referred to in that issue ... I'd
really prefer not to do that. Yet on the other hand, that GitHub->SVN
bridge is useful to users who're not locked into the gitficionado world.

My current thinking is that if GitHub can't fix their protocol emulation
by the time of the planned Subversion 1.12 release, we'll have to
seriously consider including this patch.

But I'd still rather not ...

-- Brane

Re: Can SVN pull request same as GIT?

[Branko Čibej]

On 04.12.2018 12:12, Branko Čibej wrote:
> On 04.12.2018 10:11, 钱海远(Nathan) wrote:
>> Will you make any plan on SVN pull request?
> No.
>
> Subversion is a version control tool, not a code review tool. There are
> plenty of those available, both open-source and commercial, and some of
> them support Subversion for version control.
>
>
> Now if someone wants to write a pre-commit hook that will send a pending
> commit to code review, and will integrate nicely with *any* Subversion
> client ... you're welcome to bring your proposal to dev@. But don't
> expect someone else to write it for free in their spare time.


And of course it turns out that someone has already written this, all it
takes is a quick search:

https://pravinrajput.wordpress.com/2016/11/23/svn-reviewboard-integration-pre-commit-workflow/

-- Brane

Re: Can SVN pull request same as GIT?

[Branko Čibej]

On 04.12.2018 10:11, 钱海远(Nathan) wrote:
> Will you make any plan on SVN pull request?

No.

Subversion is a version control tool, not a code review tool. There are
plenty of those available, both open-source and commercial, and some of
them support Subversion for version control.


Now if someone wants to write a pre-commit hook that will send a pending
commit to code review, and will integrate nicely with *any* Subversion
client ... you're welcome to bring your proposal to dev@. But don't
expect someone else to write it for free in their spare time.


> More and more company change SCM system to Git.

That's their loss.

-- Brane

Re: Can SVN pull request same as GIT?

[Branko Čibej]

On 01.12.2018 10:00, Stefan Sperling wrote:
> So I fully agree with Brane; SVN provides all the tooling required, and
> people building code review tools just have to make clever use of it.

Just to be clear: my issue is not whether SVN provides the tooling, but
with this conflation of "feature" and "tool". The very phrase "git pull
request" is tremendously misleading, because "git" doesn't provide a
"pull request" feature in the first place.

One can hardly think rationally about solving a problem if the problem
isn't stated clearly in the first place.

-- Brane

Re: Can SVN pull request same as GIT?

[Branko Čibej]

On 01.12.2018 01:19, Nico Kadel-Garcia wrote:
> On Fri, Nov 30, 2018 at 8:20 AM Julian Foad  wrote:
>> Nico Kadel-Garcia wrote:
>>> On Thu, Nov 29, 2018 at 10:31 PM 钱海远(Nathan)  
>>> wrote:
 We want to develop a feature like git pull request .
 [...]
>>>  This seems infeasible. The working copy in which the merges would occur 
>>> does not exist in the Subversion workflow.
>> Hello Nico!  What do you mean? If Nathan is developing a Subversion pull 
>> request workflow, his software can create a WC when it needs one.
>>
>> Hello Nathan.  I am having difficulty knowing what you really require. "Like 
>> git pull request" could mean lots of different things. It would help if you 
>> can describe exactly what you require.
>>
>> - Julian
> git pull requests perform a merge in the local repository.


There are no "git pull requests". There are GitHub pull requests, and
BitBucket pull requests, and Gerrit pull requests, and so on. It doesn't
really matter whether or not they're all implemented the same way.


>  What you'd
> need to create for this is a local repository, not a working copy, and
> the working repository becomes part of a distributed source control
> system.

Nonsense. You're describing one _posslble_ way to implement a "code
review with automatic merge" workflow. What people tend to call "pull
requests" these days is a feature that's quite a bit older than git (or
bitkeeper before that) and worked just fine with centralised
repositories. Let's not confuse the forest and the trees.

-- Brane

Re: Can SVN pull request same as GIT?

[Branko Čibej]

On 30.11.2018 21:39, Nathan Hartman wrote:
> On Fri, Nov 30, 2018 at 4:56 AM Julian Foad  wrote:
>
>> 钱海远(Nathan) wrote:
>>> We want to develop a feature like git pull request .
>> Some other companies are also interested in developing the same.
>>
>> There are a few different possible directions.
>>
>> You could implement pull requests (PR) using Subversion's branches. The PR
>> would be some kind of message that you send to your PR server, saying
>> something like, "please merge branch
>> $REPO_URL/branches/pull-requests/pr1234 to $REPO_URL/branches/my-branch".
>> The PR server would check out the target branch in to a WC local to that
>> server, attempt the merge, commit it, and delete the PR. If the merge
>> fails, the PR server can "svn delete" the PR branch; there is no way to
>> permanently delete the contents of that branch from history, but in many
>> cases that can be OK. If there are conflicts, the PR server can send an
>> error report back to the originating user.
>
> It seems to me that the refactorings and support for shelving/checkpointing
> being developed right now are putting into place a good foundation for
> implementing pull request type functionality as well.


I hope we're all aware that "pull request" is not a git feature, it's a
feature of some tools built on top of git, right? Just to keep things in
perspective. One could always build such tools with Subversion. The
workflow would be slightly different, but that really shouldn't be an issue.

-- Brane

Re: AW: SVN on docker/kubernetes/openshift - shared storage?

[Branko Čibej]

On 27.11.2018 11:25, Tietz, Jonathan wrote:
> Hi,
>
> we have times where the load of our server is getting quite high, so we want 
> to spread the load to different svn-instances.

The first step is to find out what exactly is causing the load; whether
it's commits or updates or something else.


>  As we have TBs of data, we do not want to share these data over different 
> storages. 
>
> But if you say, that (one) shared storage with different svn-instances 
> (mod_subversion) will never work, than ok, I didn't find an answer. Can you 
> confirm?


Subversion itself supports master/slave replication, where all commits
go to a single server but read operations can be served by many. Maybe
that's sufficient for your case, but it's hard to say without any
performance data. Sometimes just tuning the server configuration may be
enough.

> If yes, then we have to thing about a different architecture, eg. many 
> svn-instances each with its own storage

Sure, you can split repositories amongst different servers. Or you can
use a commercial solution that provides master/master replication.

-- Brane


> -----Ursprüngliche Nachricht-
> Von: Branko Čibej  
> Gesendet: Freitag, 23. November 2018 12:06
> An: users@subversion.apache.org
> Betreff: Re: SVN on docker/kubernetes/openshift - shared storage?
>
> On 23.11.2018 11:27, Tietz, Jonathan wrote:
>> Hi,
>>
>> we are thinking about to run subversion on a docker/openshift environment.
>>
>> That means we have multiple subversion instances, reading/writing on 
>> subversion repositories saved on one shared storage (currently nfs 
>> filesystem)
>>
>> According to internet, e.g. 
>> https://support.wandisco.com/index.php?/Knowledgebase/Article/View/182
>> /0/why-you-should-not-use-network-file-system-with-git-or-svn
>> You should not use nfs.
>>
>> Has someone else running a similar setup with a shared storage? If yes, what 
>> filesystem are you using?
> What are you trying to achieve with this configuration? Perhaps there's a 
> better way to solve your use-case than using a basically unsupported and 
> possibly broken configuration.
>
> -- Brane

Re: SVN on docker/kubernetes/openshift - shared storage?

[Branko Čibej]

On 23.11.2018 11:27, Tietz, Jonathan wrote:
> Hi,
>
> we are thinking about to run subversion on a docker/openshift environment.
>
> That means we have multiple subversion instances, reading/writing on 
> subversion repositories saved on one shared storage (currently nfs filesystem)
>
> According to internet, e.g. 
> https://support.wandisco.com/index.php?/Knowledgebase/Article/View/182/0/why-you-should-not-use-network-file-system-with-git-or-svn
> You should not use nfs.
>
> Has someone else running a similar setup with a shared storage? If yes, what 
> filesystem are you using?

What are you trying to achieve with this configuration? Perhaps there's
a better way to solve your use-case than using a basically unsupported
and possibly broken configuration.

-- Brane

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

[Branko Čibej]

On 22.11.2018 17:39, Nico Kadel-Garcia wrote:
> On Wed, Nov 21, 2018 at 9:54 AM Branko Čibej  wrote:
>> On 21.11.2018 15:23, Thorsten Schöning wrote:
>>> Guten Tag Branko Čibej,
>>> am Donnerstag, 15. November 2018 um 18:21 schrieben Sie:
>>>
>>>> Has there been any further update from them on this issue?
>>> News:
>>>
>>>> Thanks for following up. Our engineers have been able to reproduce
>>>> the error on our CI system and are working on a fix.
>>>> This issue is already a focus for our SVN team. However people who
>>>> are experiencing this issue can feel free to write in to
>>>> supp...@github.com to report their own experience and we'll also let
>>>> them know when the issue is fixed.
>>
>> Oh, that's nice.
>>
>> -- Brane
> Can this be entirely sidestepped by using svn+ssh:// access instead of
> HTTPS:// ? I'm not currently using any Subversion based access to
> github, but it might provide a short-term workaround if it's
> supported.

Only if GitHub provides that service. I doubt they do -- they're not
converting Git repositores to Subversion repositories, they're emulating
a Subversion HTTP server that gets information directly from git
repositories plus (presumably) some additional data to maintain stable
commit-id->revision mappings.

To support svn+ssh:// they'd have to emulate a second Subversion protocol.

-- Brane

P.S.: Clearly, the cause of the issue discussed in this thread is that
the emulation is incomplete.

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

[Branko Čibej]

On 21.11.2018 15:23, Thorsten Schöning wrote:
> Guten Tag Branko Čibej,
> am Donnerstag, 15. November 2018 um 18:21 schrieben Sie:
>
>> Has there been any further update from them on this issue?
> News:
>
>> Thanks for following up. Our engineers have been able to reproduce
>> the error on our CI system and are working on a fix.
>> This issue is already a focus for our SVN team. However people who
>> are experiencing this issue can feel free to write in to
>> supp...@github.com to report their own experience and we'll also let
>> them know when the issue is fixed.


Oh, that's nice.

-- Brane

Re: AW: Subversion Exception!

[Branko Čibej]

On 20.11.2018 08:24, Hedtke, Gerd wrote:
> Still experiencing this behavior with TortoiseSVN 1.11.0


Please report this to the TortoiseSVN developers.

-- Brane

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

[Branko Čibej]

On 15.11.2018 19:07, Thorsten Schöning wrote:
> Guten Tag Branko Čibej,
> am Donnerstag, 15. November 2018 um 18:21 schrieben Sie:
>
>> Has there been any further update from them on this issue?
> Sadly not and they didn't get in contact with you using dev@?

Nope; not now, and not ever. Sigh.

-- Brane

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

[Branko Čibej]

On 05.11.2018 18:27, Thorsten Schöning wrote:
> Guten Tag Ryan Schmidt,
> am Montag, 5. November 2018 um 04:45 schrieben Sie:
>
>> I'd be interested to know the resolution, since I use the GitHub
>> svn bridge daily. I'll hold off on upgrading past Subversion 1.10.x
>> for now but could you keep us informed about what GitHub does to solve this?
> Support of GitHub answered:
>
>> Thanks to your report our engineers are investigating the situation.
>> I don't have an ETA for a fix but we'll keep you updated.


Has there been any further update from them on this issue?

In the meantime, I created this:

https://issues.apache.org/jira/browse/SVN-4789

It contains a patch for the Subversion client that hacks around GitHub's
bug, but it's a very messy hack indeed and I would prefer to not have it
in our code.

-- Brane

Re: How to commit only top level files?

[Branko Čibej]

On 06.11.2018 21:11, Bo Berglund wrote:
> I have a project where I want to commit the modified sources in the
> top folder but want to prevent it from recursing to subdirectories,
> which hold the compiled binaries. These are only to be committed when
> the sources are stable.
>
> I looked at svn ci with the --depth argument, but I do not understand
> the wording of the docs:
> http://svnbook.red-bean.com/en/1.7/svn.ref.svn.html#svn.ref.svn.sw.depth
>
> it says:
>
> --depth ARG
>
> Instructs Subversion to limit the scope of an operation to a
> particular tree depth. ARG is one of empty (only the target itself),
> files (the target and any immediate file children thereof), immediates
> (the target and any immediate children thereof), or infinity (the
> target and all of its descendants—full recursion).
>
> The problem I have is in the definition of "target"...

"Target" is any file or directory that you tell the command to operate
on. For example, when you say:

    svn commit foo bar

"foo" and "bar" are targets for 'svn commit'. You can omit explicit
targets for some commands — svn commit is one of them — in which case
the implicit target is the current directory; so,

    svn commit

means exactly the same as

    svn commit .


> I am doing the operation inside the top level of the WC tree (where
> the .svn dir is located).
> The command will be:
> svn ci --depth 
>
> What should I use as argument so that only the changed files in the
> current dir are committed?

    svn commit --depth files

(or 'svn commit --depth files .') will only commit /files/ that in the
current directory. On the other hand,

    svn commit --depth immediates

will commit files /and/ directories, but will not recurse into the
directories. Basically this means that changed files and property
changes on directories in the current dir will be committed, but nothing
else.


> empty does not work for me because the dir is NOT empty

That's not what '--depth empty' means. It means "commit only the target
itself", so if the target is a directory, it will only commit any
property changes on that directory.


> files does not work because I don't understand what "file children" is

Files within the target direcory.

> immediates clearly would include subdirs too?

Yes, but nothing inside those subdirs.

> infinity not what I want, full recursion...
>
> Tried to google but I only get hits that deal with the opposite, how
> to exclude file commit.
>
> I want to block recursion into subdirectories...

You want either 'svn commit --depth files' or 'svn commit --depth
immediates', depending on whether or not property changes on directories
matter.

-- Brane

Re: How to commit only top level files?

[Branko Čibej]

On 06.11.2018 21:19, Alfred von Campe wrote:
>
>> On Nov 6, 2018, at 15:11, Bo Berglund > > wrote:
>>
>> What should I use as argument so that only the changed files in the
>> current dir are committed?
>
> Will the -N [—non-recursive] option work for you?

The -N option is deprecated in favour of --depth, because it has
different meanings for different commands, whereas --depth always means
the same thing.

-- Brane

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

[Branko Čibej]

On 04.11.2018 20:11, Branko Čibej wrote:
> On 04.11.2018 18:57, Thorsten Schöning wrote:
>> Guten Tag Branko Čibej,
>> am Sonntag, 4. November 2018 um 17:47 schrieben Sie:
>>
>>> I'm not sure what you mean by "handles more than only DAV successfully"
>> I thought it might be possible that GitHub answers differently but
>> properly, because the other check mentioned something about HTTP v2.
>> Because of TLS, I was unable to look at the requests and responses
>> then, but it's like you said, they don't provide DAV-headers in their
>> response to OPTION.
>>
>>> And yes, the HTTP/DAV specification requires that header to be present
>>> in the response.
>> Which you didn't care about before and things worked for some years
>> for some users.
> We made this change because users complained about unhelpful error
> messages when they tried to connect to a server that did not even
> implement HTTP/DAV. The error message was "Malformed XML in response"
> which wasn't exactly helpful for diagnosing the problem.
>
> I admit I didn't have GitHub in mind when I added this check. ...

I added a test case to our suite that tries the following command:

svn info https://github.com/apache/subversion/trunk


It runs on one of our build slaves, so we'll know fairly soon when (if)
GitHub deploys a fix. And, of course, we'll also know if this feature
breaks again in future.

http://svn.apache.org/r1845942

-- Brane

Re: Error E145001

[Branko Čibej]

On 06.11.2018 13:29, xxsa...@seznam.cz wrote:
> Hello,
> I am trying to remove symbolic link that is currently under version control 
> but with keeping it in the file system. I try to do it like this:
> svn delete --keep-local xyz
>
> When now trying to commit this change, I get following error:
> svn: E145001: Commit failed (details follow):
> svn: E145001: Entry 'xyz' has unexpectedly changed special status
>
> svn --version
> svn, version 1.7.14 (r1542130)
>
> Is this a bug or just wrong approach?

It's a bug in a version of Subversion that's far too old. You really
should upgrade if you can; 1.7.x and 1.8.x are no longer supported.

It works with 1.11:

$ svnadmin create repo
$ svn co file://$(pwd)/repo wc
Checked out revision 0.
$ ln -s foo wc/bar
$ svn add wc/bar
A wc/bar
$ svn ci -mm wc
Adding wc/bar
Transmitting file data .done
Committing transaction...
Committed revision 1.
$ svn rm --keep-local wc/bar 
D wc/bar
$ svn ci -mm wc
Deleting   wc/bar
Committing transaction...
Committed revision 2.
$ svn st wc
?   wc/bar
$ ls -l wc
total 0
lrwxr-xr-x  1 brane  staff  3  6 Nov 15:36 bar -> foo



-- Brane

Re: subversion 1.11.0 on FreeBSD 11.2: ... does not support the HTTP/DAV protocol

[Branko Čibej]

On 06.11.2018 10:20, Dr. Rolf Jansen wrote:
> For a DAV noob, this error message is IMHO indeed not very helpful. You need 
> to know that DAV is heavily based on XML. However, I have my doubts, that the 
> other message „does not support the HTTP/DAV protocol“ is much more helpful 
> to a SVN noob, because you need to know that in the given respect SVN is 
> utilizing the DAV protocol. So far to the term non-solution.

That's not quite the case. Certainly the error message could be
better/different, but point is to have one specific enough that it's
easy to find the cause; it took less than 5 minutes in the reported
case. Ease of maintenance and issue triage are important.

> Complex, because this was not achieved by simply rephrasing the misleading 
> error message,

It's not easily rephrased because it's a valid error. The server could
be attempting to respond correctly to a DAV request but for some reason
messing up the XML in the response, or it could not be sending a DAV
response at all. In order to tell the difference, one must first know if
we're parsing a DAV response. There are two ways to do this: the simple
one is to look for the mandatory DAV: header; the complex and
error-prone one is to see if the response looks vaguely like the XML one
might expect.

>  but by adding another obstacle into the connection protocol and throwing a 
> new message if somebody stumbles across.

I'm a bit amused by this talk of obstacles ... we're talking about a
well-defined protocol here, and yet you complain to the volunteers on
this project for implementing it, rather than to the paid staff at
GitHub for not implementing it. Oh the irony.

> Now in regards to the term non-problem. Misspelling of URL’s may happen to 
> everybody, not only to noobs, and yes, I saw this „Malformed XML in 
> response,“ in the past, I corrected the URL, pronto.

Again, good for you. Many of our users did not assume that the URL is
wrong but that there's something wrong with either the client or the
server ...

> Said all this, I would have simply amended this error message by a hint. „... 
> check the URL is pointing to a SVN repository!“.

... and this hint implies that only the URL could be wrong, so it's
misleading.

-- Brane

Re: subversion 1.11.0 on FreeBSD 11.2: ... does not support the HTTP/DAV protocol

[Branko Čibej]

On 06.11.2018 00:28, Dr. Rolf Jansen wrote:
>> Am 05.11.2018 um 20:43 schrieb Stefan Sperling :
>>
>> On Mon, Nov 05, 2018 at 08:21:20PM -0200, Dr. Rolf Jansen wrote:
>>> and of course the GitHub server does support HTTP/DAV.

No it does not. It does not implement the most basic requirements of
that protocol, which would be to return a response header saying "DAV:
1". See https://www.ietf.org/rfc/rfc2518.txt section 15.1.


>>> # svn co https://github.com/cyclaero/ContentCGI.git/trunk ContentCGI
>>> svn: E170013: Unable to connect to a repository at URL 
>>> 'https://github.com/cyclaero/ContentCGI.git/trunk'
>>> svn: E175003: The server at 
>>> 'https://github.com/cyclaero/ContentCGI.git/trunk' does not support the 
>>> HTTP/DAV protocol
>> There is a problem at Github's end with SVN 1.11.
>>
>> See the thread titled "Problems accessing GitHub's SVN-bridge with SVN 1.11"
>> on this very mailing list: 
>> https://svn.haxx.se/users/archive-2018-11/0008.shtml
> In the meantime, I saw this thread.
>
>> There is a problem at Github’s end with SVN 1.11.
>
> Reading the whole thread, my impression is that there is another issue with 
> the Robustness Principle of software design on Subversion’s end. See: 
> https://en.wikipedia.org/wiki/Robustness_principle.

We're extremely liberal with that we accept, but it has to at least
marginally follow the protocol specification.

> I won’t hold on my breath, until the Subversion Developers and the GitHub 
> engineers sorted out their animosities. I put the patch shown below to 
> /usr/ports/devel/subversion/files/patch-zz-DAV-robustness.local on my FreeBSD 
> system, and then I reinstalled the port - problem solved. Happy discussions!

Good for you. If you ever get an error saying "Malformed XML in
response," please don't ask us to fix it.

-- Brane

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

[Branko Čibej]

On 05.11.2018 04:45, Ryan Schmidt wrote:
>
> On Nov 4, 2018, at 11:57, Thorsten Schöning wrote:
>
>> Now "we" need to get GitHub to change their
>> implementation and I didn't even get an automatic bot-reply to my
>> question on Friday yet. :-) Lets see how things are going after I send
>> them this thread...
> I'd be interested to know the resolution, since I use the GitHub svn bridge 
> daily. I'll hold off on upgrading past Subversion 1.10.x for now but could 
> you keep us informed about what GitHub does to solve this?
>
>
> Wasn't there going to be support in the Subversion client for dealing with 
> git repositories directly? Is that still in the works?


There's a branch that has very rudimentary support for read-only
checkouts from Git repositories. It hasn't been updated in a while. If
anyone would like to help with that, please do join us on our dev@ list.

-- Brane

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

[Branko Čibej]

On 04.11.2018 18:57, Thorsten Schöning wrote:
> Guten Tag Branko Čibej,
> am Sonntag, 4. November 2018 um 17:47 schrieben Sie:
>
>> I'm not sure what you mean by "handles more than only DAV successfully"
> I thought it might be possible that GitHub answers differently but
> properly, because the other check mentioned something about HTTP v2.
> Because of TLS, I was unable to look at the requests and responses
> then, but it's like you said, they don't provide DAV-headers in their
> response to OPTION.
>
>> And yes, the HTTP/DAV specification requires that header to be present
>> in the response.
> Which you didn't care about before and things worked for some years
> for some users.

We made this change because users complained about unhelpful error
messages when they tried to connect to a server that did not even
implement HTTP/DAV. The error message was "Malformed XML in response"
which wasn't exactly helpful for diagnosing the problem.

I admit I didn't have GitHub in mind when I added this check. ...


> Now "we" need to get GitHub to change their
> implementation and I didn't even get an automatic bot-reply to my
> question on Friday yet. :-) Lets see how things are going after I send
> them this thread...

I keep wondering why the GitHub staff didn't contact us when they
implemented their SVN-like server. This might all have been avoided if
they had. We already spent time trying to work around GitHub's faulty
implementation (q.v. r1707164), but there's a limit to how much we can
or should do. The protocols in question are quite well documented after
all, both in RFCs and in our own notes.


-- Brane

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

[Branko Čibej]

On 04.11.2018 17:41, Branko Čibej wrote:
> On 04.11.2018 16:05, Thorsten Schöning wrote:
>> Hi all,
>>
>> GitHub documents to support Subversion clients and I'm using that for
>> many projects to include them in one of my working copies using
>> svn:externals. Since upgrading TortoiseSVN from 1.10 to 1.11 I get the
>> following error for all of those projects:
>>
>>> The server at '[...]' does not support the HTTP/DAV protocol.
>> This happens to a long list of projects, some examples:
>>
>>> https://github.com/apache/commons-lang.git/tags/LANG_3_6
>>> https://github.com/pgjdbc/pgjdbc.git/tags/REL42.2.2
>>> https://github.com/ams-tschoening/kaitai_struct_tests.git/branches/libs_java_3rd_usage
> The first two URLs return a 404. The third returns 410 and says "feature
> gone" ... I think you'll need better examples.

Sorry, that's incorrect, I wrote that before I fixed my svnoptions.sh
script. Please ignore.

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

[Branko Čibej]

On 04.11.2018 17:47, Branko Čibej wrote:
> On 04.11.2018 17:06, Thorsten Schöning wrote:
>> Guten Tag Thorsten Schöning,
>> am Sonntag, 4. November 2018 um 16:42 schrieben Sie:
>>
>>> Others have the same problem and while it is true that GitHub might
>>> have implemented something on their own, it might help to have a look
>>> at the changes between 1.10 and 1.11 regarding the protocol.
>> Guess I found it:
>>
>>>* Better error when http:// URL is not a Subversion repository (r1825302)
>>>   /* Bail out early if we're not talking to a DAV server.
>>>  Note that this check is only valid if we've received a success
>>>  response; redirects and errors don't count. */
>>>   if (opt_ctx->handler->sline.code >= 200
>>>   && opt_ctx->handler->sline.code < 300
>>>   && !opt_ctx->received_dav_header)
>>> {
>>>   return svn_error_createf
>>> (SVN_ERR_RA_DAV_OPTIONS_REQ_FAILED, NULL,
>>>  _("The server at '%s' does not support the HTTP/DAV protocol"),
>>>  session->session_url_str);
>>> }
>> "received_dav_header" is only set at one place, isn't that check
>> wrong? The code handles more than only DAV successfully from my point
>> of view:
>
> I'm not sure what you mean by "handles more than only DAV successfully"
> ... this code only checks if we received any DAV: header in the response
> to the OPTIONS request, no more and no less. HTTP/DAV and Subversion's
> HTTP protocol use that for capability negotiation at the start of a session.
>
> And yes, the HTTP/DAV specification requires that header to be present
> in the response.

FWIW, the fix could be as simple as GitHub's server returning something like

    DAV: http://github.com/fake-svn-server


in their response headers ...

-- Brane

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

[Branko Čibej]

On 04.11.2018 17:06, Thorsten Schöning wrote:
> Guten Tag Thorsten Schöning,
> am Sonntag, 4. November 2018 um 16:42 schrieben Sie:
>
>> Others have the same problem and while it is true that GitHub might
>> have implemented something on their own, it might help to have a look
>> at the changes between 1.10 and 1.11 regarding the protocol.
> Guess I found it:
>
>>* Better error when http:// URL is not a Subversion repository (r1825302)
>>   /* Bail out early if we're not talking to a DAV server.
>>  Note that this check is only valid if we've received a success
>>  response; redirects and errors don't count. */
>>   if (opt_ctx->handler->sline.code >= 200
>>   && opt_ctx->handler->sline.code < 300
>>   && !opt_ctx->received_dav_header)
>> {
>>   return svn_error_createf
>> (SVN_ERR_RA_DAV_OPTIONS_REQ_FAILED, NULL,
>>  _("The server at '%s' does not support the HTTP/DAV protocol"),
>>  session->session_url_str);
>> }
> "received_dav_header" is only set at one place, isn't that check
> wrong? The code handles more than only DAV successfully from my point
> of view:


I'm not sure what you mean by "handles more than only DAV successfully"
... this code only checks if we received any DAV: header in the response
to the OPTIONS request, no more and no less. HTTP/DAV and Subversion's
HTTP protocol use that for capability negotiation at the start of a session.

And yes, the HTTP/DAV specification requires that header to be present
in the response.

-- Brane

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

[Branko Čibej]

On 04.11.2018 16:05, Thorsten Schöning wrote:
> Hi all,
>
> GitHub documents to support Subversion clients and I'm using that for
> many projects to include them in one of my working copies using
> svn:externals. Since upgrading TortoiseSVN from 1.10 to 1.11 I get the
> following error for all of those projects:
>
>> The server at '[...]' does not support the HTTP/DAV protocol.
> This happens to a long list of projects, some examples:
>
>> https://github.com/apache/commons-lang.git/tags/LANG_3_6
>> https://github.com/pgjdbc/pgjdbc.git/tags/REL42.2.2
>> https://github.com/ams-tschoening/kaitai_struct_tests.git/branches/libs_java_3rd_usage

The first two URLs return a 404. The third returns 410 and says "feature
gone" ... I think you'll need better examples.


> I've asked about that problem on SO[1], which revealed that the switch
> from 1.10 to 1.11 really is the problem. Downgrading resolves the
> problem.
>
> Do you have any idea what could be the root cause? Is there something
> that needs to be configured specially?

The root cause is that GitHub does not implement Subversion's HTTP/DAV
protocol correctly.

In 1.11, the Subversion client has become stricter about the server
requirements (see: https://svn.apache.org/r1825302). Specifically, we
require that the server sends DAV response headers to the OPTIONS
request, which we use for capability negotiation. Here's an example of a
correct response:

HTTP/1.1 200 OK
Date: Sun, 04 Nov 2018 15:40:24 GMT
Server: Apache/2.4.7 (Ubuntu)
DAV: 1,2
DAV: version-control,checkout,working-resource
DAV: merge,baseline,activity,version-controlled-collection
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
...


The GitHub server does not return any DAV: header for the OPTIONS
request, so the response is considered incorrect. I suggest sending a
bug report to GitHub; the attached script can be used to simulate
Subversion's OPTIONS request.

In the meantime, staying with 1.10.x appears to be the only option if
you have to use GitHub's SVN protocol.

-- Brane

#!/bin/bash

if [ -z "$1" ]; then
echo "Usage: $0 " >&2
exit 2
fi

HOST=$(echo "$1" | sed -e 's%^https*://\([^/]*\).*$%\1%')

set -x
curl -i -X OPTIONS \
 -H "Host: $HOST" \
 -H 'User-Agent: SVN/1.11.0' \
 -H 'Content-Type: text/xml' \
 -H 'DAV: http://subversion.tigris.org/xmlns/dav/svn/depth' \
 -H 'DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo' \
 -H 'DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops' \
 --data-raw ''
 \
 "$1"

Re: Symlinks on Windows

[Branko Čibej]

On 02.11.2018 11:07, Albertsen, Ketil wrote:
>
> So where did this idea about “… working copies on systems such as
> Windows that do not support symlinks” come from?
>

It comes from a time when Windows did not support symlinks. However ...

> NTFS supports symlinks, and has supported it for many years.
>

... it's not so simple. Even though NTFS supports symlinks, there are
two problems:

  * Symlinks to files and symlinks to directories are different on
Windows, whereas Unix doesn't care. Obviously Subversion doesn't
know what the target of the symlink is supposed to be.
  * You need special permissions to create a symlink. You either have to
be in Administrator mode, or — if the code is written differently —
have the Development Mode turned on. The vast majority of users
aren't able to create them.


And, of course, NTFS is not the only filesystem people can use,
Subversion would have to decide on a case-by-case basis if the
filesystem where the working copy is stored supports symbolic links.
This is, however, a minor problem compared to the other two.

> If my memory is correct, it wasn’t avialable in the CLI interface,
> cmd.exe, utntil long after the file system API provided it – but now
> we are talking history!
>


For the reasons mentioned above, supporting symbolic links on Windows is
a much more complex problem than you think. Even if we somehow solved
the file/directory link problem, adding a feature that requires special
permissions to use is a non-starter.


-- Brane

> *From:* Pavel Lyalyakin 
> *Sent:* 1 November, 2018 17:49
> *To:* Bengt Nilsson 
> *Cc:* users@subversion.apache.org
> *Subject:* Re: Symlinks on Windows
>
>  
>
> Hello,
>
>  
>
> On Thu, Nov 1, 2018 at 6:39 PM, Bengt Nilsson
>  > wrote:
>
> Hi!
>
> We have a SVN-server running on Windows and there we get problem
> with symlinks.
>
> If we put up a SVN-server on a Linux-server would that work better
> with the symlinks although  the clients (TortoiseSVN) are on Windows?
>
> Or do we have to have clients on Linux as well?
>
>  
>
> Please, see SVNBook | Versioning Symbolic Links
>  (scroll down
> to the "Versioning Symbolic Links" section). Is this what you are
> asking about?
>
>  
>
> If the answer is "yes", then the platform where the SVN server runs
> does not matter. You need the clients to be on Linux, but the server
> can be on Windows.
>
>  
>
> -- 
>
> With best regards,
> Pavel Lyalyakin
> VisualSVN Team
>

Re: Symlinks on Windows

[Branko Čibej]

On 01.11.2018 16:39, Bengt Nilsson wrote:
>
> Hi!
>
> We have a SVN-server running on Windows and there we get problem with
> symlinks.
>

What problem? The server should work just fine on Windows and it doesn't
use symlinks for anything.

> If we put up a SVN-server on a Linux-server would that work better
> with the symlinks although  the clients (TortoiseSVN) are on Windows?
>
> Or do we have to have clients on Linux as well?
>

I don't know, you haven't described what you're trying to do.

-- Brane

Re: Coredump when javahl SVNClient::diff() called with diff-cmd set

[Branko Čibej]

On 29.10.2018 10:20, matthew.b...@nats.co.uk wrote:
>
> On 2018/10/25 11:18:51, Branko Čibej  wrote: 
>> On 25.10.2018 12:41, BURT, Matthew J wrote:
>>> Hi,
>>>
>>>  
>>>
>>> We’ve got a number of developers using the javahl bindings from Eclipse
>>>
>>> via subclipse.
>>>
>>>  
>>>
>>> One of them recently reported a coredump against 1.10.3. I’ve also
>>>
>>> reproduced it with 1.9.7.
>>>
>>>  
>>>
>>> The problem occurs when SVNClient::diff() is called with a diff-cmd
>>>
>>> defined in the user’s ~/.subversion/config file.
>>>
>>>  
>>>
>>> SVNClient::diff() calls svn_client_diff6() with the errstream explicitly
>>>
>>> set to NULL and the diff command in dwi->diff_cmd.
>>>
>>>  
>>>
>>> Further down in the code, if diff_content_changed() from
>>>
>>> subversion/libsvn_client/diff.c is called, the NULL errstream is
>>>
>>> de-referenced with a call to svn_stream__aprfile().
>>>
>>>  
>>>
>>> I’ve put together a simple patch to avoid the null dereference, but I’m
>>>
>>> not 100% sure this is the correct solution. The code suggests to me that
>>>
>>> the intention is to allow the errstream parameter for svn_client_diff6()
>>>
>>> to be set to NULL, but maybe I’m misreading it.
>>>
>>>  
>>>
>>> Is this the correct approach, and should I submit this patch for
>>>
>>> consideration?
>>>
>> The docstring for svn_client_diff7 (..._diff6 was deprecated on trunk)
>> doesn't say that outstream or errstream may be NULL; that's pretty
>> definitive. This should be fixed in the native JavaHL code; either an
>> actual stream should be used such that JavaHL users can read it (in this
>> case I suspect that the JavaHL API would have to be upgraded), or a
>> stream that ignores all writes should be used.
>>
>> -- Brane
>>
>>
> OK - that's clear.
>
> I've replaced both NULL values in the JavaHL code with an svn_stream_empty in 
> the pool that's in-scope for the call. We've re-tested with Eclipse/subclipse 
> and it seems to have solved the crash we're seeing. This is on 1.10.3.
>
> I can submit a patch for trunk if you like, but I note that JavaHL on trunk 
> is still using ..._diff6.

Please do submit a patch against trunk. That JavaHL has not been updated
to ..._diff7 is not your problem. :)

-- Brane

Re: svnpubsub/client.py: RuntimeError: dictionary changed size during iteration

[Branko Čibej]

On 23.08.2018 14:54, sebb wrote:
> When running a version of watcher.py I got the following error:
>
>   File ".../svnpubsub/client.py", line 251, in run_forever
> self._check_stale()
>   File ".../svnpubsub/client.py", line 216, in _check_stale
> for client in asyncore.socket_map.values():
> RuntimeError: dictionary changed size during iteration
>
> Is this a known issue?

It is now, since you created #4770 ... :)

Can you try this patch:

Index: client.py
===
--- client.py   (revision 1844264)
+++ client.py   (working copy)
@@ -213,17 +213,19 @@ class MultiClient(object):
 
   def _check_stale(self):
 now = time.time()
+stale = []
 for client in asyncore.socket_map.values():
   if client.last_activity + STALE_DELAY < now:
-# Whoops. No activity in a while. Signal this fact, Close the
-# Client, then have it reconnected later on.
+# Whoops. No activity in a while. Signal this fact.
 self.event_callback(client.url, 'stale', client.last_activity)
+stale.append(client)
 
-# This should remove it from .socket_map.
-client.close()
+# Close stale clients, then have them reconnected later on.
+for client in stale:
+  # This should remove it from .socket_map.
+  client.close()
+  self._reconnect_later(client.url)
 
-self._reconnect_later(client.url)
-
   def _maybe_work(self):
 # If we haven't reach the targetted time, or have no work to do,
 # then fast-path exit






-- Brane

Re: svn copy WC to URL asserts

[Branko Čibej]

On 27.10.2018 18:07, Branko Čibej wrote:
> On 15.08.2018 16:14, Jens Geyer wrote:
>>
>> Hi,
>>
>>  
>>
>> We have one case of a misbehaving branch here. Our CI server creates
>> a tag at the end of a build using a svn copy command:
>>
>>
>> {code}
>>
>> svn.exe copy -m "Devtest" D:\Builds\Release_5.1.1.x\Source
>> svn://repo.server/tags/buildserver/Release_5.1.1.x/Build513
>>
>> {code}
>>
>>  
>>
>> The message printed is this.
>>
>>
>> {code}
>>
>> svn: E235000: In file
>> 'D:\Development\SVN\Releases\TortoiseSVN-1.10.1ext\subversion\subversion\libsvn_client\copy.c'
>> line 2109: assertion failed (commit_items != NULL)
>>
>> {code}
>>
>>  
>>
>>
>> The problem so far manifests only with this particular branch. We
>> double-checked everything, beginning with paths and URLs up to access
>> permisions and everything. We also installed the latest SVN version,
>> and as the only result the assertion line number changed.
>>
>> The WC has no changes, but a bunch of externals.
>>
>>  
>>
>>  
>>
>> Any advice where to look for or what to check would be appreciated.
>> If I can provide information to help fixing the issue, please let me
>> know and I will be happy to supply whatever informatiomn you may need
>> (except that I am certainly not going to upload the repo nor the
>> complete source code).
>>
>
>
> [Note, this is issue #4769, which the OP already created. In future,
> please read the big yellow box at
> https://subversion.apache.org/reporting-issues.html ]
>
> Can you please do the following:
>
> svn.exe info --show-item=repos-root-url D:\Builds\Release_5.1.1.x\Source
>
> then check if the printed URL matches the target URL of the copy? That
> assertion implies that you're trying to copy to a different repository
> than the working copy was checked out from.

Or of course you could try:

svn.exe copy --ignore-externals ...


since copying the externals contents may well be the cause of the
problem if the externals point to different repositories. Since you're
creating a "tag" you may want to use the --pin-externals flag, too,
unless your externals references are already pinned.

-- Brane

Re: svn copy WC to URL asserts

[Branko Čibej]

On 15.08.2018 16:14, Jens Geyer wrote:
>
> Hi,
>
>  
>
> We have one case of a misbehaving branch here. Our CI server creates a
> tag at the end of a build using a svn copy command:
>
>
> {code}
>
> svn.exe copy -m "Devtest" D:\Builds\Release_5.1.1.x\Source
> svn://repo.server/tags/buildserver/Release_5.1.1.x/Build513
>
> {code}
>
>  
>
> The message printed is this.
>
>
> {code}
>
> svn: E235000: In file
> 'D:\Development\SVN\Releases\TortoiseSVN-1.10.1ext\subversion\subversion\libsvn_client\copy.c'
> line 2109: assertion failed (commit_items != NULL)
>
> {code}
>
>  
>
>
> The problem so far manifests only with this particular branch. We
> double-checked everything, beginning with paths and URLs up to access
> permisions and everything. We also installed the latest SVN version,
> and as the only result the assertion line number changed.
>
> The WC has no changes, but a bunch of externals.
>
>  
>
>  
>
> Any advice where to look for or what to check would be appreciated. If
> I can provide information to help fixing the issue, please let me know
> and I will be happy to supply whatever informatiomn you may need
> (except that I am certainly not going to upload the repo nor the
> complete source code).
>


[Note, this is issue #4769, which the OP already created. In future,
please read the big yellow box at
https://subversion.apache.org/reporting-issues.html ]

Can you please do the following:

svn.exe info --show-item=repos-root-url D:\Builds\Release_5.1.1.x\Source


then check if the printed URL matches the target URL of the copy? That
assertion implies that you're trying to copy to a different repository
than the working copy was checked out from.

-- Brane

Re: Coredump when javahl SVNClient::diff() called with diff-cmd set

[Branko Čibej]

On 25.10.2018 12:41, BURT, Matthew J wrote:
>
> Hi,
>
>  
>
> We’ve got a number of developers using the javahl bindings from Eclipse
>
> via subclipse.
>
>  
>
> One of them recently reported a coredump against 1.10.3. I’ve also
>
> reproduced it with 1.9.7.
>
>  
>
> The problem occurs when SVNClient::diff() is called with a diff-cmd
>
> defined in the user’s ~/.subversion/config file.
>
>  
>
> SVNClient::diff() calls svn_client_diff6() with the errstream explicitly
>
> set to NULL and the diff command in dwi->diff_cmd.
>
>  
>
> Further down in the code, if diff_content_changed() from
>
> subversion/libsvn_client/diff.c is called, the NULL errstream is
>
> de-referenced with a call to svn_stream__aprfile().
>
>  
>
> I’ve put together a simple patch to avoid the null dereference, but I’m
>
> not 100% sure this is the correct solution. The code suggests to me that
>
> the intention is to allow the errstream parameter for svn_client_diff6()
>
> to be set to NULL, but maybe I’m misreading it.
>
>  
>
> Is this the correct approach, and should I submit this patch for
>
> consideration?
>

The docstring for svn_client_diff7 (..._diff6 was deprecated on trunk)
doesn't say that outstream or errstream may be NULL; that's pretty
definitive. This should be fixed in the native JavaHL code; either an
actual stream should be used such that JavaHL users can read it (in this
case I suspect that the JavaHL API would have to be upgraded), or a
stream that ignores all writes should be used.

-- Brane

Re: ViewVC of Subversion Forbidden

[Branko Čibej]

On 18.10.2018 14:19, wuzhouhui wrote:
> Hi,
> When I click
> Apache's ViewVC instance 
> in https://subversion.apache.org/source-code.html, the server told me
> I have no permission to access /viewvc/subversion/trunk:
>
>
>   Forbidden
>
> You don't have permission to access /viewvc/subversion/trunk/ on this
> server.
>


It works just fine for me.

-- Brane

.oO(Is the name "Subversion" triggering a rule in the Great Firewall?)

Re: Subversion 1.10.2 Checksum (SHA512)

[Branko Čibej]

On 22.09.2018 17:26, Daniel Shahaf wrote:
> Branko Čibej wrote on Sat, 22 Sep 2018 16:54 +0200:
>> Ah, that would be this one:
>>
>> https://www.apache.org/dyn/closer.cgi?path=subversion/subversion-1.10.2.tar.bz2
> That still gives me an HTML page, whether I pass the relpath as a query
> parameter (as you have) or as PATH_INFO.

Huh. That must be new? Because I distinctly remember using it to
download our tarballs from mirrors with curl.

Homebrew on Mac relies on URLs of this format to download all Apache
sources, too.

-- Brane

Re: Subversion 1.10.2 Checksum (SHA512)

[Branko Čibej]

On 22.09.2018 16:26, Daniel Shahaf wrote:
> Branko Čibej wrote on Sat, 22 Sep 2018 16:22 +0200:
>> On 22.09.2018 16:13, Daniel Shahaf wrote:
>>> Please don't download the artifacts from www*.apache.org but from a
>>> mirror.  I think there is a redirector CGI somewhere that automatically
>>> redirects you to a mirror close to you, but I can't find it :(
>> http://subversion.apache.org/download.cgi
>>
>> Linked from our main page.
> I meant, a CGI that just gives a 302 redirect to the mirror.  Not one
> that generates an HTML page that a shell script would need to parse.
>
> The actual CGI lives here: 
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/dyn/

Ah, that would be this one:

https://www.apache.org/dyn/closer.cgi?path=subversion/subversion-1.10.2.tar.bz2

-- Brane

Re: Subversion 1.10.2 Checksum (SHA512)

[Branko Čibej]

On 22.09.2018 16:13, Daniel Shahaf wrote:
> Please don't download the artifacts from www*.apache.org but from a
> mirror.  I think there is a redirector CGI somewhere that automatically
> redirects you to a mirror close to you, but I can't find it :(

http://subversion.apache.org/download.cgi

Linked from our main page.

-- Brane

Re: Inconsistencies/bugs in peg revision parsing and help description

[Branko Čibej]

On 09.09.2018 14:20, Mark Phippard wrote:
> On Sep 9, 2018, at 8:15 AM, Michael Osipov  wrote:
>> Am 2018-09-09 um 13:50 schrieb Mark Phippard:
>> Any thoughts?
> If I understand your examples, you are showing what happens when the 
> filename contains an @, right?  If so, this is addressed in the book in 
> this paragraph:
 Correct.

> "The perceptive reader is probably wondering at this point whether the 
> peg revision syntax causes problems for working copy paths or URLs that 
> actually have at signs in them. After all, how does svn know whether 
> news@11 is the name of a directory in my tree or just a syntax for 
> “revision 11 of news”? Thankfully, while svn will always assume the 
> latter, there is a trivial workaround. You need only append an at sign to 
> the end of the path, such as news@11@. svn cares only about the last at 
> sign in the argument, and it is not considered illegal to omit a literal 
> peg revision specifier after that at sign. This workaround even applies 
> to paths that end in an at sign—you would use filename@@ to talk about a 
> file namedfilename@."
 Hi Mark,

 I am aware of that paragraph and this is what I did actually: 
 https://github.com/apache/maven-scm/commit/c1f4f0fe1e0fafb876e098d8ecc17745664396ed

 It is still not clear why mkdir or export are subject to PEG parsing where 
 it makes no sense at all, imho.
>>> My guess is that there is just one parser used in the code base, but do not 
>>> know.  I do tend to agree that it seems to not make sense.  It is something 
>>> that may have been discussed before and maybe someone had a logic behind 
>>> just being consistent everywhere?
>> The common parser was the first idea which came into my mind too.
> After sending my last reply, it occurred to me that if there were not a 
> common parser and a consistent set of rules then it would make your "simple 
> workaround" a lot more difficult to use.  You would have to be aware on a 
> command by command basis what the rules were and when you need to add an @ 
> and when you had to not do that.  I would not be surprised if that sort of 
> discussion happened back when this feature was added ... which was many years 
> ago now.

Indeed. The interpretation of paths and URLs in the command-line must be
consistent, regardless of the command context. That makes the code
simpler, but more importantly, it makes it easier to educate users. (Or
at least, ideally it would make it easier ...).

Adding exceptions here just because parsing peg revisions appears
redundant in some places is definitely not the way we want to go.


>> Do you think it is worthwhile to file some issues about the incorrect help 
>> output?
> I would recommend posting here on what the specific changes are that you 
> think ought to be made.  I did not understand from your original post what 
> you were suggesting was incorrect.  Having the command transcripts was nice 
> but you did not really highlight where you thought there were problems.

And a hint: use the bindings if you want to be explicit about peg
revisions. The @ in paths is only special in the command-line client,
not in the underlying APIs.

-- Brane

Re: Wildcard bug? Or user error?

[Branko Čibej]

On 06.09.2018 16:22, Nathan Hartman wrote:
> On Mon, Sep 3, 2018 at 6:31 PM Branko Čibej  <mailto:br...@apache.org>> wrote:
>
> These cases are, believe it or not, completely different. On your Mac,
> the shell expands the wildcards. On Windows, Subversion is linked
> with a
> library that's shipped with Visual Studio (setargv.obj) that
> expands the
> wildcards in the arguments. It looks like something strange is
> happening
> during that wildcard expansion.
>
> It would be best to report this to whoever built the Subversion
> binaries; it might be that their setargv.obj is corrupt somehow.
>
> In any case, there's no code in Subversion proper for expanding
> wildcards in the command-line arguments.
>
>
> Just to keep this list in the loop, in case someone else stumbles
> upon this, Stefan of Tortoise fame has confirmed your suspicion:
> There is a bug in the (at this time) latest Windows SDK, version
> 10.0.17134.0, that causes the first matching filename to be
> truncated to one character.
>
> An upcoming Windows Update is supposed to fix it.
>
> Here is the link Stefan provided:
>
> https://developercommunity.visualstudio.com/content/problem/289637/setargvobj-is-broken-in-the-latest-windows-sdk.html

"Nice." Especially since, to fix the problem, they'll have to rebuild
the Subversion binaries.

-- Brane

Re: Wildcard bug? Or user error?

[Branko Čibej]

On 03.09.2018 22:30, Nathan Hartman wrote:
> On Mon, Sep 3, 2018 at 11:10 AM Johan Corveleyn  wrote:
>
>> On Sun, Sep 2, 2018 at 11:10 PM Nathan Hartman 
>> wrote:
>>> I've encountered weirdness with wildcards several times today, so I
>>> just tried in a clean freshly checked-out copy:
>>>
>>> E:\workspace\processor>svn rm *.hconfig
>>> svn: E25: Use --force to override this restriction (local
>> modifications may be lost)
>>> svn: E25: 'E:\workspace\processor\a' is not under version control
>
> (snip)
>
>
>> My first reaction is that this might be unrelated to svn, but merely
>> to Windows (or some Windows library). I wouldn't know what, but to
>> rule out that svn has anything to do with it, try something like 'dir
>> *.hconfig' in that directory.
>
> Thank you for your reply.
>
> This behavior appears consistent everywhere. For example (I am
> working in a different directory now):
> E:\workspace\BSP>dir *.h
>  Volume in drive E is WORK
>  Volume Serial Number is D28A-433E
>
>  Directory of E:\workspace\BSP
>
> 09/03/2018  04:12 PM   828 BSP-Global.h
> 09/03/2018  04:12 PM   568 BSP-Main.h
> 09/03/2018  04:12 PM   632 DigitalInputs.h
> 09/03/2018  04:12 PM 8,528 DigitalInputsAutoGen.h
> 09/03/2018  04:12 PM   731 DigitalOutputs.h
> 09/03/2018  04:12 PM10,073 DigitalOutputsAutoGen.h
> 09/03/2018  04:12 PM   502 DmaChannels.h
>7 File(s) 21,862 bytes
>0 Dir(s) 250,642,432 bytes free
>
> Okay... Now:
>
> E:\workspace\BSP>svn rm *.h
> svn: E25: Use --force to override this restriction (local modifications
> may be lost)
> svn: E25: 'E:\workspace\BSP\B' is not under version control
>
> Like before, it seems to find only the first letter of the filename.
>
> Now if I go over to my Mac...
>
> $ ls -1 *.h
> BSP-Global.h
> BSP-Main.h
> DigitalInputs.h
> DigitalInputsAutoGen.h
> DigitalOutputs.h
> DigitalOutputsAutoGen.h
> DmaChannels.h
>
> $ svn rm *.h
> D BSP-Global.h
> D BSP-Main.h
> D DigitalInputs.h
> D DigitalInputsAutoGen.h
> D DigitalOutputs.h
> D DigitalOutputsAutoGen.h
> D DmaChannels.h
>
> Caveat: My Mac is running svn 1.8.19; the misbehaving Windows machine
> is running 1.10.2.
>
> Any other thoughts?


These cases are, believe it or not, completely different. On your Mac,
the shell expands the wildcards. On Windows, Subversion is linked with a
library that's shipped with Visual Studio (setargv.obj) that expands the
wildcards in the arguments. It looks like something strange is happening
during that wildcard expansion.

It would be best to report this to whoever built the Subversion
binaries; it might be that their setargv.obj is corrupt somehow.

In any case, there's no code in Subversion proper for expanding
wildcards in the command-line arguments.

-- Brane

Re: Error connecting to svn.apache.org

[Branko Čibej]

On 02.09.2018 21:22, Paul Hammant wrote:
> I'd already tried something similar, but will paste in the result:
>
>   $ svn log http://209.188.14.144/repos/asf/synapse/trunk/
>   Redirecting to URL 'https://dist.apache.org/repos/asf/synapse/trunk':
>   svn: E170013: Unable to connect to a repository at URL
> 'https://dist.apache.org/repos/asf/synapse/trunk'
>   svn: E175009: The XML response contains invalid XML
>   svn: E130003: Malformed XML: no element found at line 1
>
> ^ That as an attempt to force IPv4

This does not so much force IPv4 as it breaks name-based virtual hosts
on the server ... which is obvious from the bogus redirect.


-- Brane

Re: Error connecting to svn.apache.org

[Branko Čibej]

On 02.09.2018 21:04, Paul Hammant wrote:
> For svn 1.10.2, when I do:
>
>     $ svn log http://svn.apache.org/repos/asf/synapse/trunk
>
> it results in:
>
>     svn: E170013: Unable to connect to a repository at URL
> 'http://svn.apache.org/repos/asf/synapse/trunk'
>     svn: E120108: Error running context: The server unexpectedly
> closed the connection.
>
> I've tried over hotspot (T-Mobile USA), and wifi with the same reults
> (I was wondering if it was an IPv4 / IPv6 issues).
>
> However if I do:
>
>     $ svn log https://github.com/apache/synapse.git
>
> ... it works as expected. Github's Svn mirrors don't require the
> /trunk suffix for 'master' that's mapped to that.
>
> Does anyone have any ideas?


Nope ... All I can say is that it works for me.

FWIW:
$ host svn.apache.org
svn.apache.org has address 209.188.14.144


Could be different for you.

-- Brane

Re: Tree conflict resolution considered harmful

[Branko Čibej]

On 29.08.2018 12:54, Dag-Erling Smørgrav wrote:
> I'm using Subversion 1.10.2 to perform a non-interactive merge with
> around 15 tree conflicts (files that exist on the source branch but have
> been deleted from the target branch).  It spends exactly two hours on
> each conflict before the connection is killed and it gives up and moves
> on to the next.  Here's an excerpt from ktrace showing svn's attempt to
> resolve the first conflict:
>
>  33821 svn  35.021454 GIO   fd 1 wrote 20 bytes
>"\rChecking r338344..."
> --
>  33821 svn  40.898214 GIO   fd 1 wrote 20 bytes
>"\rChecking r338059..."
>  33821 svn  40.898328 GIO   fd 1 wrote 20 bytes
>"\rChecking r333678..."
>  33821 svn  40.898412 GIO   fd 1 wrote 20 bytes
>"\rChecking r333677..."
> --
>  33821 svn  40.900558 GIO   fd 1 wrote 20 bytes
>"\rChecking r333490..."
> --
>  33821 svn  77.091446 GIO   fd 1 wrote 20 bytes
>"\rChecking r89..."
> --
>  33821 svn  95.000296 GIO   fd 1 wrote 20 bytes
>"\rChecking r00..."
> --
>  33821 svn  95.001008 GIO   fd 1 wrote 20 bytes
>"\rChecking r326169..."
> --
>  33821 svn  671.067538 GIO   fd 1 wrote 20 bytes
>"\rChecking r322052..."
> --
>  33821 svn  671.337258 GIO   fd 1 wrote 20 bytes
>"\rChecking r321369..."
> --
>  33821 svn  7240.543297 GIO   fd 2 wrote 62 bytes
>"svn: warning: W210002: Network connection closed unexpectedly
>
> The third column is the time elapsed since the start of the process.
>
> The actual conflict is in r294466, which removed the file in question
> from the target branch.  The revision it's stuck on, r321369, only
> touched the svn:mergeinfo property on the current directory (propagated
> down from a merge higher up in the tree).
>
> Please add an option to disable conflict resolution entirely.

Would not one of the --accept option values work? E.g.,
`--accept=theirs-conflict', though that would also affect how the file
contents are merged.

-- Brane

Re: SVN checkout speed issue

[Branko Čibej]

On 31.07.2018 00:56, Art Hatch wrote:
> Hi Team!
>
> We think there may be a bug, or a feature we don't understand:
>
> When checking out a repository using TortoiseSVN on top of a Visual
> SVN Server v3.6, running on Windows Server 2012R2, we notice that
> files with a mime type set (usually application/octet-stream) download
> from the checkout MUCH FASTER. For a repo with lots of mime types set
> (mostly application/octet-stream, as mentioned), we see speeds around
> 1.5-3MByte/sec. For non-mime-typed files, it's capped at around
> 300kb/sec max. If some files come through with mime types in the
> slower-to-checkout-repo, the DL speed bursts up to 1.5-3MBytes/sec, as
> we see in the faster repo.
>
> This leads us to  believe that SVN's underlying checkout logic is
> running some mime type evaluation logic on files without mimetype set,
> and that the logic ran is extremely inefficient or slow by design.

Sorry, but you believe incorrectly. :)

> *1. is this a bug, or a feature by default?*

There's no clear answer to that. It may be related to some server
settings. It's definitely not by design.

> *2. can we disable the logic doing the mime type check for files
> without mime type data, to speed up checkouts?*

There's no such logic in the Subversion (but, see below). There may be
in the HTTP server, depending on how it's configured.

> *3. can we force SVN to see files without mime types set at text or
> binary, to stop the logic that tries to figure out a file's mime type
> programattically?*

As I said, there's no such code in Subversion.

Well, actually, there is; depending on how Subversion was compiled, it
may try to guess a file's MIME type at 'svn add' and set the
svn:mime-type property on the newly added file (in the working copy).
However, that code does not in any way affect checkouts.

> *4. Any other input or feedback to help us? :)*

If you're accessing the repository via http(s)://, I recommend you check
the Apache HTTPd server settings. It does have an option to try to guess
the MIME type of the file it's serving. However, I don't know if that
option is even available for files that come from a Subversion repository.

Also, overall transmission speed _may_ be related to file size; it's
possible that fewer large files will transfer more quickly than more
small files. Whether that's the case here is hard to see from your
measurements.

-- Brane

Re: Some files stay at an too new revision when updating the working copy to an old revision

[Branko Čibej]

On 20.07.2018 15:37, Franz Sirl wrote:
> Hi,
>
> this already happened a few times here, but now I managed to re-create
> it reliably.
> This happens at least on Linux with subversion-1.8/subversion-1.10 and
> on Windows
> with TortoiseSVN-1.9, didn't test older versions yet. Server is
> subversion-1.9.5
> on Linux, a "svnadmin verify" of a repository hotcopy showed no problems
>
> This slightly obfuscated transcript shows the problem:
>
> -->
> $ rm -rf myrepo.wc
> $ svn co https://svnserver/svn/myrepo/trunk/some/path/src myrepo.wc/
> ...
> Checked out revision 98863.
> $ svn status --verbose myrepo.wc/mysrc[34].c
>  98867    93474 user1    myrepo.wc/mysrc3.c
>  98867    87357 user2    myrepo.wc/mysrc4.c
> $ svn up -r 85950 myrepo.wc
> ...
> At revision 85950.
> $ svn status --verbose myrepo.wc/mysrc[34].c
>  85950    93474 user1    myrepo.wc/mysrc3.c
>  85950    83501 user3    myrepo.wc/mysrc4.c
> --<
>
> As you can see, mysrc3.c has a too high last_commit revision and also
> the content
> of the file is too new after the first downgrading with "svn up -r
> 85950 myrepo.wc".

This does look strange.

Is myrepo.wc/mysrc3.c a file external by any chance? Try:

$ svn propget svn:externals --show-inherited-props myrepo.wc

If it isn't could you show us an (obfuscated) log of that file?

$ svn log --verbose -r93474:85950 myrepo.wc/mysrc3.c

(the actual log messages are not important, only the list of changes to
the file)

-- Brane


>
> The following procedure fixes the problem:
>
> -->
> $ svn update -r85950 myrepo.wc/mysrc3.c
> Updating 'myrepo.wc/mysrc3.c':
> At revision 85950.
> $ svn status --verbose myrepo.wc/mysrc[34].c
>  85950    93474 user1    myrepo.wc/mysrc3.c
>  85950    83501 user3    myrepo.wc/mysrc4.c
> $ svn update -rPREV myrepo.wc/mysrc3.c
> Updating 'myrepo.wc/mysrc3.c':
> U    myrepo.wc/mysrc3.c
> Updated to revision 93473.
> $ svn status --verbose myrepo.wc/mysrc[34].c
>  93473    87225 user2    myrepo.wc/mysrc3.c
>  85950    83501 user3    myrepo.wc/mysrc4.c
> $ svn update -r85950 myrepo.wc/mysrc3.c
> Updating 'myrepo.wc/mysrc3.c':
> U    myrepo.wc/mysrc3.c
> Updated to revision 85950.
> $ svn status --verbose myrepo.wc/mysrc[34].c
>  85950    83501 user3    myrepo.wc/mysrc3.c
>  85950    83501 user3    myrepo.wc/mysrc4.c
> --<
>
> Is this a known problem? Could it be server-related? IOW, should I try
> to upgrade
> the server to 1.10?
>
> This is a simple oneliner to find affected files:
>
> $ svn status --verbose --ignore-externals myrepo.wc/ | gawk '{
> FIELDWIDTHS = "1 1 1 1 1 1 1 1 1 1 8 1 8 1 5000"; if ($13 > $11) print
> $11 " " $13 " " $15 }'
>
> Let me know if there is anything I should try or if you need more
> details.
>
> Franz
>
>

Re: Http authentication

[Branko Čibej]

On 18.07.2018 15:38, Essig Felix wrote:
>
> Hi,
>
>  
>
> I have a question about the http authentication when using the
> subversion api 1.8.13.
>
> For example using the ‚svn_client_list3‘ function:
>
> Everytime this function is called the first http request does not
> contain any Authorization header which leads to a ‚401 Authorization
> Required‘ response.
>
> In my opinion this leads to an unnecessary delay when the function is
> called multiple times and the same credentials could be used.
>
>  
>
> When calling this function the svn_client_ctx_t contains an
> svn_auth_baton_t with set default username and default password
> parameters.
>
>  
>
> Now to my actual question:
>
> Can this behaviour somehow be changed or is it just designed to work
> this way? I also know that the version I’m using is not the newest one
> so if you think an upgrade to a newer version could lead to some
> performance improvement please let me know.
>

You can either modify the auth baton or create your own. See
svn_cmdline_create_auth_baton2 in include/svn_cmdline.h and
subversion/libsvn_subr/cmdline.c.

-- Brane

Re: svn st without the X lines for externals?

[Branko Čibej]

On 29.06.2018 17:04, Julian Foad wrote:
> Nathan Hartman wrote: 
>> We make extensive use of externals, so "svn st" outputs many lines
>> beginning with X. Running "svn st --ignore-externals" gets rid of the
>> "Performing status on external item at" output, but not the "X" lines.
>> Is it possible to avoid those as well?
> I would consider supporting a proposal for "svn status" to be 
> improved/changed, if you'd like to make such a proposal.

Interestingly enough, 'svn status --quiet' already does this, it's just
not very explicitly mentioned in the help text.

-- Brane

Re: svn 1.10: mod_authz no longer combines ACL entries

[Branko Čibej]

On 04.07.2018 13:25, Michael Ruder wrote:
> Hi,
>
> we used up to and including svn 1.9 an authz file of the format
>
> [groups]
> company = user1, user2, user3
> customer = customer1, customer2
>
> # company can read-write on everything
> [/]
> @company = rw
>
> [project1:/]
> @customer = r
>
> [project2:/]
>
> This gave company full rights on both project1 and project2 and
> customer reading rights on project1. Now, with svn 1.10, company
> cannot access anything (customer can still read project 1). So
> apparently, only the ACLs in the most specific matching block are used
> and parent ACLs not at all.
>
> Even like this, within a single repository, this is the case:
>
> [project1:/]
> @company = rw
>
> [project1:/trunk/src]
> @customer = r
>
> It results, that in trunk/src and below ONLY customer can read,
> company has no rights.
>
> Is this really an intentional change? It results in our case in a huge
> amount of duplicated ACL entries and seems a rather drastic change
> regarding backwards compatibility.

This kind of change is probably not intentional. It does appear that we
need more test cases, though.

-- Brane

Re: Bug: Locally deleted file wrongly accepted as log message string.

[Branko Čibej]

On 29.06.2018 10:35, Philip Martin wrote:
> Karl Fogel  writes:
>
>> :-).  In any case, I first wanted to make sure there is consensus that
>> this is a bug.  Do we agree?
> Agreed.

That check was put in the code to prevent users from writing '-m foo' instead of '-F foo'. It was *not* put there
to prevent people from using the name of a (nominally)
version-controlled file in the log message. Therefore, the behaviour is
correct, since in your second example, there is no such file on disk.

Note that the error message says that "the log message is a pathname",
not that it's a versioned file. Also the comment in the code where we
check that says:

If the -m argument is a file at all, that's probably not what the
user intended.


QED: not a bug but expected behaviour.

-- Brane

P.S.: Incidentally, Karl, your name appears in the blame of that bit of
the source file, so I'm assuming that, at least at some point, you
agreed with the current behaviour. :)

Re: SVN patch issue with property changes

[Branko Čibej]

On 29.06.2018 10:45, Johan Corveleyn wrote:
> On Fri, Jun 29, 2018 at 10:34 AM, Branko Čibej  wrote:
>> On 28.06.2018 22:08, Julian Foad wrote:
>>> Philip Martin wrote:
>>>> Julian Foad  writes:
>>>>> Julian Foad wrote:
>>>>>> The bug seems to be that 'svn patch' fails to apply any patch of
>>>>>> this form, that tries to change a property value from empty to
>>>>>> non-empty.
>>>>> I committed a test for this in http://svn.apache.org/r1834628
>>>> I'm confused, you are treating as '' special?  Suppose an existing
>>>> property P has value 'foo'.  Should a patch that adds P with value 'bar'
>>> The issue is about a patch that *changes* the current value to another 
>>> value, not a patch that *adds* a property.
>>>
>>> I am pointing out that a patch that changes the empty value '' to 'bar' 
>>> should be (and isn't being) applied successfully to a property that already 
>>> has the empty value ''.
>>>
>>> The patch format for modifying an empty value is mostly the same as the 
>>> patch format for adding a new property:
>>>
>>> [[[
>>> Property changes on: f
>>> ___
>>> Added: empty
>>> ## -0,0 +1 ##
>>> +foo
>>> \ No newline at end of property
>>> ]]]
>>> vs.
>>> [[[
>>> Property changes on: f
>>> ___
>>> Modified: empty
>>> ## -0,0 +1 ##
>>> +foo
>>> \ No newline at end of property
>>> ]]]
>>>
>>> It's similar to the ambiguous patch representation of create a file or add 
>>> text to an empty file. In that case, 'svn patch' first creates the file if 
>>> it doesn't exist, and in both scenarios adds the patch text.
>>>
>>> For a property patch, a property-patch header line specifies whether it's a 
>>> modify or an add, so there is no ambiguity. If the patch asks to 'modify' 
>>> from empty to non-empty, when the target property already exists and has an 
>>> empty value, this should certainly succeed.
>> However, when libsvn_client creates the svn:executable property, it
>> *always* sets its value to *. Applying a patch from empty to something
>> else will then very likely result in a conflict; because the
>> svn:executable property value cannot be empty (unless someone used a
>> broken client). This has been true since at least version 0.14., some 15
>> years ago.
> I think the cvs2svn conversion tool makes it possible to have an empty
> svn:executable property. I don't remember if it does this by default,
> or you need to do something special. I just recall we had this with an
> early attempt at converting years ago (we ended up throwing that
> version away, and replaced it with *).
>
> I remember thinking at the time: "Why do we need to set it to *? The
> docs only say the property needs to be set, but it doesn't require it
> to be *, it can be _any value_ ... it's not because the default svn
> client does so that it's required ..."

It's not "required" until you begin playing around with 'svn patch',
which did not exist at the time. :) libsvn_client will surely do the
right thing as soon as it sees the property, setting the executable bit
in the WC. But 'svn patch', if it's a bit naïve, may get things wrong.
Which would be a bug in 'svn patch' because it should treat special
properties just as specially as the rest of libsvn_client does. For
example, we have properties where we verify that the contents are utf-8
text with \n line endings; it shouldn't be possible for 'svn patch' to
break those constraints. svn:executable just happens to have a different
constraint.

-- Brane

Re: SVN patch issue with property changes

[Branko Čibej]

On 28.06.2018 22:08, Julian Foad wrote:
> Philip Martin wrote:
>> Julian Foad  writes:
>>> Julian Foad wrote: 
 The bug seems to be that 'svn patch' fails to apply any patch of
 this form, that tries to change a property value from empty to
 non-empty.
>>> I committed a test for this in http://svn.apache.org/r1834628
>> I'm confused, you are treating as '' special?  Suppose an existing
>> property P has value 'foo'.  Should a patch that adds P with value 'bar'
> The issue is about a patch that *changes* the current value to another value, 
> not a patch that *adds* a property.
>
> I am pointing out that a patch that changes the empty value '' to 'bar' 
> should be (and isn't being) applied successfully to a property that already 
> has the empty value ''.
>
> The patch format for modifying an empty value is mostly the same as the patch 
> format for adding a new property:
>
> [[[
> Property changes on: f
> ___
> Added: empty
> ## -0,0 +1 ##
> +foo
> \ No newline at end of property
> ]]]
> vs.
> [[[
> Property changes on: f
> ___
> Modified: empty
> ## -0,0 +1 ##
> +foo
> \ No newline at end of property
> ]]]
>
> It's similar to the ambiguous patch representation of create a file or add 
> text to an empty file. In that case, 'svn patch' first creates the file if it 
> doesn't exist, and in both scenarios adds the patch text.
>
> For a property patch, a property-patch header line specifies whether it's a 
> modify or an add, so there is no ambiguity. If the patch asks to 'modify' 
> from empty to non-empty, when the target property already exists and has an 
> empty value, this should certainly succeed.

However, when libsvn_client creates the svn:executable property, it
*always* sets its value to *. Applying a patch from empty to something
else will then very likely result in a conflict; because the
svn:executable property value cannot be empty (unless someone used a
broken client). This has been true since at least version 0.14., some 15
years ago.

-- Brane

Re: Unable to shelve changes when using custom diff-cmd

[Branko Čibej]

On 26.06.2018 12:19, Csongor Pal wrote:
> Hi,
>
> I ran into an issue with svn shelve on my setup. I use the following
> script as my diff-cmd to open diffs with FileMerge on
> macOS: svn-diffwrap.sh
> 
>
> When running an svn shelve command I get the diffs opened up in
> FileMerge and the command fails with: svn: E29: No changes were
> shelved
>
> When I remove the diff-cmd setting from the config file svn shelve
> works as expected, but is there a way to have both features work at
> the same time?

It would be helpful if the wrapper script returned the exit code from
the diff program. Something like 'exit $?' at the end would do it.

-- Brane

Re: Problem with svndumpfilter

[Branko Čibej]

On 08.06.2018 10:20, Doros Agathangelou wrote:
> Another option is to use Subdivision, a commercial tool that is
> designed to do exactly these kinds of operations, in other works
> Delete files, Extract files, Split repositories in two parts.
> Subdivision reads the repository structure in memory and 'understands'
> the structure of your repository. It can therefore create the
> necessary derived selections from your selections to make sure that
> the delete operation succeeds in the first pass. In this example,
> Subdivision would make sure that /branches/develop/dir2 would be
> available for the copy to be made from it (or that both source and
> copy would both be unavailable - depending on the user selections).
>
> Subdivision is a Windows application but we are working on a Linux
> solution too. You can try a demo by visiting http://subdi.vision
>
> Goes without saying that we are affiliated with Subdivision and we are
> sorry for the shameless advertising but we believe people in this
> group will benefit from knowing that Subdivision exists.


Before advertising proprietary, platform-specific tools, I'd first
suggest that the OP take a look at

    https://gitlab.com/esr/reposurgeon

which also supports these kinds of operations and is open source.


> On Thu, Jun 7, 2018 at 6:08 PM Stefan Sperling  wrote:
>> On Thu, Jun 07, 2018 at 10:40:51AM -0400, Alfred von Campe wrote:
>>> Thanks, Stefan.  The path of least resistance for me is to use the script 
>>> you pointed me to.  However, it seems that the exclude feature is not yet 
>>> implemented:
>>>
>>>   try:
>>> if args[0] == 'include':
>>>   sys.exit(analyze_logs(map(sanitize_path, targets)))
>>> elif args[0] == 'exclude':
>>>   usage_and_exit("Feature not implemented")
>>> else:
>>>   usage_and_exit("Valid subcommands are 'include' and 'exclude'")
>>>
>>> Is there a more recent version of this script?
>> I am afraid not. The link I provided points to the latest version of
>> this script we have in our repository.  We would welcome patches to
>> the script. However, since the problem has been fixed in SVN 1.10's
>> version of 'svnadmin' I think it makes more sense to just use 1.10.
>>
>> You could install 1.10 binaries somewhere next to your existing SVN
>> installation and use the 1.10 svnadmin binary to create a dump file.
>> The resulting dump file will be compatible with older versions.

Re: "Expected format '3' of repository; found format '5' "

[Branko Čibej]

On 08.05.2018 22:03, Philip Martin wrote:
> Paul Greene  writes:
>
>> I'm migrating an SVN server to a new server. The old server is running an
>> ancient version of Redhat and version 1.4 of subversion.
>>
>> The new server is running CentOS 7 and version 1.7 of subversion.
>>
>> I'm creating some test dump files to copy from the old server to the new
>> one. When I go to run "svnadmin dump repo.name > repo.name.dump" I get this
>> error on some of the repos:
>>
>> "svnadmin: Expected format '3' of repository; found format '5' "
>>
>> I get the same error if I try to run this command remotely as well - "svn
>> list svn://svnserver/data/subversion/repo.name"
>>
>> Some generate a normal result, and some generate the above error. It seems
>> the newer the repo, the more likely it will push that error.
>>
>> I'm guessing it's related to differing version numbers between what the
>> repos were created with and the current version of the svn software.
>>
>> What is needed to get around this error?
> That error comes from the libsvn_repos layer of Subversion but would
> only be produced by Subversion older than 1.4.  Your claim to be running
> 1.4 is probably incorrect, what does "svnadmin --version" show?
>
> You may have more than one version of Subversion installed on the old
> server.  If you can find and use a more recent version you should be
> able to access the repository.
>
> Alternatively, you do not need to dump/load to move servers.  If the
> repository on the old server is not live then you could simply copy it
> to the new server.  Subversion 1.7 will be able to read/write the copied
> repository.


Actually this could be quite a problem, because FSFS format version 5
was never present in any official release of Subversion. According to
our release notes, it appeared in some 1.7.0-alpha versions, but
official 1.7.x uses format 4 (as does 1.6.x) and will error out if it
sees a format 5 repository.

Someone must have played a little loose with pre-release code on a
production server.

-- Brane

Re: svn client for Windows and non-latin symbols

[Branko Čibej]

On 07.05.2018 11:27, Anders Munch wrote:
> Fra: Mark Phippard [mailto:markp...@gmail.com]:
>> If you see a ? It means the font does not have a glyph for the character. 
>> Use a Unicode font.
> That would only help if svn would output some kind of unicode.

Nonsense.

>  It doesn't.

Subversion will output whatever you have set as your system encoding.
But if your console window isn't using a font that can represent all the
characters in that encoding, then  they won't be printed correctly. This
has nothing to do with Subversion but with how your console is set up.

By the way, the default console font (Consolas) is quite limited and
don't even contain the whole range of accented latin characters. Try
using Lucida Console instead.

> You can't even tell it to output utf-8, there's no such option. 

There is, in fact, but not in Subversion; you have to fiddle with
Windows' regional settings.

> People talk about setting the LANG environment variable or some such,
> but I've never managed to get that to do anything.

LANG and LC_* environment variables are pertinent to Unix, not Windows.

-- Brane

Re: locks-test fail when building subversion-1.10.0 from sources under Linux (Ubuntu 16)

[Branko Čibej]

On 01.05.2018 20:13, Juan Gabriel Covas wrote:
>
>  
>
>  
>
> Ok, my mistake.
>
>  
>
> >>> SUMMARY: All tests successful.
>
>  
>
> I got “success” for all the tests from “make check” command after
> compiling svn from sources NOT using the root account.
>
>  
>
> First I tried to ensure the build process was using the “apr” and
> “apr-util” compiled from the subversion-1.10 sources directory, but
> the same locks-test #14 failed (even forced a “apt-get remove libapr1
> libapr1-dev libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-dev
> libaprutil1-ldap”).
>
>  
>
> But that was not the problem. Only when I used a non-root account to
> compile from sources from scratch, all the tests were successfull.
>
>  
>
> Regards and sorry for the inconvenience,
>


Well, well. This does explain the test failure.

But let me give you a hint: Compiling sources as 'root' is, to put it
mildly, just a "bit" dangerous. What if I added an 'rm -rf /' to our
build scripts? By mistake, of course, obviously I'd never do that on
purpose (even if it /would/ be very educational).

-- Brane

 
>
> Philip said:
>
> >If you have gdb installed you can check whether the 0444 permissions
>
> >have made it to the filesystem (-r--r--r--).  Something like:
>
>  
>
>   $ libtool --mode=execute gdb -arg ./locks-test 14
>
>   (gdb) b svn_fs_lock_many
>
>   (gdb) r
>
>   Breakpoint 1
>
>   (gdb) shell ls -l test-obtain-write-lock-failure/write-lock
>
>   -r--r--r-- 1 pm pm 0 May  1 13:17
> test-obtain-write-lock-failure/write-lock
>
>   (gdb) b open
>
>   (gdb) c
>
>   Breakpoint 2
>
>   (gdb) shell ls -l test-obtain-write-lock-failure/write-lock
>
>   -r--r--r-- 1 pm pm 0 May  1 13:17
> test-obtain-write-lock-failure/write-lock
>
>   (gdb) fin
>
>   (gdb) fin
>
>   Value returned is $1 = 13
>
>   (gdb) p fname_apr
>
>   $2 = 0x77eea130 "test-obtain-write-lock-failure/write-lock"
>
>   (gdb) shell ls -l test-obtain-write-lock-failure/write-lock
>
>   -r--r--r-- 1 pm pm 0 May  1 13:17
> test-obtain-write-lock-failure/write-lock
>
>  
>
> >The second breakpoint is the open that should fail.  The two "fin"
>
> >commands return to the Subversion code and the value 13 is EPERM >showing
>
> >the open failed (because the file has permissions -r--r--r--).
>
>  
>
> >In your case I assume the return value is 0 rather than 13 and the file
>
> >permissions are not -r--r--r--.
>
>  
>

Re: locks-test fail when building subversion-1.10.0 from sources under Linux (Ubuntu 16)

[Branko Čibej]

On 01.05.2018 13:43, Juan Gabriel Covas wrote:
>
>  
>
> Thanks for your input.
>
>  
>
> >> Extract from fails.log:
>
> >> [[[
>
> >> svn_tests: E26: Expected error but got SVN_NO_ERROR
>
> >> FAIL:  lt-locks-test 14: lock/unlock when 'write-lock' couldn't be
> obtained
>
> >> ]]]
>
>  
>
> >That's odd.  You can run just that one test:
>
> >  cd subversion/tests/libsvn_fs
>
> > ./fs-test 14
>
>  
>
> Result:
>
> # ./fs-test 14
>
> PASS:  lt-fs-test 14: set/get txn props, commit, validate new rev props
>
>  
>
> >Does it always fail? 
>
>  
>
> Always Pass when executed individually.
>
>  
>
> >What sort of filesystem are you using?  Is it a
>
> >network filesystem?
>
>  
>
> No network filesystem:
>
> # mount | grep sda1
>
> /dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
>
>  
>
> >If you have strace installed you can run:
>
> >  libtool --mode=execute strace ./locks-test 14 2>&1 | grep
> failure/write-lock
>
>  
>
> This is what I get:
>
>  
>
> …/libsvn_fs# libtool --mode=execute strace ./locks-test 14 2>&1 | grep
> failure/write-lock
>
> unlink("test-obtain-write-lock-failure/write-lock") = 0
>
> open("test-obtain-write-lock-failure/write-lock",
> O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = 3
>
> open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC) = 3
>
> lstat("test-obtain-write-lock-failure/write-lock",
> {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>
> chmod("test-obtain-write-lock-failure/write-lock", 0444) = 0
>
> open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC) = 3
>
>  
>
> >For a successful test the output should end:
>
> > 
>
> > chmod("test-obtain-write-lock-failure/write-lock", 0444) = 0
>
> > open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC)
> = -1 EACCES (Permission denied)
>
> > open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC)
> = -1 EACCES (Permission denied)
>
>  
>
> Doesn’t seem to be the same…
>


This is extremely strange. Your filesystem appears to be seriously
broken ... it should be impossible to open a read-only file in write
mode. Are you absolutely sure that you're running the tests on /dev/sda1?

Perhaps the chmod() is failing ... what are the actual permissions on
that file when the test has completed?

-- Brane

Re: Strange libtool errors when try to build pyhton and ruby bindings (1.10.0)

[Branko Čibej]

On 15.04.2018 21:30, Branko Čibej wrote:
> On 13.04.2018 18:20, Lev Serebryakov wrote:
>>  I'm preparing FreeBSD of subversion-1.10.0 and have very strange errors
>> when try to build bindings.
>>
>>  subversion itself builds without problems.
> I just created a FreeBSD 11 virtual machine tried building the 1.10.0
> source tarball and ... well, I can confirm this report. I couldn't build
> the Perl bindings either, due to a missing header.
>
> However, when I installed autoconf, libtool and swig30, and started with
> a clean tree (make extraclean; ./autogen.sh; ./configure ...), I could
> build JavaHL and all the Swig bindings — with the standard deluge of
> missing typemap warnings. I could run the Perl, Python and JavaHL tests,
> but not the Ruby tests, the latter apparently due to a missing dependency.
>
> It makes me wonder what went wrong with the build scripts generation in
> the release package, because the builds worked fine on Linux, macOS and
> OpenBSD. The other possibility is that FreeBSD is simply weird ...

The problem is that Swig has become a build-time dependency now. We
don't configure the Swig bindings unless Swig is installed, even if the
binding sources are already generated — as they are in the release tarballs.

The solution is to install Swig and tell configure about it:

$ sudo pkg install swig30
$ ./configure --with-swig=/usr/local/bin/swig30 ...


This will not cause the Swig sources to be regenerated, but will perform
the proper configuration to make them compile correctly.

I consider this to be a bug in our build scripts, FWIW.

-- Brane

Re: Strange libtool errors when try to build pyhton and ruby bindings (1.10.0)

[Branko Čibej]

On 13.04.2018 18:20, Lev Serebryakov wrote:
>  I'm preparing FreeBSD of subversion-1.10.0 and have very strange errors
> when try to build bindings.
>
>  subversion itself builds without problems.

I just created a FreeBSD 11 virtual machine tried building the 1.10.0
source tarball and ... well, I can confirm this report. I couldn't build
the Perl bindings either, due to a missing header.

However, when I installed autoconf, libtool and swig30, and started with
a clean tree (make extraclean; ./autogen.sh; ./configure ...), I could
build JavaHL and all the Swig bindings — with the standard deluge of
missing typemap warnings. I could run the Perl, Python and JavaHL tests,
but not the Ruby tests, the latter apparently due to a missing dependency.

It makes me wonder what went wrong with the build scripts generation in
the release package, because the builds worked fine on Linux, macOS and
OpenBSD. The other possibility is that FreeBSD is simply weird ...

-- Brane

Re: SVN E170001: Authentication error with specific user/realm/pw combinations while many other work!

[Branko Čibej]

On 13.04.2018 19:55, NOCERA, ANDY wrote:
>
> Summary: SVN E170001: Authentication error with specific user/realm/pw
> combinations while many other work!
>
>  
>
>  
>
> Observations/Workarounds
>
>  
>
> While there is a work around, by simply changing the password, we have
> an unusual reoccurring issue with some user/realm/password
> combinations.  It’s a problem
>
> setting the same password to many repos.
>
>  
>
> The issue shows up under both CRAM-MD5 and DIGEST-MD5, but not for the
> same user/realm/password. 
>
>  
>
>  
>
> From and SVN perspective:
>
> How do I get svn/svnserve to log the hashed response so I can compare
> it outside of SASL and MYSQL.  
>
> I suspect our method to generate the hashed CRAM-MD5 and DIGEST-MD5
> that we store in mysql has a bug, what is a good place to locate
> source for this program.
>


Svnserve does not use a MySQL database for storing passwords or password
hashes. So you either have a customized svnserve or a customized SASL
library. You'll have to find out where those customizations came from.
There is no such functionality in the Subversion code base.

-- Brane

Re: Subversion 1.9.7 server on Windows, advice on setting up svnsync?

[Branko Čibej]

On 27.03.2018 22:52, Bo Berglund wrote:
> When I move forward and prepare target repositories for syncing I need
> to activate two hooks in each repo (pre-revprop-change and
> start-commit). So there will be 18 scripts to create...
> Can I symlink the existing hooks into the new repositories so I only
> need to manage one set of files?

Yes, of course.

-- Brane

Re: Can import also convert the source to a working copy

[Branko Čibej]

On 15.03.2018 20:18, Bo Berglund wrote:
> On Thu, 15 Mar 2018 13:45:13 -0400, Kris Deugau 
> wrote:
>
>> Unless I misread your original post, the very first option in that link 
>> looks like a better fit.  To rephrase it somewhat for your case:
>>
>> 1)  Create a repository or a directory in the repository
>> 2)  Create your local files
>> 3)  Check out the empty repository path to your workspace - this won't 
>> overwrite any of your files
>> 4)  svn add [files]
>> 5)  svn ci
>> 6)  Continue working as usual
>>
>> This avoids a round trip to the server to push the current files, then 
>> pull them back down to create the formal SVN working copy with things 
>> already in it - instead you "check out" an empty directory which should 
>> be quite fast.
>>
> I readthat page as best I could but it looked so much Linuxish

What on earth is Linuxish about it? Files and directories exist on
Windows, too, it doesn't matter what the names are. If you can't
extrapolate instructions to your specific OS, you'll have no end of
trouble using any tool that works with files and directories ...

>  that I
> lost track of how it could be done and then finding the other reply
> and looking up that led me to the procedure I showed.
> Also, I normally already have the files when subversion comes into
> play...

That does not matter. The point is that you check out an empty tree in
the repository over an existing tree in your local filesystem and that
will magically create a working copy with no versioned objects in it.

-- Brane

Re: Can import also convert the source to a working copy

[Branko Čibej]

On 15.03.2018 11:48, Bo Berglund wrote:
> I have used this sequence for handling new projects with svn:
>
> - Start a new project in whatever IDE is used
> - Work a bit on initial code so the framework is OK
> - Exit the IDE
> - Command prompt in the parent of the project dir
> - svn import   --depth files -m "message"
> - rename  
> - svn co  
> - move \ \
> - delete 
> - start dev IDE again and hopefully find that it loads properly
>
> I want to avoid having to do all the steps following the svn import
> command so I can just continue working where I was when I wanted to
> put the project under version control.
> Specifically there may be ignored files in the project dir that are
> needed by the dev IDE but should not be versioned and I would like
> these to be intact yet not part of the versioning. I have svn ignores
> in my config file so they won't be part of the import and therefore
> they will not appear after the following checkout...
>
> Is there some flag or such that can help out during the import or in a
> following checkout so that the extra directory >something else> does
> not need to be used?
>
> Or can I just move the .svn dir from the working copy to the original
> project and then it will be converted in place?


svn checkout --force

-- Brane

Re: Run shelve tests in subversion 1.9

[Branko Čibej]

On 11.03.2018 11:20, wuzhouhui wrote:
> I am backporting 'svn shelve' subcommand into Subversion 1.9,

Why are you doing this? Subversion 1.10 will be released in a couple
weeks; the first release candidate is available, with all the shelving
support. Why not use that, instead of backporting something that we'll
never support?


>  and now I want
> to do some tests. If I copy shelve_tests.py from Subversion-1.10 to
> Subversion-1.9/subversion/tests/cmdline/shelve_tests.py, and run 'make check',
> but shelve_tests.py doesn't executed.
>
> So my question is how to run shelve_tests.py in Subversion 1.9 when 'make
> check'?

Most likely you forgot to make the file executable.

-- Brane

Re: trunkless svn: using svn without a trunk

[Branko Čibej]

On 08.03.2018 13:22, Paul Hammant wrote:
>
> I make a living visiting enterprises to help them get _to_
> Trunk-Based Development and _away_ from other branching models.
> The advocacy site: https://trunkbaseddevelopment.com
>  for your bookmarks :)
>
>
>
> I have already read some of your site, and the impression I got
> was that it's mostly about not having teams of developers working
> on different branches simultaneously. And we're not planning to do
> that; the whole team would only be working on one branch at a
> time. Our workflow would be MUCH cleaner than the picture of the
> "Cascade" workflow that you show
> on https://trunkbaseddevelopment.com/alternative-branching-models/
>  .
>  
>
>
> I look forward to you blogging about the pros/cons in a year. 
>
> In answer to your question, Subversion supports *_arbitrary_*
> branching models.  The TBT way of working is just an idiom, that's
> perhaps supported more in the tool chain that other ways of working. 
> Specifically, you can create a branch from
> http://svnServer/path/to/directory/ 
> to  http://svnServer/somewhere/else/entirely/
>  and merge point tracking will make it
> all work over time.  Try to keep merges in one direction. That's just
> my TBD-related opinion and the great team that maintains Svn will
> disagree. I may point out
> https://paulhammant.com/categories.html#Limits_of_Merging though.
>
> Git and Mercurial don't support arbitrary branching - all branches
> (and master (trunk equiv)) do the mechanics of branching from root. At
> least for now - over time Git changes to implement things that were
> previously "hell no".  Subversion and Perforce support arbitrary
> branching.  The founding dev team for Subversion around the 2001
> timeframe would tell you that they were aware of Perforce and among
> others it was inspiration for the design/goals of Svn.


More or less. Maybe.

In other news, 'trunk' is just another branch ... and I for one would
have been happier back then if we hadn't singled it out in the
recommended repository structure. Something like 'branches/main' would
have been less confusing in the long run, IMO.

The long and short of it is that whatever branching model you decide to
use, its success depends on discipline and documentation more than
anything else (as well as fitting the tool's (mis)features, of course).
Whether or not cascading branches work for you really depends on whether
they fit your development and release management methods.

-- Brane

Re: SHA-1 collision in repository?

[Branko Čibej]

On 26.02.2018 22:41, Myria wrote:
> -bash-4.1$ sqlite3 rep-cache.db "select * from rep_cache where
> hash='db11617ef1454332336e00abc311d44bc698f3b3'"
> db11617ef1454332336e00abc311d44bc698f3b3|604440|34|134255|136680
>
> The line from the grep -a command containing that hash is below.  They
> all match.
> text: 604440 34 134255 136680 c9f4fabc4d093612fece03c339401058
> db11617ef1454332336e00abc311d44bc698f3b3 604439-cyqm/_13
>
>
> In other news, unknown whether related to the current problem, my
> attempt to clone the repository to my local computer is failing:
>
> D:\>svnsync sync file:///d:/svnclone
> Transmitting file data
> .svnsync:
> E16: SHA1 of reps '227170 153 193 57465
> bb52be764a04d511ebb06e1889910dcf
> e6291ab119036eb783d0136afccdb3b445867364 227184-4vap/_4o' and '-1 0
> 193 57465 bb52be764a04d511ebb06e1889910dcf
> e6291ab119036eb783d0136afccdb3b445867364 227184-4vap/_4o' matches
> (e6291ab119036eb783d0136afccdb3b445867364) but contents differ
> svnsync: E160004: Filesystem is corrupt
> svnsync: E200014: Checksum mismatch while reading representation:
>expected:  bb52be764a04d511ebb06e1889910dcf
>  actual:  80a10d37de91cadc604ba30e379651b3
>
> This is odd, because revision 227185 (the revision it's trying to
> commit) verifies fine on the originating server:
>
> -bash-4.1$ sudo svnadmin verify -r227170 /srv/subversion/repositories/meow
> * Verifying repository metadata ...
> * Verifying metadata at revision 227170 ...
> * Verified revision 227170.
> -bash-4.1$ sudo svnadmin verify -r227185 /srv/subversion/repositories/meow
> * Verifying repository metadata ...
> * Verified revision 227185.


It is a very, *very* bad idea to perform any operations on the
repository as root! You should not have to do that.

Please check file ownership and permission throughout the repository;
none of the files should be owned by root.

-- Brane


> On Fri, Feb 23, 2018 at 5:42 PM, Philip Martin  
> wrote:
>> Philip Martin  writes:
>>
>>> There are a couple of options:
>>>
>>>   A) disable rep-caching by editing fsfs.conf inside the repository
>>>
>>>   B) reset the mapping by deleting/renaming the file db/rep-cache.db
>>>  inside the repository (but please rename rather than delete if you
>>>  want to help us identify the corruption)
>>>
>>> Doing either of these should allow the commit to succeed.
>> To verify the corruption start with the rep-cache:
>>
>>   sqlite3 db/rep-cache.db "select * from rep_cache where 
>> hash='db11617ef1454332336e00abc311d44bc698f3b3'"
>>
>> That should give you five numbers: the hash, the revision (604440), the
>> offset, the size and the expanded size.
>>
>> Then examine the revision file for r604440.  It could be unpacked:
>>
>>   grep -a "^text: 604440.*/_" db/revs/604/604440
>>
>> or packed:
>>
>>   grep -a "^text: 604440.*/_" db/revs/604.pack/pack
>>
>> One of the lines from grep should contain the hash and that line should
>> start:
>>
>>   text: 604440
>>
>> followed by three more numbers then hashes and other stuff.  The three
>> numbers are the offset, size and expanded size and should match the
>> values from the rep-cache but I suspect the rep-cache has the wrong
>> offset.
>>
>> --
>> Philip

Re: SHA-1 collision in repository?

[Branko Čibej]

On 24.02.2018 01:09, Myria wrote:
> Once it's on my local machine, I'll be able to compile TortoiseSVN and
> debug it while pointing to a file:// repository.  (TortoiseSVN instead
> of command-line svn because TortoiseSVN is compiled with Visual C++
> and is therefore many times easier to debug.)

In fact, on Windows, the command-line Subversion is also compiled with
Visual C++ and should be quite as easy to debug. What probably is harder
is setting up the initial build environment ...


-- Brane

Re: SHA-1 collision in repository?

[Branko Čibej]

On 22.02.2018 21:30, Myria wrote:
> When we try to commit a very specific version of a very specific
> binary file, we get a SHA-1 collision error from the Subversion
> repository:
>
> D:\confidential>svn commit secret.bin -m "Testing broken commit"
> Sendingsecret.bin
> Transmitting file data .svn: E16: Commit failed (details follow):
> svn: E16: SHA1 of reps '604440 34 134255 136680
> c9f4fabc4d093612fece03c339401058
> db11617ef1454332336e00abc311d44bc698f3b3 605556-czmh/_8' and '-1 0
> 134255 136680 c9f4fabc4d093612fece03c339401058
> db11617ef1454332336e00abc311d44bc698f3b3 605556-czmh/_8' matches
> (db11617ef1454332336e00abc311d44bc698f3b3) but contents differ
>
>
> What can cause this?

The simplest explanation would be a corruption of the existing
representation on disk. Note that both the MD5 and the SHA1 checksums
appear to match, as do the sizes; which makes it even more likely that
it's the same file but the copy in the repository is somehow corrupted.

-- Brane

Re: auto-props syntax in file vs. property

[Branko Čibej]

On 22.02.2018 13:52, Chris wrote:
> Re-awakening my previous thread about the auto-properties. I get really 
> confused by where to use ;; and ; as a separator.
>
> I currently have this in the auto-props on the repo:
> *.txt = svn:mime-type=text/plain;;charset=iso-8859-1;svn:eol-style=LF
>
> And then if I add a text file:
> prompt>  touch foo.txt; svn add foo.txt; svn pg svn:mime-type foo.txt
> A foo.txt
> text/plain;charset=iso-8859-1

More completely: an 'svn proplist -v' would show the folloing properties:

svn:mime-type=text/plain;charset=iso-8859-1
svn:eol-style=LF

> So the property itself is with just one semicolon in there despite the 
> auto-prop having ;;
> Is this the correct behavior?

Yes of course. In the auto-props configuration, a single colon separates
individual properties. If you want a colon within a property value, you
have to write ;; in the auto-props configuration to get the ; in the
property value.

If instead you'd had this auto-props configuration:

*.txt = svn:mime-type=text/plain;charset=iso-8859-1;svn:eol-style=LF


Then, when you added a file to Subversion, you'd get the following
properties set:

svn:mime-type=text/plain
charset=iso-8859-1
svn:eol-style=LF


which is probably not what you want.


> While if I to the same thing manually, i.e.
>
> prompt> touch foo; svn add foo; svn propset svn:mime-type 
> "text/plain;;charset=iso-8859-1" foo; svn pg svn:mime-type foo
> A foo
> property 'svn:mime-type' set on 'foo'
> text/plain;;charset=iso-8859-1
>
> That is, I'm passing in the exact string that I have in my auto-props into 
> propset for a file without .txt-suffix so I don't get the auto-properties. 
> But as you see in the resulting property that I now have has double 
> semi-colons.

On the command-line you can only set a singly property value at a time,
so there's no need to escape the ';' delimiter.
But the auto-props configuration isn't a single property; it's several
properties, delimited with a single ';'.

> My guess is that the former is the intended behavior and I should not be 
> passing in the ";;" into the manual command,

Yes.

>  but I'm getting really confused here. I seems very error-prone that manual 
> propset can't use the strings from the config file or auto-props wihtout 
> getting a different result.
>
> Which version is the correct one, or do both actually do the job?

Each does its job in its own context.

-- Brane

Re: enhancement suggestion

[Branko Čibej]

On 20.02.2018 15:59, Johan Corveleyn wrote:
> On Tue, Feb 20, 2018 at 1:11 PM, Christian Klie  wrote:
>> Hello,
>> currently I made a huge commit. In respect of the number of the files (see
>> attachment "working copy").
>> While the commit went down the transaction grew and grew and grew (see
>> attachment "transaction").
>> That all happend because of the files in the transaction's folder being very
>> small but huge in number so
>> those have a relativly huge overheat, because of the blocksize. So I am
>> suggesting to rethink the commit procedure but I am not
>> sure whether to report this or not.
> So the directory 5-6.txn below db/transactions showed:
> - Number of files: 244295 (0 folders)
> - Size: 88.6 MB
> - Size on disk: 29.8 GB
> (Wow, that's huge! For only 88.6 MB of data in 244295 files, that's a
> factor of more than 300 compared to the actual data size)

344 exactly. The filesystem cluster is 128 KiB and the average file size
is 380 bytes. The cluster (allocation unit) size is quite large, which
suggests it may not be NTFS, or it is a really humongously huge volume. See:

https://support.microsoft.com/en-gb/help/140365/default-cluster-size-for-ntfs-fat-and-exfat

> And your working copy showed:
> - 118094 files, 5350 folders
> - Size: 903 MB
> - Size on disk: 1.01 GB
>
> What SVN version is the server? What SVN version is the client?
> What version of back-end filesystem on the server (BDB or FSFS, which 
> version)?
> -> If you have a 1.9 server, please send the output of "svnadmin info
> REPOS_PATH". Otherwise, send the contents of REPOS_PATH/format and of
> REPOS_PATH/db/format.
>
> The server is on Windows apparently. Which version of Windows? NTFS I
> presume? Anything special about that disk? Any special settings?
>
> Oh and one more question: do those files in your working copy have
> many svn properties?

You're missing the point, Johan ... the "enhancement suggestion" was to
"rethink the commit procedure". Having rethunked it, I suggest the
obvious cheapest solution would be to fix the underlying filesystem. :)

-- Brane

Re: Not so cheap moves

[Branko Čibej]

On 19.02.2018 15:40, Ignacio González (Eliop) wrote:
> Client svn 1.8.13
> Server svn 1.8.13 on Centos 7 64 bit
> -
> I have a repository with 400 000 revisions.
> Proyect X in that repository has the usual trunk / branches / tags
> structure.
> Tags are structured in a dozen of sub-directories:
> Project X
>  +- trunk
>  +- tags
>     +-- setA
>     +-- setB
>     +-- setC
>
> The number of tags under 'setB' is over 3000. All of them are copies
> of the trunk at several points in the past.
> I want to rename 'setB' to 'setF'.
> Easy, I thought: svn mv setB .setF.

Did you use server-side move or client-side move + commit? Please show
us the *exact* command you used, not some summary that you think is
sufficient, but really is not.

-- Brane

Re: Server side svn:auto-props, how to set it correctly?

[Branko Čibej]

On 17.02.2018 08:18, Bo Berglund wrote:
> On Fri, 16 Feb 2018 10:20:05 +0100, Branko ?ibej 
> wrote:
>
>>> editor pops up and I enter all of the lines like:
>>> *.c = svn:eol-style=native
>>> *.cpp = svn:eol-style=native
> Do I also have to handle case here?
> I.e. for each file pattern do I have to figure out all case
> permutations too?
> Ex:
> *.cpp = svn:eol-style=native
> *.cpP = svn:eol-style=native
> *.cPp = svn:eol-style=native
> *.cPP = svn:eol-style=native
> *.Cpp = svn:eol-style=native
> *.CpP = svn:eol-style=native
> *.CPp = svn:eol-style=native
> *.CPP = svn:eol-style=native
>
> Or is it just the svn_apply_autoprops.py that uses case sensitive
> pattern recognition?
> I noticed a file not getting the property set when I used it...
> It was named in all caps.

Paths in Subversion are case-sensitive. All patterns are case-sensitive
too. You'll either have to add all case permutations, as you showed
above, or teach your users some discipline in naming files.

-- Brane

Re: Server side svn:auto-props, how to set it correctly?

[Branko Čibej]

On 16.02.2018 12:41, Ryan Schmidt wrote:
> On Feb 15, 2018, at 14:18, Bo Berglund wrote:
>
>> I would like to set our SVN server to enforce some file properties for
>> commonly used files such as images and binary files as well as eol
>> handling between client operating systems.
> The server-side auto-props feature can *suggest* properties users should use, 
> but if you want to *enforce* that they are used, and prevent commits that 
> don't, you have to write a pre-commit hook script to do that.

That's not true at all. The client will honour the properties it knows
about. Of course in the case of svn:auto-props, these are processed at
'svn add' and the user can change the results before committing; but
they're not a suggestion by any means, they even override client-side
configuration.

-- Brane

Re: Server side svn:auto-props, how to set it correctly?

[Branko Čibej]

On 15.02.2018 21:18, Bo Berglund wrote:
> I would like to set our SVN server to enforce some file properties for
> commonly used files such as images and binary files as well as eol
> handling between client operating systems.
> I have fixed up one repository from the client side using working
> copies and the svn_apply_autoprops.py script.
> But it feels like I still have to make some *server side* settings
> that will stop new file additions to be done with incorrect
> properties.
>
> I have tried looking for a manual for svn 1.9 but the only one I have
> found is 1.7 and there is nothing about setting up server side
> enforced properties. Apart from this there is only a number of
> webpages, which I find hard to navigate.
>
> What I have found is this:
> https://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config
> https://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Auto-Props_Hierarchy_and_Precedence
>
> But it is not clear to me HOW one can set these properties

Obviously you set them on some directory and commit the change.

> The system I am setting up consists of a number of VisualSVN
> repositories each holding a number of projects of certain types. All
> projects have the structure:
> Project
>   |-- branches
>   |-- tags
>   |-- trunk
>
> How can I set the auto-props on the server itself

Not on the server, on the root of the repository, which is a directory.

>  such that when
> someone imports a new project the files will be assigned the necessary
> properties even if they have not properly set up their clients?
>
> I need some exact command descriptions if possible...

For example:

svn checkout ${REPOSITORY_ROOT_URL} ${WC_PATH} --depth empty
cd ${WC_PATH}
svn propset ${PROPERTY} ${VALUE}
svn commit -m "Commit message"


This will set a property on the repository root directory.

> PS:
> On the server I found a conf subdirectory in the server root and it
> contains a svnserve.conf file which starts out like this:
>
> ### This file controls the configuration of the svnserve daemon, if
> you
> ### use it to allow access to this repository.  (If you only allow
> ### access through http: and/or file: URLs, then this file is
> ### irrelevant.)
>
> Our access method is via https: through the Apache webserver, so this
> conf file is apparently not useful at all...

That's completely irrelevant, it has nothing to do with repository contents.

-- Brane

Re: File not accepted as valid addition to svn

[Branko Čibej]

On 12.02.2018 18:41, Bo Berglund wrote:
> On Mon, 12 Feb 2018 15:54:00 +, Philip Martin
>  wrote:
>
>> Bo Berglund  writes:
>>
>>> svn add Fasadändring
>>> svn: warning: W155010: 'D:\Bosse\Fasadändring' not found
>> '&' has special meaning to the shell and needs to be quoted or escaped.
> I always thought that this was the case only for Linux, since & is a
> perfectly valid part of a file name on Windows...
> But I will refrain from such characters in paths in the future.

The Windows shell has special characters, too. As far as file names are
concerned, Unix filesystems typically allow _more_ characters than
Windows filesystems.

-- Brane

Re: Does svn client binary honors LANG env variable on Windows?

[Branko Čibej]

On 10.02.2018 09:59, Thorsten Schöning wrote:
> Hi all,
>
> I'm using the PHP webapp WebSVN and ran into encoding problems with
> file names in my Linux environment when e.g. creating downloadable
> Zipr or Tars using WebSVN. I worked around those problems using a
> simple shell wrapper like the following:
>
>> #!/bin/sh
>>
>> export LC_CTYPE=de_DE.UTF-8
>> svn $*
> Other people fixed this differently by using setlocale in WebSVN
> directly and forwarding that value using LANG per shell invokation:
>
>> // Make sure that the input locale is set up correctly
>> setlocale(LC_ALL, $config->getLocale());
>> $cmd = $this->svnCommandString('blame', $path, $rev, $peg).' > 
>> '.quote($filename);
>> if ($config->getLocale() != null)
>>   $cmd = "LANG=".setlocale(LC_ALL, 0)." ".$cmd;
> A command line like this doesn't work on Windows, it at least needs a
> different syntax. I know the needed syntax and all but am not sure if
> it is even necessary to handle Windows specifically the same way.
>
> I think this depends on if the svn binary honors the env var LANG on
> Windows at all? PHP itself simply executes "cmd.exe /C '...' in the
> end. So which encoding is used in this case with and without setting a
> LANG variable? I have the feeling it's that of the invoked cmd.exe
> process in both cases because APR handles that specially for Windows?

On Windows, the locale is a system-wide property and it's not defined by
environment variables. Nor does Subversion look at the environment, on
any platform; it uses the C setlocale() function to set the default
locale from the environment. On Unix, that ends up looking at
environment variables; on Windows, it uses a different mechanism.

Also, on Windows, Subversion (or rather, APR) knows that file names are
always written as Unicode, regardless of the system locale.

Since Subversion is not the tool that's creating your ZIP or TAR
packages, any encoding problems are more likely caused by the
surrounding (PHP/WebSVN) code.

-- Brane

Re: regarding downloading subversion

[Branko Čibej]

[no top-posting please]

On 08.02.2018 18:24, Eric Johnson wrote:
> Unfortunately, it is difficult to tell from your email what your
> question is. And because of that, it is also difficult to tell if this
> is the right forum for addressing your question.
>
> Not meaning to be rude or dismissive, but can you provide more
> details? The email says "not able to complete the download process".
> Download of what? From where? How did it fail? Depending on your
> answer, some other email list might be more appropriate.
>
> Eric.
>
> On Thu, Feb 8, 2018 at 3:09 AM, nayama scariah  > wrote:
>
> Good day sir,
> I tried to download Apache Subversion 1.9.7 for working on krc
> model in Davinci platform. But I am not able to complete the
> download process. After extract all the data from Zip file what is
> the next step for further proceedings and I tried to download Slik
> subversion also, which is also not working.
>


As far as I can see, the OP is downloading the source. Which needs to be
compiled before you get a working application.

-- Brane

Re: svn diff non-temporary files option

[Branko Čibej]

On 07.02.2018 15:06, Nico Kadel-Garcia wrote:
> On Wed, Feb 7, 2018 at 8:21 AM, Branko Čibej <br...@apache.org> wrote:
>
>> No; because 'svn diff' hides differences in end-of-line style and
>> keyword expansions, it has to preprocess the files in the working copy,
>> and it sends those preprocessed files to the external diff wrapper.
>>
>> We could theoretically skip that part for files that don't have
>> svn:eol-style or svn:keywords properties, but then the tool invocation
>> would be inconsistent.
>>
>> Your best bet is to use an editor that has Subversion support built in.
> :(Looking innocent over here.) Emacs?

What else do you suppose I'm using? :)

-- Brane

Re: svn diff non-temporary files option

[Branko Čibej]

On 07.02.2018 13:07, Juraj Priskin wrote:
> Hi,
>
> I'm using vimdiff as my diff tool for svn diff.  The wrapper is simple
> one line command "vimdiff -R $6 $7".  Having open vimdiff, it happens
> often that I would like to fix my local changes, mostly typos, small
> stuff, etc.  It would be thus handy if I can do it in vimdiff, rather
> than open the file separately.
>
> I thought that there should be some svn diff option to do so, but I
> did not find that.  After searching internet, I found few similar
> questions with no answers.  I briefly went through red-bean SVN book,
> chapter 7., that has some details on external diff tool setup, etc.
> but I haven't found solution there also.  I search your bugs also with
> no result.
>
> Likely I can resolve this with some small Bash scripting, like getting
> my base file revision via "svn info", then export that file revision
> from the repository, save it to some temp_base_file and call vimdiff
> directly without "svn diff" like "vimdiff -R temp_base_file file", but
> this seems to me odd.  At least just because I will not see potential
> changes in the file attributes.
>
> So, is there a way how to provide the real local file for the external
> diff tool "right side"?

No; because 'svn diff' hides differences in end-of-line style and
keyword expansions, it has to preprocess the files in the working copy,
and it sends those preprocessed files to the external diff wrapper.

We could theoretically skip that part for files that don't have
svn:eol-style or svn:keywords properties, but then the tool invocation
would be inconsistent.

Your best bet is to use an editor that has Subversion support built in.

-- Brane

Re: Searching for a C++ API

[Branko Čibej]

On 30.01.2018 13:30, Daniel Shahaf wrote:
> R developer wrote on Tue, 30 Jan 2018 10:22 +0100:
>> I'm not that familiar with the C API unless I'm missing something
>> (which is very well possible) one would have to manage the apr pools
>> himself?
> In the C API, the caller of a function passes to it a result_pool and a
> scratch_pool, and decides when to reclaim or free their memory space
> (apr_pool_clear / apr_pool_destroy).
>
>> for instance
>> https://svn.apache.org/repos/asf/subversion/trunk/tools/examples/minimal_client.c
>> does seem very complex to me for the tasks it performs is there any
>> easier C example out there?
> svnlook? svnmucc? subversion/tests/cmdline/*.c?
>
> There were C++ language bindings developed in trunk, see
> subversion/bindings/cxxhl/.  I don't know what the state of the art on
> that is --- quite possibly they aren't stable yet --- but they are
> Apache Licensed, so perhaps you could build on them.  If they don't
> yet provide some functionality which you require, please do send
> patches :-).


There's hardly any art there that could be in a state. Most of that
effort was making things compile ... there's no real substance there
(but there is a false start or two).

-- Brane

Re: Searching for a C++ API

[Branko Čibej]

On 29.01.2018 11:45, R developer wrote:
> Hello all,
>
> I have been involved in writing a closed source application that among
> other things maintains a checkout from an SVN repository, the
> application used to be written in C# so at the moment we are used to
> SharpSvn. Recently the decision was made to incorporate the
> functionality into a mobile c++ app (yes, I do wish we could use a
> different language, but for now that's out of our scope).
>
> Is there a C++ library available somewhere?
> One that can be used in a closed source app and compiles both on
> Windows and Linux (and preferably other platforms like OSx, iOS, Android).
> Usage of c++11, boost and/or Qt frameworks is fine as our app already
> uses them.
>
> When we started searching; we found several dead ends. Either GPL code
> which we can't use or outdated and no longer compiling.
>
> What is the preferred/easiest way of doing a simple checkout/update of
> a svn repository folder in a c++ application?
> (Any leads will be appreciated as we are quite new to this topic)


There is no C++ API that I'm aware of. However, the C API can quite
handily be used from C++.

-- Brane

Re: Is there some keyword providing the local path within the working copy?

[Branko Čibej]

On 26.01.2018 08:50, Thorsten Schöning wrote:
> Guten Tag Johan Corveleyn,
> am Donnerstag, 25. Januar 2018 um 20:40 schrieben Sie:
>
>> But I don't understand what you're trying to do. You want to include
>> the WC-root-relative path to *another dir* inside some config file,
>> while you're checking out or updating that config file? That's weird.
> One use case is simply providing e.g. systemd service files in a dir
> structure like the following, while working around some limitations of
> systemd[1]:
>
>> /[...]/someProject
>>.svn
>>  [...]
>>config
>>  appConfig.xml
>>  upstart.conf
>>  systemd.service
>>startTheApp.sh
> The problem is that "systemd.service" needs the absolute path to
> "startTheApp.sh" in it's file and that path is unknown on commit time,
> because of very generic tags, but known during checkouts and updates.

You have to tell systemd about the location of its config file anyway.
Changing 'svn checkout' to 'svn checkout && install.sh' is surely the
sane way to do this. You have to 'svn update && restart service' too.


> The problem with a build script generating some unversioned file is
> that each user needs to do it for each working copy and each update
> chaning something on the file "systemd.service".

Each user has to check out the working copy, too. There's always some
step that needs to be done first.


-- Brane

Re: File and folder names corrupted when importing from CVS using cvs2svn

[Branko Čibej]

On 24.01.2018 14:11, Nico Kadel-Garcia wrote:
> On Thu, Jan 18, 2018 at 6:55 PM, Daniel Shahaf  
> wrote:
>> Andreas Krey wrote on Thu, 18 Jan 2018 19:14 +0100:
>>> svndumping, filtering and reloading may fix the file names for
>>> all revisions, but I have no idea how the client sandboxes
>>> will react to that.
>> The term is "working copies", and if when changing the history one should
>> 'svnadmin setuuid' the repository, which will cause all network
>> operations from old working copies to error out up front with a UUID
>> mismatch error message (as desired).
> This is also when you rename the upstream Subversion hostname or reset
> the URL for it altogether, so that old and broken working copies are
> reported as completely absent. It helps prevent people from doing an
> "svn switch" and expecting the histories to be consistent, and lets
> them know that the old repository is unusaable: a new working copy
> should be checked out.


Actually one cannot "svn switch" to a repository with a different UUID,
so changing that should be enough.

-- Brane

Re: Exe files corrupted in SVN after import from CVS

[Branko Čibej]

On 22.01.2018 13:48, Nico Kadel-Garcia wrote:
> On Mon, Jan 22, 2018 at 4:38 AM, Bo Berglund  wrote:
>> On Mon, 22 Jan 2018 09:02:44 +, Scott Bloom 
>> wrote:
>>
>>> When I have used cvs2svn, I had a couple of these issues as well..
>>>
>>> It came down to improper settings on the cvs side, but since the
>>> binary files were never modified, there was no corruption due to
>>> cvs thinking it was a text file.
>>>
>>> What I wound up doing, was simply finding all the expected binary
>>> files... and re-checking them in, after the conversion with proper
>>> SVN settings.
>>>
>>> Scott
>>>
>> OK thanks,
>> I have now retrieved the latest CVS file versions on trunk and copied
>> them into my svn working copy with the corrupted exe files so I could
>> commit them to svn. And before I committed them I also explicitly set
>> the file MIME properties to binary (using the SmartSvn properties
>> dialogue).
>> Now when I export trunk they are OK.
>> So at least as long as one stays on trunk these files will be OK.
> That makes sense. I'm glad you were able to work it out.
>
> Some folks, like me, consider EOL reprocessing on checking and
> checkout to be a very dangerous habit and one that should be avoided
> in source control systems, It works great, until it doesn't, as you've
> just found.

... which is precisely why Subversion doesn't do this by default.

But the moral of this whole story is this: After any major surgery on a
version control system — and conversion from one system to another is
certainly major — one should thoroughly verify the result before
bringing it into production.

-- Brane

Re: File and folder names corrupted when importing from CVS using cvs2svn

[Branko Čibej]

On 18.01.2018 17:51, Bo Berglund wrote:
> On Thu, 18 Jan 2018 17:38:04 +0100, Bo Berglund
>  wrote:
>
>> I don't know from where this problem originates, either it is a flaw
>> in the cvs2svn script, the configuration of the conversion or in the
>> format of the generated dump files.
>> Otherwise it may be a problem when importing the dump files into the
>> VisualSVN server
> I made a test by creating a new file in the working copy named as
> follows:
> Testing_Å_Ä_Ö_å_ä_ö.txt
>
> Then I added it and committed.
> Then I used the VisualSVN repository web browser and found the file
> with the correct name. So it seems like the conversion from CVS to Svn
> is where the screw-up is located...

AFAIR you did not convert your CVS repositories on the same machine that
you used as the CVS server, correct? So ... you may not have used the
same character encoding during conversion as during normal operations.
As a guess I'd say that your (Windows, CVSNT) server uss the Windows
Latin 1 ("Western") encoding, and your (Linux) machine where you did the
conversion uses UTF-8.

If that's the case, it's not surprising that accented characters were
converted improperly.

(FWIW, the hex codes you show are valid UTF-8 but the characters they
encode have no relation to the originals.)

> Still, what do I do now?

Two options:

  * If you don't care about history, just rename all the offending files
in the repository to their proper names.
  * If you *do* care about history, repeat the conversion, using the
correct locale settings, then use svnsync to bring the correctly
converted repositories up to date.
  o Alternatively, edit the original dump files and fix the file
names there (they have to be encoded in UTF-8) to avoid having
to repeat the conversion from CVS.

The second option is going to be extremely tricky.


-- Brane

Re: Apache SVN module and LUA authentification hook

[Branko Čibej]

On 05.01.2018 16:00, Stefan Hauffe wrote:
>
> Hello community,
>
>  
>
> I have an Apache 2.4 which shall deliver SVN repos by the
> http-Protocol. I’m experienced with standard Basic Authentification
> and path-based authorization for the Subversion repo.
>
>  
>
> In my new application, the authentication will be done by a LUA-script
> using the directive “LuaHookCheckUserID”. Generally, the LUA script
> works as expected (used this documentation
> ).
>
>  
>
> Unfortunately it seems, that the authorization file (Subversion
> Accessfile) is not read out correctly. I see an empty repo with my
> (authorized) user.
>
>  
>
> From the logfile (Debug/Error) I see, that LUA granted my user. But
> also a “Access denied” message on a SVN file path:
>
>  
>
> [lua:debug] [pid 6872:tid ] @/path/to/hook.lua(29): [client ip]
> Accepted user myuser
>
> [authz_svn:info] [pid 6872:tid ] [client ip] Access granted: 'myuser'
> GET (null)
>
> [authz_svn:debug] [pid 6872:tid ]
> subversion/mod_authz_svn/mod_authz_svn.c(450): [client ip] Path to
> authz file is /path/to/accessfile
>
> [authz_svn:info] [pid 6872:tid ] [client ip] Access denied: - GET
> repo002:/file.txt
>
>  
>
> My simplest working LUA-Scripts goes here:
>
>  
>
> require 'apache2'
>
> function authcheck_hook(r)
>
>     r.user = "myuser"
>
>     r:debug("Accepted user " .. r.user)
>
>     return apache2.OK
>
> end
>

Are you really changing the username stored in the request in your
authentication script? That could certainly be the problem, AFAIK
there's no guarantee that that change gets propagated back to mod_authz_svn.

(It's also a horribly wrong approach to authentication.)

-- Brane

Re: inodes usage of svn server

[Branko Čibej]

On 03.01.2018 22:04, Bo Berglund wrote:
> On Wed, 3 Jan 2018 21:16:02 +0100, Branko ?ibej 
> wrote:
>
>> And there's your answer to the question of day to day performance of the
>> repository: Subversion also has to open many vs. just one file when its
>> reading historical revisions, so packing will definitely help to reduce
>> the number of directory lookups and file opens (the latter are
>> notoriously slow on Windows). Depending on usage patterns, the
>> performance boost may be significant.
> THat seems to be a valid cause for using the function then!
> I will look at my new converted repository in view of this info.
> Thanks!

It's safe to create a post-commit hook that runs 'svnadmin pack'
asynchrouously, or schedule a task that does that (hourly or daily,
depending on your needs). The operation is cheap if it has nothing to do.

-- Brane

Re: inodes usage of svn server

[Branko Čibej]

On 03.01.2018 21:13, Dave Huang wrote:
> On 1/3/2018 13:19, Nico Kadel-Garcia wrote:
>> NTFS also has limits on the maximum number of files for a filesystem.
>
> FWIW, that limit is 2^32 - 1 files, or approximately 4 billion (see
> Table 3.12 of https://technet.microsoft.com/en-us/library/cc938432.aspx)
>
>> There are also notable performance limits on having too many files in
>> a directory.
>
> I don't know enough about NTFS internals to say whether that's the
> case with NTFS or not, but in the context of this discussion, the
> default SVN shard size is 1000 revisions, which I don't think could be
> considered "too many files in a directory".
>
> While I don't have any actual numbers, my gut feeling is that packing
> the repo isn't really needed on NTFS in terms of day to day
> performance of clients using the repo, or in terms of filesystem
> limitations. That said, I do it anyway because backing up the repo
> does go faster when dealing with a couple dozen large files vs. tens
> of thousands of small files.

And there's your answer to the question of day to day performance of the
repository: Subversion also has to open many vs. just one file when its
reading historical revisions, so packing will definitely help to reduce
the number of directory lookups and file opens (the latter are
notoriously slow on Windows). Depending on usage patterns, the
performance boost may be significant.

-- Brane

Re: How to see when an item was added using svnlook?

[Branko Čibej]

On 02.01.2018 13:27, Bo Berglund wrote:
> On Tue, 2 Jan 2018 09:42:07 +0100, Branko ?ibej 
> wrote:
>
>> On 01.01.2018 21:28, Bo Berglund wrote:
>>> I am trying to use svnlook to find the revision when a directory was
>>> created. I want to use this to dig out the timestamps of tags and
>>> branches. My svn version is 1.9.7 (both server and client).
>>> ... and the list continues in *trunk* for about 50 lines ...
>> Yes, that is correct. You asked for the history of the item; it was
>> copied (branched) from trunk in r103, and svnlook is showing the whole
>> history.
> I noted this and asked if there is a way to get the revision when the
> directory was actually ADDED thus making it possible to extract the
> timestamp. I should probably have asked in the subject for the
> *revision* it was added and that would have given me the tool to get
> the other info...
>
>>> Is there a command to show the revision when an item (directory or
>>> file) was actually created in svn?
>> Currently the only hack to do this is by using 'svn log --stop-on-copy'
>> in a working copy.
> This is not going to work on the server using svnlook then
>
>>> If I know the revision I can get additional information using svnlook:
>>>
>>> D:\>svnlook changed -r 699 D:\SVN\test\bosse --copy-info
>>> A + CVSMailer/tags/Rel_1-5-2-50_20060422/
>>> (from CVSMailer/trunk/:r698)
>>>
>>> But lacking the revision number when it was added I cannot  find the
>>> extra info like the date...
>> "The date" is a revision property.
> But I am looking for a way to find the revision so this timestamp I am
> after can be extracted...
>
>> What are you actually trying to achieve?
> Apart from the timestamp I want for other purposes I am also after the
> revision for a changed file when it was last changed (forgot this when
> posting).
> So I want to create a commit email including info that we are used to
> having in the emails we get from our earlier system.
> This includes a list with the following for each changed item:
>
>   -Item that was changed (dir or file, available in svnlook changed) 
>   -revision it was changed (i.e. the commit revision - simple)
>   -revision it was last changed before this commit (how to do this?)
>   -a command to diff the new file version with the previous

Oh for goodness' sake, please use an existing mailer script that already
does all of that. Don't reinvent the wheel. The mailer we have in the
Subversion repository shows the log message, what changed in the commit
and the complete diff; you could easily adapt it for your needs.

("revision it was last changed before this commit ... I'm not sure why
you need this info; you don't need it to generate the diff.)

> Not for me because all the hook scripts I have looked at are either
> too simplistic (basically pushing svnlook info and svnlook changed
> into the mail body) or they are written in a language I do not
> master...

Well here I can't help you other than to suggest that "mastering" a
language is not a prerequisite to customizing a script. Python isn't
that hard to understand.

Alternatively, you could investigate some existing freely (or not so
freely) available development tools that have all this integrated. I
won't post links to commercial offers on this list, but they're just one
search away.

-- Brane

Re: How to see when an item was added using svnlook?

[Branko Čibej]

On 02.01.2018 13:29, Bo Berglund wrote:
> On Tue, 02 Jan 2018 09:59:15 +, Daniel Shahaf
>  wrote:
>
>> Branko ?ibej wrote on Tue, 02 Jan 2018 09:42 +0100:
>>> On 01.01.2018 21:28, Bo Berglund wrote:
 Is there a command to show the revision when an item (directory or
 file) was actually created in svn?
>>> Currently the only hack to do this is by using 'svn log --stop-on-copy'
>>> in a working copy.
>> Wouldn't 'svn log --stop-on-copy URL' work?
>>
>> There's also this (not immediately obvious) command for showing the
>> revision that created TARGET at that location, via a copy or otherwise:
>>
>>svn log -r 0:HEAD -q -v --stop-on-copy --limit=1 -- TARGET
> I believe this only works in a working copy, not on the server in a
> hook...

Yes it does work on the server in a hook if TARGET is an URL.

$ svn log -r 0:HEAD -q -v --stop-on-copy --limit=1 
https://svn.apache.org/repos/asf/subversion/branches/1.10.x

r1817773 | julianfoad | 2017-12-11 14:22:31 +0100 (Mon, 11 Dec 2017)
Changed paths:
   A /subversion/branches/1.10.x (from /subversion/trunk:1817772)



Of course, on the server, you can use a file:// URL to avoid looping
through HTTP(S).

-- Brane

Re: How to see when an item was added using svnlook?

[Branko Čibej]

On 02.01.2018 10:59, Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, 02 Jan 2018 09:42 +0100:
>> On 01.01.2018 21:28, Bo Berglund wrote:
>>> Is there a command to show the revision when an item (directory or
>>> file) was actually created in svn?
>> Currently the only hack to do this is by using 'svn log --stop-on-copy'
>> in a working copy.
> Wouldn't 'svn log --stop-on-copy URL' work?

It would ... I just didn't want to confuse the issue by introducing the
not-so-subtle difference between the "client" and the "working copy."


> There's also this (not immediately obvious) command for showing the
> revision that created TARGET at that location, via a copy or otherwise:
>
> svn log -r 0:HEAD -q -v --stop-on-copy --limit=1 -- TARGET

Indeed, that's a better hack.

-- Brane

Re: How to see when an item was added using svnlook?

[Branko Čibej]

On 01.01.2018 21:28, Bo Berglund wrote:
> I am trying to use svnlook to find the revision when a directory was
> created. I want to use this to dig out the timestamps of tags and
> branches. My svn version is 1.9.7 (both server and client).
>
> So far I have not found a way to do it...
>
> svnlook history  /branches/
> shows a lot of revisions which are for changes to any file within the
> directory, but not the addition commit for the actual directory itself
> AND unrelated directories (the command below is on one line):

The directories are not unrelated.

> D:\>svnlook history D:\SVN\test\bosse
> /CVSMailer/branches/Branch_Rel_1-2-9 -l 5
> REVISION   PATH
>    
>  120   /CVSMailer/branches/Branch_Rel_1-2-9
>  119   /CVSMailer/branches/Branch_Rel_1-2-9
>  103   /CVSMailer/branches/Branch_Rel_1-2-9
>  100   /CVSMailer/trunk
>   98   /CVSMailer/trunk
> ... and the list continues in *trunk* for about 50 lines ...

Yes, that is correct. You asked for the history of the item; it was
copied (branched) from trunk in r103, and svnlook is showing the whole
history.

> Is there a command to show the revision when an item (directory or
> file) was actually created in svn?

Currently the only hack to do this is by using 'svn log --stop-on-copy'
in a working copy.

> I have read the whole SVNBook 1.7 chapter on svnlook but did not find
> an obvious candidate.
>
> If I know the revision I can get additional information using svnlook:
>
> D:\>svnlook info -r 699 D:\SVN\test\bosse
> cvs2svn
> 2006-04-22 23:17:29 +0200 (lö, 22 apr 2006)
> 79
> This commit was manufactured by cvs2svn to create tag
> 'Rel_1-5-2-50_20060422'.
>
> D:\>svnlook changed -r 699 D:\SVN\test\bosse --copy-info
> A + CVSMailer/tags/Rel_1-5-2-50_20060422/
> (from CVSMailer/trunk/:r698)
>
> But lacking the revision number when it was added I cannot  find the
> extra info like the date...

"The date" is a revision property.

What are you actually trying to achieve? There's a good chance that
whatever you're trying to use svnlook for has already been implemented
half a dozen times, using an existing tool might get you to your goal
quite a bit faster.

-- Brane

Re: Issue parsing url with '+' in it

[Branko Čibej]

On 30.12.2017 20:35, John McClean wrote:
> I'm trying to checkout/export part of a github repo.
>
> svn export "https://github.com/apache/avro.git/trunk/lang/c++;
>
> This creates a directory but doesn't get any files. It work fine for
> urls which don't have a '+' in them.
>
> URI encoding the '+'s doesn't change the behavior.
>
> Any ideas?

Report a bug to GitHub, their Subversion protocol is a custom
implementation that AFAIK is not based on our code.

-- Brane

Re: make -j16 javahl sometimes failed for subversion-1.9.7

[Branko Čibej]

On 31.12.2017 13:42, wuzhouhui wrote:
> I'm using rpmbuild to build a package for subversion-1.9.7, but sometimes 
> building will failed when make -j16 javahl:
>
> Error: Class org.apache.subversion.javahl.ClientNotifyInformation could not 
> be found.
> make: *** 
> [subversion/bindings/javahl/include/org_apache_subversion_javahl_callback_PatchCallback.h]
>  Error 1
> make: *** Waiting for unfinished jobs
> 1 warning
>
> Configure arguments as follows:
>
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --disable-mod-activation 
> --with-berkeley-db --with-apxs=/usr/sbin/apxs 
> --with-apr=/usr/bin/apr-1-config --with-apr-util=/usr/bin/apu-1-config 
> --with-apache-libexecdir=yes --with-gnome-keyring --enable-javahl 
> --with-jdk=/usr/lib/jvm/java-1.7.0-openjdk.x86_64 --without-jikes 
> --with-sqlite=sqlite-amalgamation/sqlite3.c --with-serf
>
> and make -j16 javahl is the first step in section %build.


The RPM config is wrong. Our JavaHL build is not parallel-safe and
should be built single-threaded. I believe the same may be true of the
Swig bindings, but I'm not sure about that.

-- Brane