Re: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Daniel Sahlberg]

Den fre 17 maj 2024 kl 00:20 skrev Williams, James P. {Jim} (JSC-CD4)[KBR
Wyle Services, LLC] via users :

> > BTW: as Daniel asked: You previously mentioned Subversion 1.14.1, is
> > that on the server or on the client?
>
> I've been testing with SVN 1.14.1 on both the client and server.
>

Perfect, thanks for confirming. Do you happen to know what version of Serf
is used on the client and what version of OpenSSL do you have on the
client/server?


>
> > Regardless, since the issue manifests on the client-side by hangs and
> > crashes while waiting for / processing data from the server (hangs
> > inside libsvn_ra_serf), I'd suggest also to investigate whether there
> > is something in between your client and your server that might be
> > interfering. A proxy or reverse proxy perhaps? Or some security
> > software on the client that interferes with the network (as some
> > antivirus suites do on Windows)? If so, try to bypass it (or disable /
> > create an exclude rule), as a diagnostic step to see whether this
> > might be the cause.
>
> I don't think we have anything inserted between client and server, but
> will ask those smarter than me if they know of such a thing.
>
> I do have an update.  My system administrator was surprised to see the
> server machine configured to support both version 4 and 6 IP addresses.  He
> thought the latter were turned off.  After that change, checkouts were
> noticeably faster, and hangs and crashes were noticeably less frequent.
> The repo size needed to trigger them appeared to grow some.  Though a step
> forward, the configuration still isn't useable.  It might also point at
> further network configuration problems as a cause, though the SVN client
> probably shouldn't crash in any case.
>

Are the client and the server both "close" (networkwise) or do they
communicate over a WAN/internet link?

Is it possible to - at least temporarily - add a VHost without SSL
encryption to see if this makes a difference? That would also make it
easier to catch the traffic using Wireshark to see the last packages before
a crash. In particular, I'm interested in the content of the packages that
trigger the xml parsing error (the call to svn_xml_parse). For the cases
when it hangs, does one side say "goodbye" (ie, FIN) or does it seem like
package drops (ie, traffic just stops flowing).

When it hangs, does it ever release? I would assume that the client would
finally time out.

Kind regards,
Daniel

Re: PoshSvn – Subversion for PowerShell

[Daniel Sahlberg]

Den fre 17 maj 2024 kl 06:45 skrev Nathan Hartman :

> On Thu, May 16, 2024 at 1:50 PM Timofey Zhakov  wrote:
> >
> > Hello everyone!
> >
> > I like Subversion and use it for my projects.
> >
> > PoshSvn is a PowerShell module which provides a tab competition and
> > typed output for the Subversion cmdlets. I found it useful for
> > scripting and everyday life.
> >
> > For example to get the status of a working copy, you could use the
> > svn-status cmdlet:
> >
> > [[[
> > PS C:\> svn-status
> >
> > Status  Path
> > --  
> > M   PoshSvn\CmdLets\SvnAdd.cs
> > M   PoshSvn\CmdLets\SvnLog.cs
> > M   PoshSvn\SvnCmdletBase.cs
> > M   README.md
> > ]]]
> >
> > This is useful for scripting because of typed output. For example:
> >
> > [[[
> > PS C:\> $info = svn-info https://svn.apache.org/repos/asf
> > PS C:\> $info.Revision
> > 1917749
> > PS C:\> $info.LastChangedAuthor
> > projects_role
> > ]]]
> >
> > Documentation is available at: https://www.poshsvn.com/
> >
> > The installation is very easy. Just type `Install-Module PoshSvn` in
> > the PowerShell command prompt.
> >
> > This module is fully free and open source.
> >
> > Any kind of feedback would be much appreciated.
> >
> > Thanks!
> >
> > --
> > Timofei Zhakov
>
>
> Thanks for sharing!
>
> I'm not a Windows user or a PowerShell user so I can't try it out for
> myself, but I am always glad to hear about new additions to the
> Subversion ecosystem.
>
> If you ever feel like participating in Subversion development, there
> are plenty of opportunities around here :-)
>
> Cheers,
> Nathan
>

Dear Timofei,

Very impressive work and I think this is the biggest addition to the
Subversion ecosystem in may years.

I'm a Windows user although I use PowerShell way to seldom. I will try to
find time to test this out a little bit in the next few weeks.

I was thinking about adding a link to your project on the Subversion
website. There is already page for Binary packages[1] and this would make a
nice addition. (Although, we have previously limited that page to strictly
Apache Subversion builds and this a different kind of client, so we might
have to create a new page for "ecosystem" - this should be discussed in the
dev@ list).

Kind regards,
Daniel Sahlberg

[1] https://subversion.apache.org/packages.html

Re: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Daniel Sahlberg]

Hi,

I've added a few comments/questions below.

Kind regards,
Daniel Sahlberg

Den lör 11 maj 2024 kl 03:00 skrev Williams, James P. {Jim} (JSC-CD4)[KBR
Wyle Services, LLC] via users :

> > How did you upgrade your server from RHEL 6 to RHEL 8?
>
> Because so much changed from RHEL 6 to 8, including Apache from 2.2.15 to
> 2.4.37, all the Apache modules, etc., I started from the skeleton
> configuration the operating system provides and made mostly the same
> customizations we had for RHEL 6, or modernized them where the docs said
> things changed.  Mostly, that was tweaks to authentication (from LDAP to
> Kerberos), SSL, and the SVN endpoints.  Browser access to all SVN and
> ViewVC pages seems to work fine.
>

You previously mentioned Subversion 1.14.1, is that on the server or on the
client?

[...]

> And do the problems happen if you use svn:// rather than https:// ?
>
> I thought svn:// worked only with svnserve, which we don't run.  Are you
> suggesting I try to run it as a test, or that I consider abandoning Apache
> in favor of it?  Yikes; that'd be painful.
>
> I hear you on the HTTP integration.  We have about 2000 repos and a few
> hundred developers.  I've supported that server for at least 15 years, and
> it hasn't been too bad...until now.
>

I have personally only ever used Subversion over http/https (except for
testing purposes) and I haven't had any of the problems described by Nico -
I guess YMMV...

Still it would be interesting to compare just to rule out a problem within
the repository. You can use svnserve directly or tunneled over SSH, see the
Subversion book:

https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth



> On Fri, May 10, 2024 at 4:17 PM Williams, James P. {Jim} (JSC-CD4)[KBR
> Wyle Services, LLC] via users  wrote:
> >
> > I'm upgrading an Apache HTTP server of our SVN repos on RedHat
> Enterprise Linux 8.  Using Subversion 1.14.1, svn checkout of even a small,
> simple repo with about 150 files hangs about 90% of the time, crashes 5%,
> and succeeds 5%.  Given enough time, the hangs eventually time out after
> checking out much of the repo.  A debugger shows the following stack during
> the hang.
> >
> >
> >
> >   #0  epoll_wait   /usr/lib64/libc.so.6
>

Waiting for a reply from the server ... ?

Do you see any activity on the server (CPU / disk) during this time?


> >
> >   #1  impl_pollset_poll/usr/lib64/libapr-1.so.0
> >
> >   #2  serf_context_run /usr/lib64/libserf-1.so.0
> >
> >   #3  svn_ra_serf.context_run  /usr/lib64/libsvn_ra_serf-1.so.0
> >
> >   #4  finish_report/usr/lib64/libsvn_ra_serf-1.so.0
> >
> >   #5  svn_wc_crawl_revisions5  /usr/lib64/libsvn_wc-1.so.0
> >
> >   #6  update_internal.isra /usr/lib64/libsvn_client-1.so.0
> >
> >   #7  svn_client.update_internal   /usr/lib64/libsvn_client-1.so.0
> >
> >   #8  svn_client.checkout_internal /usr/lib64/libsvn_client-1.so.0
> >
> >   #9  svn_client_checkout3 /usr/lib64/libsvn_client-1.so.0
> >
> >   #10 svn_cl.checkout
> >
> >   #11 sub_main
> >
> >   #12 main
> >
> >
> >
> > strace shows repeated calls to epoll_wait about 1 sec apart.
> >
> >
> >
> > When the checkout crashes, it's a SIGSEGV with this stack,
> >
> >
> >
> >   #0  apr_pool_create_ex(libapr-1.so.0)
>

Memory allocation?


> >
> >   #1  svn_pool_create_ex(libsvn_subr-1.so.0)
> >
> >   #2  update_opened (libsvn_ra_serf-1.so.0)
> >
> >   #3  expat_start   (libsvn_ra_serf-1.so.0)
>

Parsing the XML message from the server?

Can you catch/view the actual XML message sent from the server? I'm
thinking if this is mangled in some strange way that is upsetting the XML
parser.


> >
> >   #4  expat_start_handler   (libsvn_subr-1.so.0)
> >
> >   #5  doContent (libexpat.so.1)
> >
> >   #6  contentProcessor  (libexpat.so.1)
> >
> >   #7  XML_ParseBuffer   (libexpat.so.1)
> >
> >   #8  svn_xml_parse (libsvn_subr-1.so.0)
> >
> >   #9  expat_response_handler(libsvn_ra_serf-1.so.0)
> >
> >   #10 process_buffer.isra.9 (libsvn_ra_serf-1.so.0)
> >
> >   #11 finish_report (libsvn_ra_serf-1.so.0)
> >
> >   #12 svn_wc_crawl_revisions5   (libsvn_wc-1.so.0)
> >
> >   #13 update_inte

Re: TortoiseSVN & Office 365 Single Sign-On

[Daniel Sahlberg]

Den tis 30 apr. 2024 kl 05:37 skrev Jason Vietri <
jason.vie...@certcentercanada.com>:

> Hi everyone,
>
> Is there a way to configure Office 365 Single Sign-On within TortoiseSVN
> so our users can be authenticated using their Office 365 credentials? I
> appreciate your help.
>
> Thank you all for your time and effort. I hope you have a wonderful day!
>
>
>
> Jason Vietri
>


Hi,

I saw you also posted on the TortoiseSVN forums (
https://groups.google.com/g/tortoisesvn/c/bfBdlKdSzbw). As I replied there,
this was discussed a while back (
https://groups.google.com/g/tortoisesvn-dev/c/ByECclvGKi8) and also on the
Subversion dev list (
https://lists.apache.org/thread/f3f516vkm16ss67g9xfrjrfdcp70ymd0).

I'm very interested in getting this working but unfortunately I don't have
much time to do it myself right now.

Kind regards,
Daniel Sahlberg




> IT & Security Manager
>
> 514-578-7864
>
> 450-441-6464 x413
>
> jason.vie...@certcentercanada.com
>
> Book time with Jason Vietri
> <https://outlook.office.com/bookwithme/user/1b009fddf3f941119ffa124cdf54a...@certcentercanada.com?anonymous=plink>-
> https://bit.ly/vietri
>
> [image: signatureImage]
>
>
>
> *Cert Center Canada <http://www.certcentercanada.com/>*
>
> 50 Chemin de la Rabastalière est, suite 23A
>
> Saint-Bruno-de-Montarville  QC  J3V 2A5
>
> Canada
>
>
>

Re: Error | svnauthz: E220003: Section appears more than once in the authz file: [groups]

[Daniel Sahlberg]

Den ons 17 apr. 2024 kl 15:32 skrev BK :

> Hello Pavel,
>
> That is the question.
> Is it possible in version 1.14 to keep this format
> (per repository) as it is possible in version 1.8?
> I think this is clearer with a large number
> of repositories on the server.
>
The code as it is now seems to be very intentionally written to NOT allow
multiple sections with the same name, see the check_open_section() function
in authz_parse.c[1].

I don't know if it would be possible to relax this restriction but feel
free to take a look at the code and send a patch to
d...@subversion.apache.org.

It is not possible to switch back to the old authz parse code in version
1.14.

Kind regards,
Daniel



[1]
https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_repos/authz_parse.c?revision=1875971=markup#l310



> Regards,
> Bernhard
>
>
> Am 17.04.24 um 14:16 schrieb Pavel Lyalyakin:
>
> On Wed, 17 Apr 2024 at 15:08, BK   wrote:
>
> Hello,
>
> After the change from Subversion 1.8 to 1.14 on my server
> the access rights definitions in the svn_access_file
> no longer work.
> The following error message appears:
> [authz_svn:error] Failed to load the mod_authz_svn config: Error while 
> parsing config file: '/opt/csvn/release/data/conf/svn_access_file': svnauthz: 
> E220003: Section appears more than once in the authz file: [groups]
>
> Is it no longer possible to define groups more than once
> per repository in the acccess file? I find this style
> more clearly organised, than to separate all groups
> of the repos and the corresponding access rights
> separate.
>
> Is there a possibility to stay in the old format (Subvesion 1.8)?
>
> Here is an extract from the svn_access_file file.
>
> ##
> # server administrators
> ##
> [groups]
> ApplicationServerAdmins = svnadm, admim1
>
> # ---
> # access rules for entire server content
> # ---
> [/]
> @ApplicationServerAdmins = rw
>
>
> ##
> # test1
> ##
> [groups]
> test1_Administration = @ApplicationServerAdmins, user1
> test1_Users = user1
>
> # ---
> # access rules
> # ---
> [test1:/]
> @test1_Administration = rw
> [test1:/tags/to1/t1]
> @test1_Users = rw
>
>
> ##
> # jira_test
> ##
> [groups]
> jira_test_Administration = @ApplicationServerAdmins, admin2
> jira_test_Developer = user2
>
> # ---
> # access rules
> # ---
> [jira_test:/]
> @jira_test_Administration = rw
> @jira_test_Developer = rw
>
>
> Thanks for your help,
> Bernard
>
> I'm not familiar with this particular issue and the error message. But
> why does your authz file have multiple [groups] sections? I think that
> you should clean up the file and 1) Remove unnecessary entries. 2)
> Group all group definitions in a single [groups] section.
>
>
>

Re: Feature request: distinguish between disconnect to server and to proxy

[Daniel Sahlberg]

Den tors 11 apr. 2024 kl 19:17 skrev Mikhail Dvorkin <
mikhail.dvor...@gmail.com>:

> I received this error when doing 'svn update':
>
> svn: E170013: Unable to connect to a repository at URL …
>
> I spent many minutes trying to find why the perfectly working server
> would not grant a connection.
>
> The solution was: for years in my TortoiseSVN settings a proxy server
> was selected, and it simply has been working until it happened to be
> turned off.
>
> So I ask for one of two features:
>
> A) When "unable to connect to a server", make an extra check whether
> it is possible to connect to the proxy server (if one is selected). If
> this is the case, make the error more verbose, like:
>
> svn: E170013: Unable to connect to a repository at URL …, also unable
> to connect to a proxy …
>
> B) Simply make the error message more verbose if the proxy server is
> selected in the settings, like:
>
> svn: E170013: Unable to connect to a repository at URL …
> (Note: proxy … was used for connection)
>

Hi,

While I think the idea in principle sounds good, I think the impact is
rather limited. Considering the low number of active contributors in the
project, I'm not sure if anyone will step up to actually implement this,
sorry.

On the other hand, this is a REALLY good place to start if you would like
to get involved in Subversion development. A patch would be more than
welcome on d...@subversion.apache.org.

I took a quick look at the code and I think the error comes from the call
to serf_connection_create2() in /subversion/libsvn_ra_serf/serf.c (see
[1]). You probably need to create a new error code and then check for this
error code in /subversion/libsvn_ra/ra_loader.c (see [2]).

Kind regards,
Daniel

[1]
https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_serf/serf.c?revision=1905955=markup#l567
[2]
https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra/ra_loader.c?revision=1905955=markup#l390

Re: Repo access with HTTPS and an access token (or: GCM for svn?)

[Daniel Sahlberg]

Den fre 29 mars 2024 kl 16:27 skrev EML :

> Before I do too much work on this, I'd like to do a sanity check. Does
> anyone know of a client which will access a repo over HTTPS, with an
> access/bearer token? This gives SSO and multi-factor authentication using
> OAuth2.
>
> The repo runs behind Apache httpd, which is using mod_auth_openidc. The
> config file sets 'AuthType openid-connect', and 'Require valid-user'. The
> repos additionally require a specific claim to access them ('Require claim
> x:y:z').
>
> This all works with git, using Git Credential Manager
>  (GCM; this is a
> cross-platform .NET Core app).
>
> Basically, two things need to be done:
>
> (1) HTTP requests need to specify 'Authorization: Bearer' with an access
> token. If you don't have an access token, something (a script, GCM,
> whatever) has to pop up a browser window and connect to an OAuth2 identity
> provider (IdP). The user then logs in (with MFA if configured), and the IdP
> then redirects back to localhost with a token. This means that the 'script'
> must also run a webserver to extract the token, which it can then add to
> the GET/POST/whatever request.
>
> (2) Subversion has to know about this in some way, and has to run the
> script to use a previously-generated token, or request a new one if
> necessary.
>
> The first step is not, I think, particularly difficult, and there are
> various existing scripts or apps out there that do some or all of the
> problem. GCM itself looks pretty complex. I'm not really sure what the
> complexity is. The choice to use .NET doesn't help (but it has to be
> multi-platform), but a lot of the complexity is presumably in how to use
> the credential manager to store tokens. There's also some complexity in
> handling different targets (GitHub, Bitbucket, Azure, whatever). However,
> there is a generic setup (which I use; this talks to Keycloak). My entire
> config (.gitconfig) to talk to Keycloak looks this:
>
> [credential]
> helper = cache --timeout 7200
> helper = "oauth"
>
> [credential ""]
> oauthScopes   = "openid email"
> oauthAuthURL  =
> /keycloak/realms//protocol/openid-connect/auth
> oauthTokenURL =
> /keycloak/realms//protocol/openid-connect/token
> oauthClientId = openid-cli
> oauthRedirectUri  = http://127.0.0.1
> oauthClientSecret = 
>

This was actually discussed over on the TortoiseSVN dev list today in the
following thread https://groups.google.com/g/tortoisesvn-dev/c/ByECclvGKi8

I think the steps outlined by Thomas Åkerström is quite similar to what you
are also suggesting.

This should probably be discussed further on d...@subversion.apache.org.

Kind regards,
Daniel

Re: SVN does not trust cert

[Daniel Sahlberg]

Den mån 25 mars 2024 kl 16:34 skrev Stanley Gilliam <
stanley.x.gill...@gsk.com>:

> Hello,
>
>
>
> So we use appview to update our certificates and our cert team confirmed
> that the cert was updated correctly. Is there another way to possibly
> verify this. There may also be something to the second option, I am on a
> linux RH OS. Is there a way someone could jump on a short call with us?
>

What if you run the same command as Jeffrey already tries, ie:

$ openssl s_client -connect hpc.gsk.com:443 -servername hpc.gsk.com

(I had to Ctrl-D out of the above command). I'm not familiar with openssl
debugging but there seems to be a lot of useful information on the
certificate chain. Verify that all the intermediary certificates are
available and that the root certificate is trusted by your client.

Kind regards,
Daniel





>
>
> Stanley Gilliam
>
> System Administrator
>
> GSK
>
> 14200 Shady Grove Rd
>
> Rockville, MD 20850
>
> 678-548-7768
>
>
>
> *From:* Daniel Sahlberg 
> *Sent:* Monday, March 25, 2024 11:17 AM
> *To:* noloa...@gmail.com
> *Cc:* Stanley Gilliam ;
> users@subversion.apache.org
> *Subject:* Re: SVN does not trust cert
>
>
>
> Den mån 25 mars 2024 kl 15: 19 skrev Jeffrey Walton  com>: On Mon, Mar 25, 2024 at 9: 54 AM Stanley Gilliam via users  subversion. apache. org> wrote: > > I am a system admin for
> GlaxoSmithKline. We are currently
>
> Den mån 25 mars 2024 kl 15:19 skrev Jeffrey Walton :
>
> On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
>  wrote:
> >
> > I am a system admin for GlaxoSmithKline. We are currently having issues
> getting our svn instance to authenticate. This all happened after the cert
> was updated. We are currently getting the message :
> >
> > svn: E175002: OPTIONS of 'https://hpc.gsk.com/xxx/xxx/etc': Server
> certificate verification failed: issuer is not trusted (
> https://hpc.gsk.com)
> >
> > The cert was updated correctly we believe because the website works.
> >
> > is there anybody that may be able to help?
>
> DNS seems to be a problem:
>
> $ openssl s_client -connect hpc.gsk.com:443 -servername hpc.gsk.com
> 40D7F6E4F171:error:10080002:BIO routines:BIO_lookup_ex:system
> lib:../crypto/bio/bio_addr.c:738:Name or service not known
> connect:errno=22
>
> And:
>
> $ nslookup hpc.gsk.com
> Server: 127.0.0.53
> Address:127.0.0.53#53
>
> ** server can't find hpc.gsk.com: NXDOMAIN
>
> You should add a DNS entry for the host 'hpc'. Then, rerun the experiment.
>
>
>
> It might be that the hpc.gsk.com domain is only available on an internal
> network (ie, on an internal DNS server). If there was a missing DNS entry
> you should get an error message similar to this:
>
>
>
> $ svn ls https://hpc.gsk.com
>
> svn: E170013: Unable to connect to a repository at URL '
> https://hpc.gsk.com'
>
> svn: E670002: Name or service not known
>
> $
>
>
>
> (The missing DNS entry makes it more difficult for someone outside of the
> company to help in debugging of course!).
>
>
>
> "issuer is not trusted" sounds to me like it is a self-signed certificate
> or that the certificate is signed by a root that isn't trusted by the
> client. Can you verify that the client really trust the issuer of the
> certificate?
>
>
>
> Another potential explanation (although not supported by the available
> evidence) is that there is a mismatch between the cipher of the new
> certificate compared to what OpenSSL on the client is supporting.
>
>
>
> Which platform are you on and what are the versions of Subversion and the
> linked OpenSSL library?
>
>
>
> Kind regards,
>
> Daniel
>
>
>
> *GSK monitors email communications sent to and from GSK in order to
> protect GSK, our employees, customers, suppliers and business partners,
> from cyber threats and loss of GSK Information. GSK monitoring is conducted
> with appropriate confidentiality controls and in accordance with local laws
> and after appropriate consultation.*
>

Re: SVN does not trust cert

[Daniel Sahlberg]

Den mån 25 mars 2024 kl 15:19 skrev Jeffrey Walton :

> On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
>  wrote:
> >
> > I am a system admin for GlaxoSmithKline. We are currently having issues
> getting our svn instance to authenticate. This all happened after the cert
> was updated. We are currently getting the message :
> >
> > svn: E175002: OPTIONS of 'https://hpc.gsk.com/xxx/xxx/etc': Server
> certificate verification failed: issuer is not trusted (
> https://hpc.gsk.com)
> >
> > The cert was updated correctly we believe because the website works.
> >
> > is there anybody that may be able to help?
>
> DNS seems to be a problem:
>
> $ openssl s_client -connect hpc.gsk.com:443 -servername hpc.gsk.com
> 40D7F6E4F171:error:10080002:BIO routines:BIO_lookup_ex:system
> lib:../crypto/bio/bio_addr.c:738:Name or service not known
> connect:errno=22
>
> And:
>
> $ nslookup hpc.gsk.com
> Server: 127.0.0.53
> Address:127.0.0.53#53
>
> ** server can't find hpc.gsk.com: NXDOMAIN
>
> You should add a DNS entry for the host 'hpc'. Then, rerun the experiment.
>

It might be that the hpc.gsk.com domain is only available on an internal
network (ie, on an internal DNS server). If there was a missing DNS entry
you should get an error message similar to this:

$ svn ls https://hpc.gsk.com
svn: E170013: Unable to connect to a repository at URL 'https://hpc.gsk.com'
svn: E670002: Name or service not known
$

(The missing DNS entry makes it more difficult for someone outside of the
company to help in debugging of course!).

"issuer is not trusted" sounds to me like it is a self-signed certificate
or that the certificate is signed by a root that isn't trusted by the
client. Can you verify that the client really trust the issuer of the
certificate?

Another potential explanation (although not supported by the available
evidence) is that there is a mismatch between the cipher of the new
certificate compared to what OpenSSL on the client is supporting.

Which platform are you on and what are the versions of Subversion and the
linked OpenSSL library?

Kind regards,
Daniel

Re: E200004 error during commit

[Daniel Sahlberg]

Den tors 14 mars 2024 kl 05:22 skrev Robin :

> Hi,
>
> when committing to folder, I get a
>
> Commit failed (details follow):
> Invalid L2P offset in r320 footer
> Could not convert '�x�ț���C � Y+�
>  ��ׁ%�?�l��\wH ��O3D�� b�4 �z ͦcr42 �Z2� �9g�,h$c
>  �yM .��"�?z��X: ~j� m�S  �' into a number
>
> svnadmin verify gives
>
>
> * Verifying metadata at revision 0 ...
> * Error verifying repository metadata.
> svnadmin: E24: Invalid L2P offset in r319 footer
> svnadmin: E24: Could not convert
> 'L��>q��y���B�|Q�`E⌂♠A�r�Y�X1V}���g6.�☼�ݥ�♂�M�,♫�]I̠◄�8►�ِ���Ya↕4♠�%��e�'��XRf1�◄��OY�D`F�',►VRG�޾�]u'
>
> into a number
>
>
> SVN 1.14.2
>
> Robin
>
>
Hi,

I believe this unfortunately means your repository is corrupt. If you have
a backup of the repository, the easiest way is probably to restore the
backup.

If you don't have a backup and have to try to manually restore the
repository, Daniel Shahaf goes into quite a bit of detail in these previous
threads on the mailing list:

https://lists.apache.org/thread/8sokdqly67db11g6vs5v547xwz1hrp74
https://lists.apache.org/thread/0y7kpppv3f0ms301m13pw0qybr47wjb4

Maybe these can help you to figure out the correct value of the L2P offset?

Kind regards,
Daniel Sahlberg

Re: SVN log --xml version omits line count

[Daniel Sahlberg]

Den tis 5 mars 2024 kl 18:09 skrev sebb :

> I would expect svn log --xml to include all the same info as the
> non-xml version, but that is not the case. The number of lines changed
> is not visible in the xml version.


The figure is the number of lines in the log message, not the number of
changed lines in the commit.


>
> Is that intentional?

If so, why?
>

One could imagine that a parser of the text output would like to know the
number of lines to read before expecting the next log message. (Looking for
""
could break down if someone has that exact string in a log message).

With XML, there is no need to know how long the log message is; a
well-behaved parser should be able to find out.

Kind regards,
Daniel


> Sebb
> Sample outputs below
> -
>
> $ svn log https://svn.apache.org/repos/asf/subversion/trunk/NOTICE
> -r1914220
> 
> r1914220 | hartmannathan | 2023-11-30 04:47:33 + (Thu, 30 Nov
> 2023) | 6 lines
>
> Update copyright year to 2023.
>
> * NOTICE,
> * subversion/libsvn_subr/version.c (svn_version_extended):
> Bump copyright year to 2023.
>
> 
>
> $ svn log https://svn.apache.org/repos/asf/subversion/trunk/NOTICE
> -r1914220
>  --xml
> 
> 
> revision="1914220">
> hartmannathan
> 2023-11-30T04:47:33.883414Z
> Update copyright year to 2023.
>
> * NOTICE,
> * subversion/libsvn_subr/version.c (svn_version_extended):
> Bump copyright year to 2023.
> 
> 
> 
>

Re: Moved file resolution fails

[Daniel Sahlberg]

fre 2 feb. 2024 kl. 06:52 skrev Sands, Daniel N. via users <
users@subversion.apache.org>:

> > As far as I'm aware this is all client-side behavior - nothing to do
> with the server. Resource move/rename
> > has always been recorded as a _Delete_ of the original path and a _Copy_
> (Add) from the previous path
> > revision. It could be I'm missing something here, also.
>
> As of 1.8, it now knows if an add or delete was due to a move.  For
> example, on my RHEL8 system that has 1.10, a move will look like this in
> status:
>
> Dfoo/bar
>   > moved to baz/bar
> Abaz/bar
>   > moved from foo/bar
>
> If I use this tree to update from even the 1.7 server, conflict resolution
> can find the change in the trunk to foo/bar/example.c and rewrite it to
> baz/bar/example.c.  The conflict resolution gives me the option to
> (u)pdate the destination of the change.
>
> However, if I check out my local branch from 1.7, the above 'moved'
> information is lost.


Which version are you using on the client side? Can you show the output of
svn —version?

Kind regards
Daniel Sahlberg

And in that case, conflict resolution fails.  There is a
> published paper that 1.8+ clients implement in resolving the new path in
> the absence of the 'moved' information.  It involves a heuristic where
> 1) the delete and the add must happen in the same checkin
> 2) the adds will be searched for some kind of common ancestry that can be
> used to match the add to the delete
>
> But whatever was implemented, the tree conflict search does not seem to
> find its common ancestry.  In addition, the example.c file modification
> record is lost, so after resolving the tree conflict there is still an
> incomplete merge even though it has the merge info recorded.
>
>

Reintegrate can only be used if revisions XX through YY were previously merged ...

[Daniel Sahlberg]

Hi,

I'm trying to do a catchup merge between two branches (incidentally within
the Subversion website tree) but I fail and I don't have enough
understanding to know what is wrong.

I have a working copy from https://svn.apache.org/repos/asf/subversion/site

In $WC/staging/, I run:
[[[
$ svn merge ^/subversion/site/publish
svn: E195016: Reintegrate can only be used if revisions 1812681 through
1915353 were previously merged from
https://svn.apache.org/repos/asf/subversion/site/staging to the reintegrate
source, but this is not the case:
  subversion/site/publish
Missing ranges:
/subversion/site/staging:1898163-1898164,1898168,1898183,1899002,1899183,1899186,1899621,1905961,1905965,1909457
]]]

The listed revisions all seem to be authored directly in staging and not
yet merged to publish (related to the upcoming 1.15 release).

What has gone wrong and what can we do to get back into a working state?

Kind regards,
Daniel Sahlberg

Re: [ANNOUNCE] Apache Subversion 1.14.3 released

[Daniel Sahlberg]

Den mån 15 jan. 2024 kl 20:44 skrev Dunnill, Robert :

> Is a document available on how to update Apache under Subversion Edge?
>

I think that Subversion Edge is no longer supported (we removed the
download links a while back) so you should probably update to another
Subversion server solution or even switching to a hosting provider. But it
is probably better to ask this question directly to CollabNet (now
digital.ai), at least if you have a commercial license.

Kind regards,
Daniel



>
> RD
>
> -Original Message-
> From: hartmannat...@apache.org 
> Sent: Thursday, December 28, 2023 9:00 PM
> To: annou...@subversion.apache.org; users@subversion.apache.org;
> d...@subversion.apache.org
> Subject: [ANNOUNCE] Apache Subversion 1.14.3 released
>
> [You don't often get email from hartmannat...@apache.org. Learn why this
> is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> EXTERNAL EMAIL
>
> I'm happy to announce the release of Apache Subversion 1.14.3.
> Please choose the mirror closest to you by visiting:
>
> https://subversion.apache.org/download.cgi#recommended-release
>
> This is a stable bugfix release of the Apache Subversion open source
> version control system.
>
> SHA-512 checksums are available at:
>
>
> https://www.apache.org/dist/subversion/subversion-1.14.3.tar.bz2.sha512
> https://www.apache.org/dist/subversion/subversion-1.14.3.tar.gz.sha512
> https://www.apache.org/dist/subversion/subversion-1.14.3.zip.sha512
>
> PGP Signatures are available at:
>
> https://www.apache.org/dist/subversion/subversion-1.14.3.tar.bz2.asc
> https://www.apache.org/dist/subversion/subversion-1.14.3.tar.gz.asc
> https://www.apache.org/dist/subversion/subversion-1.14.3.zip.asc
>
> For this release, the following people have provided PGP signatures:
>
>Nathan Hartman (CODE SIGNING KEY) [rsa4096/583F00ADF981C39F] with
> fingerprint:
> 3F8E 467C B336 6E30 13E1  120D 583F 00AD F981 C39F
>    Stefan Sperling [dsa1024/E5D30273F59D25F0] with fingerprint:
> B1CF 1060 A1E9 34D1 9E86  D6D6 E5D3 0273 F59D 25F0
>Daniel Sahlberg [rsa3072/28DB47329CFFDC63] with fingerprint:
> 4FFC B55C 0D0D 9343 CFB4  611F 28DB 4732 9CFF DC63
>Evgeny Kotkov [rsa4096/B64FFF1209F9FA74] with fingerprint:
> E7B2 A7F4 EC28 BE9F F8B3  8BA4 B64F FF12 09F9 FA74
>Johan Corveleyn [rsa4096/B59CE6D6010C8AAD] with fingerprint:
> 8AA2 C10E EAAD 44F9 6972  7AEA B59C E6D6 010C 8AAD
>
> These public keys are available at:
>
> https://www.apache.org/dist/subversion/subversion-1.14.3.KEYS
>
> Release notes for the 1.14.x release series may be found at:
>
> https://subversion.apache.org/docs/release-notes/1.14.html
>
> You can find the list of changes between 1.14.3 and earlier versions at:
>
> https://svn.apache.org/repos/asf/subversion/tags/1.14.3/CHANGES
>
> Questions, comments, and bug reports to users@subversion.apache.org.
>
> Thanks,
> - The Subversion Team
>
> --
> To unsubscribe, please see:
>
> https://subversion.apache.org/mailing-lists.html#unsubscribing
> [Sage]
>
> The information contained in this email transmission may constitute
> confidential information. If you are not the intended recipient, please
> take notice that reuse of the information is prohibited.
>
>

Re: [External] : Re: Can't connect to github anymore

[Daniel Sahlberg]

Den tis 16 jan. 2024 kl 19:58 skrev Trent Fisher :

>
> On 1/14/2024 2:52 PM, Nico Kadel-Garcia wrote:
>
> On Sun, Jan 14, 2024 at 2:27 PM sean  
>  wrote:
>
> On 2024-01-13 16:11, Nico Kadel-Garcia wrote:
>
>
> There are not many compelling reasons
> to use Subversion anymore, except the ability to check out only
> subdirectories from a branch and the insistence that a single central
> repository is the only source of truth.
>
> The ability to `svn lock` files is very useful if your repo has a lot of
> non-mergeable files, like say MS Office documents.
>
> I have never once found that feature to be useful since I first used
> Subversion back around 2001.  Mind you, I'd treat Word documents as
> binaries objects and not consider them suitable for incremental
> changes in a source control system.
>
> There are numerous documentation teams who I have worked with over the
> years who would differ with this. Version control is essential for their
> files (they may not be able to directly compare them, but they can tell
> when changes were made and who made them), and having locking is the only
> way to make this work (which is one of the reasons why Git will never work
> for them).
>
> However, I would agree with you that binaries generated from some other
> source document is not appropriate for version control (e.g. checking in
> PDF versions of documents), but Word documents are the primary source
> documents, therefore needing version control.
>
> Before I got these teams on to SVN, they were storing everything in a
> shared folder with numerous old copies of each document laying around (e.g.
> foo.doc, foo.doc.old, foo.doc.1jun2013, foo.doc.bak, etc), which is an
> accident waiting to happen.
>
>
TortoiseSVN, the Windows client, has some scripts that actually allow
"diffing" of Word and Excel documents. It is not perfect (and big
formatting changes can really throw you off) but it is quite good and helps
if you need to use DOCX or XLSX as your "source". For Word, it uses a
built-in comparison feature and for Excel it uses conditional formatting to
highlight changes.

Kind regards,
Daniel

Re: Pricing for SVN

[Daniel Sahlberg]

Den tors 11 jan. 2024 kl 10:58 skrev :

> Hello Andreas,
>
>Thank you for the reply. Could you please share the pricing
> details for Tortoise SVN as well.
>

TortoiseSVN is free software ("free" both as in freedom and no cost),
however donations are possible (and probably appreciated) if you use it.

Kind regards,
Daniel Sahlberg

Re: 100% CPU utilization by mod_authz_svn

[Daniel Sahlberg]

Den fre 22 dec. 2023 kl 12:22 skrev radek.krotil.siemens.com via users <
users@subversion.apache.org>:

> Hi SVN Community.
>
>
>
> I’d like to consult a problem with occasional high CPU utilization by
> mod_authz_svn. Please, do CC me and my colleague in the response, because
> we are subscribed to the list.
>
>
>
> Our Java application uses Subversion as a primary data storage and the SVN
> data are being accessed via Apache HTTPD mod_dav_svn and also by svnserve
> server on top of the same repository.
>
>
>
> We are facing a problem in one of our productive environments hosted in
> AWS. The server is running RHEL 8.8, Apache 2.4.37 with SVN 1.14.1
> binaries. Occasionally, the Apache HTTPD is acting strange, utilizing 100%
> CPU for periods of minutes to tens of minutes. This situation happens
> several times a week and causes delayed responses from the SVN server up to
> several minutes. Similar behavior is visible on several httpd server
> processes (mpm_event module is used), where each of them has tens of active
> requests being processed. When this CPU spike occurs, there several Apache
> HTTPD server processes with tens of threads busy in the following code
> related to the Subversion ACL.
>
>
>
> The access file is quite big. It contains about 2 group definitions
> with roughly 1 users assigned to them and about 35000 authorization
> rules for 15000 paths, and it’s size is over 5 MB. The access file is
> getting changed 100 times a day, but the CPU spikes do not correlate with
> the CPU spikes.
>
>
>
> Initially we suspected filesystem issues, but we were not able to confirm
> them. When the spike occurs, CPU I/O wait goes to zero and all the CPU is
> consumed in user space.
>
>
>
> We are looking for suggestions how to further troubleshoot the problem, or
> possible confirmation that this is a Subversion bug or inefficiency.
>
>
>
> Thank you,
>
> Radek Krotil
>
> Siemens Digital Industries Software
>
>
>
>
>
> *Pstack output example*
>
> Thread 127 (Thread 0x7f0003fcf700 (LWP 2934729)):
>
>
>
> #0  0x7f0049b79b60 in svn_authz.get_acl_access () from
> target:/lib64/libsvn_repos-1.so.0
>
> #1  0x7f0049b7a864 in update_user_rights () from
> target:/lib64/libsvn_repos-1.so.0
>
> #2  0x7f0048e35d06 in hash_do_callback () from
> target:/lib64/libsvn_subr-1.so.0
>
> #3  0x7f0058bc8ebe in apr_hash_do () from target:/lib64/libapr-1.so.0
>
> #4  0x7f0048e35d6a in svn_iter_apr_hash () from
> target:/lib64/libsvn_subr-1.so.0
>
> #5  0x7f0049b7a7b4 in expand_acl_callback () from
> target:/lib64/libsvn_repos-1.so.0
>
> #6  0x7f0048e35e41 in svn_iter_apr_array () from
> target:/lib64/libsvn_subr-1.so.0
>
> #7  0x7f0049b7c109 in svn_authz.parse () from
> target:/lib64/libsvn_repos-1.so.0
>
> #8  0x7f0049b78f74 in svn_repos_authz_read4 () from
> target:/lib64/libsvn_repos-1.so.0
>
> #9  0x7f004845e4a3 in get_access_conf () from
> target:/etc/httpd/modules/mod_authz_svn.so
>
> #10 0x7f004845e705 in req_check_access () from
> target:/etc/httpd/modules/mod_authz_svn.so
>
> #11 0x7f004845efd6 in auth_checker () from
> target:/etc/httpd/modules/mod_authz_svn.so
>
> #12 0x561c8b0724c8 in ap_run_auth_checker ()
>
> #13 0x561c8b074a9c in ap_process_request_internal ()
>
> #14 0x561c8b093a70 in ap_process_async_request ()
>
> #15 0x561c8b08fed0 in ap_process_http_connection ()
>
> #16 0x561c8b0862b8 in ap_run_process_connection ()
>
> #17 0x7f004d6b9a47 in process_socket () from
> target:/etc/httpd/modules/mod_mpm_event.so
>
> #18 0x7f004d6ba3ea in worker_thread () from
> target:/etc/httpd/modules/mod_mpm_event.so
>
> #19 0x7f005899a1ca in start_thread () from
> target:/lib64/libpthread.so.0
>
> #20 0x7f0058402e73 in clone () from target:/lib64/libc.so.6
>
>
>
>
>
> *TOP output looks as follows*
>
> top - 13:00:01 up 15 days,  7:09,  0 users,  load average: 129.31, 100.24,
> 53.38
>
> Tasks: 241 total,   7 running, 233 sleeping,   0 stopped,   1 zombie
>
> %Cpu(s): 95.6 us,  3.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.7 hi,  0.0
> si,  0.0 st
>
> MiB Mem : 126914.0 total,  55179.2 free,  20765.8 used,  50969.0 buff/cache
>
> MiB Swap:  0.0 total,  0.0 free,  0.0 used. 104540.6 avail Mem
>
>
>
> PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+
> COMMAND
>
>  233319 apache20   0 5818164   2.9g  13844 S 456.2   2.3 183:35.14
> httpd
>
>  233318 apache20   0 5751168   2.7g  13844 S 443.8   2.2 127:53.12
> httpd
>
>  232848 apache20   0 5226028   2.0g  13844 S 218.8   1.6  46:08.83
> httpd
>
>  232849 apache20   0 5291384   2.1g  13804 S 168.8   1.7  68:34.92
> httpd
>
>  232847 apache20   0 5291628   1.7g  13908 S 137.5   1.4  39:14.61
> httpd
>
>
>
> *And Apache server status clearly shows the number of “stuck” requests*
>
> Apache Server Status for localhost (via ::1)
>
> Server Version: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k
> SVN/1.14.1
>
> Server MPM: event
>
> 

Re: How do I propose changes to Subversion repos?

[Daniel Sahlberg]

Den mån 11 dec. 2023 kl 18:01 skrev Jason Yundt :

> I don’t think that they’re too picky. They made like 3 different typos
> in a 5 word log message [2], lol.
>

Luckily Subversion allows editing of log messages (although some
configuration must be done in the repository on the Subversion server)

;-)

/Daniel

Re: How do I propose changes to Subversion repos?

[Daniel Sahlberg]

Den tors 7 dec. 2023 kl 15:43 skrev Jason Yundt :

> Hi,
>
> I’m pretty familiar with Git, but Subversion is very new to me. When I
> contribute to projects that use Git, the process typically looks like
> this:
>
> 1. If I don’t already have one, then make a clone (git clone ).
>
> 2. If I already have a clone that’s been sitting around for a while,
> then switch to the main branch and pull any changes
> (git switch  && git pull).
>
> 3. Create a new branch for my changes (git switch -c my-branch).
>
> 4. Make the changes that I want to contribute.
>
> 5. Commit the changes (git commit).
>
> 6. Depending on what project I’m contributing to, do one of the
> following:
>
> • Create a fork on whatever forge the upstream project is using,
> push my branch there (git remote add my-fork  &&
> git push my-fork) and then use the forge to create a pull
> request.
>
> • Push my branch to any remote (git remote add my-repo  &&
> git push my-repo), generate a message using git-request-pull and
> then send that message to a mailing list.
>
> • Use git-send-email.
>
> ---
>
> I’m trying to figure out the Subversion equivalent of that process so
> that I can contribute to an open-source project that uses Subversion.
> Here’s what I’ve been able to figure out by looking at the patch
> submission guidelines for Subversion itself [1]:
>
> 1. If I don’t already have a one, then make a working copy of the
> project’s trunk (svn checkout /trunk/ -trunk).
>
> 2. If I already have a working copy that’s been sitting around for a
> while, then update it (svn update).
>
> 3. Make the changes that I want to contribute.
>
> 4. Generate a patch (svn diff -x-p > my-changes.patch).
>
> 5. Open the patch with a text editor and write my log message at the
> top. Put triple square brackets around the message.
>
> 6. Email the patch to the project’s mailing list. If possible, attach
> the patch with a text/x-diff, text/x-patch, or text/plain MIME type.
>
> ---
>
> Here’s the questions that I still have:
>
> • With Git, there’s multiple different ways of sending your changes
> upstream (pull requests, git-request-pull and git-send-email). Are there
> multiple ways of doing it with Subversion or do you always just send
> emails with patches attached?
>

Unfortunately there are no equivalents of Github that offer the "pull
requests" functionality for Subversion as far as I know. The normal
process, at least within the ASF, is to create a patch and either attach it
as a file (more below) or directly within the e-mail itself.

The other solution would be to commit directly to the actual repository but
then you need write access (it IS possible to say "Jason has rw access to
/jasons-branches/ and r access to everything else except /private where he
has no access" if one would like to create a "staging area", then you could
create your own branch and request merges from that one, but the process
would be much less intuitive than the Github pull request process).

Subversion has the ability to do merges from foreign repositories [2] so in
theory it would be possible to create your own repository, commit your
patches and ask the remote party to merge these commits, but it is also not
very intuitive.


>
> • I followed my own instructions to create an example patch for
> , and I attached it
> to this email. Does it look like I created the patch correctly?
>

I would prefer to not have the log message in the patch file and instead
add it in the e-mail. That way it would be much easier to apply the patch,
otherwise you need to edit the file before applying it. The triple brackets
are used in an e-mail to indicate something verbatim in a mail, such as:

Suggested log message:
[[[
* README:
  Add some nonsense as an example
]]]

It could also be used to add the patch directly in the e-mail.

Kind regards,
Daniel


> [1]: <
> https://subversion.apache.org/docs/community-guide/general.html#patches>
>


[2]:
https://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.nomergedata

Re: Subversion behind apache 2.4 proxy - Connection refused

[Daniel Sahlberg]

Den mån 4 dec. 2023 kl 14:29 skrev Gunnar Grim :

> Hi!
>
> Thanks for your reply. Just hearing that my setup looks OK made me look
> deeper, with Wireshark. Found that svn was using IPV6 but firefox used
> IPV4. Apparently the proxy can't handle IPV6 so I am now using a hostname
> wihout any IPV6 address in /etc/hosts and everything works fine.
>
> Thanks again,
> Gunnar
>

Thanks for coming back to the list with your solution.

It sounds a bit strange that Apache httpd wouldn't be able to proxy IPv6
traffic. Have you checked the Listen directives in your httpd config? Maybe
it is only listening on IPv4 ports (check with lsof -i)?

Kind regards,
Daniel



> On 2023-12-03 22:02, Daniel Sahlberg wrote:
>
> Den sön 26 nov. 2023 kl 18:31 skrev Gunnar Grim :
>
>> Hi!
>>
>> I have subversion running in a Docker container and everything works fine
>> if I connect directly to it, but I really need to run subversion behind an
>> Apache 2.4 proxy. For now I'm not using https, just trying to get it to
>> work with as simple setup as possible.
>>
>> I have tried to use the FAQ instructions,
>> https://subversion.apache.org/faq.html#reverseproxy, but they are
>> written for an older Apache version so I have tried to modify them for 2.4.
>>
>> Browsing the repos with Firefox works fine but it fails with the svn
>> client and SmartSVN:
>>
>> svn info http://localhost/svn/test/svn-test-project
>> svn: E170013: Unable to connect to a repository at URL '
>> http://localhost/svn/test/svn-test-project'
>> svn: E000111: Error running context: Connection refused
>>
>> It sounds really strange that browsing with Firefox would work but not
> the svn command line client. The error is exactly the one to be expected if
> there is no server running at all (or possibly if there is a firewall or
> security policy disabling network access for the svn program).
>
> If you try to access http://localhost/svn/test/svn-test-project with curl
> or wget? The same question for http://localhost:7280/svn/
>
> I assume svn info http://localhost:7280/svn/test/svn-test-project works
> as expected?
>
>
>> This is my proxy configuration:
>>
>>ProxyRequests Off
>>ProxyVia on
>>
>>
>>Require all granted
>>
>>
>>ProxyPass /svn/ http://localhost:7280/svn/
>>
>>  ProxyPassReverse http://localhost:7280/svn/
>>  > MKCOL MOVE COPY DELETE LOCK UNLOCK MERGE>
>>  Require all granted
>>  
>>  RewriteCond %{HTTP:Destination} .+/(svn/.*$)
>>  RewriteRule ^/svn/.* - [E=MyDestination:http://localhost:7280/%1,PT]
>>
>>  RequestHeader set Destination %{MyDestination}e env=MyDestination
>>
>>
>>
>> When I use the browser all accesses are logged but with the svn client
>> nothing is logged to the access- or error logs, even with log level debug.
>>
>> Hope someone can see what is wrong with my configuration.
>>
> On a cursory look all seems fine, but I didn't try to replicate your setup
> yet.
>
>> TIA,
>> Gunnar
>>
>>
>>
> Kind regards,
> Daniel Sahlberg
>
>

Re: Subversion behind apache 2.4 proxy - Connection refused

[Daniel Sahlberg]

Den sön 26 nov. 2023 kl 18:31 skrev Gunnar Grim :

> Hi!
>
> I have subversion running in a Docker container and everything works fine
> if I connect directly to it, but I really need to run subversion behind an
> Apache 2.4 proxy. For now I'm not using https, just trying to get it to
> work with as simple setup as possible.
>
> I have tried to use the FAQ instructions,
> https://subversion.apache.org/faq.html#reverseproxy, but they are written
> for an older Apache version so I have tried to modify them for 2.4.
>
> Browsing the repos with Firefox works fine but it fails with the svn
> client and SmartSVN:
>
> svn info http://localhost/svn/test/svn-test-project
> svn: E170013: Unable to connect to a repository at URL '
> http://localhost/svn/test/svn-test-project'
> svn: E000111: Error running context: Connection refused
>
> It sounds really strange that browsing with Firefox would work but not the
svn command line client. The error is exactly the one to be expected if
there is no server running at all (or possibly if there is a firewall or
security policy disabling network access for the svn program).

If you try to access http://localhost/svn/test/svn-test-project with curl
or wget? The same question for http://localhost:7280/svn/

I assume svn info http://localhost:7280/svn/test/svn-test-project works as
expected?


> This is my proxy configuration:
>
>ProxyRequests Off
>ProxyVia on
>
>
>Require all granted
>
>
>ProxyPass /svn/ http://localhost:7280/svn/
>
>  ProxyPassReverse http://localhost:7280/svn/
>   MKCOL MOVE COPY DELETE LOCK UNLOCK MERGE>
>  Require all granted
>  
>  RewriteCond %{HTTP:Destination} .+/(svn/.*$)
>  RewriteRule ^/svn/.* - [E=MyDestination:http://localhost:7280/%1,PT]
>  RequestHeader set Destination %{MyDestination}e env=MyDestination
>
>
>
> When I use the browser all accesses are logged but with the svn client
> nothing is logged to the access- or error logs, even with log level debug.
>
> Hope someone can see what is wrong with my configuration.
>
On a cursory look all seems fine, but I didn't try to replicate your setup
yet.

> TIA,
> Gunnar
>
>
>
Kind regards,
Daniel Sahlberg

Re: Subversion 1.14.2 on Linux how to enable plaintext password store?

[Daniel Sahlberg]

lör 2 dec. 2023 kl. 12:02 skrev Bo Berglund :

> On Fri, 01 Dec 2023 11:21:32 +0100, Bo Berglund 
> wrote:
>
> >OK, I will have to test it again.
> >
> >But I have so many RPi units and some have this problem whereas others
> don't so
> >I have to somehow figure out how to test it on all to look for
> commonality/diff
> >between those that pop the GUI dialog and those that don't.
> >
> >On one where the svn commands work without popping up anything I have
> this:
> >
> >Inside ~/.subversion/auth are these dir/files:
> >
> >svn.simple/03994a04eb338a432667e51f0e0720bf
> >svn.ssl.server/52e60f46d8c02303aea5256b18eb7aac
> >
> >The other dirs are empty.
>
> >So maybe these two together is the store for text based access logins?


svn.simple is used to store the username. In case of plaintext password
cache the password is also there. Some password stores might store the
encrypted password here as well (for example on Windows the password is
encrypted using Windows apis).


>
> UPDATE:
> ---
> Now I have tried to check out a package from our SVN server into a freshly
> built
> Raspberry Pi4B running 32 bit PiOS (bookworm).
>
> Before I did this I had compared the config between an older installation
> using
> a several years old operating system and this new one and I saw that the
> old had
> this setting enabled:
>
> [auth]
> password-stores = gnome-keyring
>
> So I added this to the svn installation config on the new RPi4B
>
> Then on the SSH login I tried to check out the package I wanted and this
> happened:
>
> It asked for the password for "bosse"
>
> But I had not told it what user to use on svn so it seems like it forces
> one to
> use the local system username rather than the subversion server username!


No, it doesn’t force the same username. It DEFAULTs to the current username
for convenience, if you happen to have the same in both. If you have
another username in Subversion, just press enter and it will ask for the
username as well.

In this case they happened to be the same since the new RPi systems no
> longer
> uses pi as the user but some username configured on installing the
> operating
> system.
>
> But after I typed in my password it just hung as before...
>
> So then I opened a VNC session to the GUI and sure enough there was a
> dialog box
> popped up on that window!!!


I think you should bring this up with the PiOS project. It seems crazy that
a ssh session is able to open a GUI application on the local console that
you can only access via VNC.


>
> Here it asked me the following:
> ---
> Choose password for new keyring
> An application wants to create a new keyring called "Default".
> Choose the password you want to usefor it.
> Password: *
> Confirm:  *
>[Cancel]  [Continue]
> ---
>
> So I entered the password twice and hit Continue.
>
> Now in the SSH window the checkout proceeded as it should have in the first
> place...
>
> Finally:
> 
> After this was done I now created a new SSH session and inside that I went
> to a
> different target directory and issued the same svn command for a checkout
> and
> this time I was not asked for a password and the GUI screen did not pop up
> a
> dialog.
>
> So it seems like svn can be used on the command line provided one first
> does
> this:
>
> - Install subversion via apt
> - Run a bare svn command to create ~/.subversion/config
> - Edit the config file and enable this:
>   [auth]
>   password-stores = gnome-keyring


I would NOT configure gnome-keyring as a password store, since it creates
all the gui problems you have. Probably better leave it empty.


> - Go somewhere like ~/projects
> - Issue a svn co command for a package on the server
> - Enter the requested password
> - Access the GUI screen where the dialog shown above is now displayed
> - Enter the requested password twice
>
> Now the svn checkout proceeds and apparently any following checkout will
> not
> trigger the GUI dialog.
> But I have not tested a svn ci command yet


Sure that it will work, but only as long as the keyring is unlocked. Don’t
know how long it stayes unlocked on PiOS.


>
> Or another package of our svn server..
>
>
> --
> Bo Berglund
> Developer in Sweden
>
>

Re: Peforce GitLFS like features

[Daniel Sahlberg]

Den lör 2 dec. 2023 kl 05:12 skrev Robin :

> Hi, I use SVN for gamedev projects, it works great but our repository
> size is growing towards 1TB size. A lot of the files are binary taking
> up bulk of space. For bigger projects in game industry, peforce is
> commonly used,  and they have a few features which are quite neat.
>
> 1. User can specify certain files that don't need to store full history.
> Server keep only X number of rev history cos the older revisions are not
> needed.  e.g a artist photoshop file, we don't need full history,
> usually only the latest or a few revisions.
>

This is unfortunately not possible. The history in Subversion is
"immutable", you cannot remove things from the repository. On the other
hand, large repositories is not a problem (except for the required disk
space).

If you really want to keep the binary assets out of the main code
repository, you can use Subversions Externals definitions (see
https://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html) where you
can pull in a file or a folder from some other repository in to the working
copy tree. Then you could have multiple repositories for the binary assets,
retiring (and removing) repositories and switching the externals definition
to point to the new repository.

But that means an old version of the code will effectively be unbuildable
since it points to non-existing binary assets.

I think the cost for some disk space on the server will be a lot lower than
the cost (in hours) for any extra complexity trying to eliminate old
versions.


>
> 2. Server don't keep a duplicate copy of those files on client, client
> get 1 copy only. This would be similar to git LFS.
>

Contrary to Git, in Subversion the client will only store the "current"
version of a file in a working copy (when checking out a repository).
"Current" here means the version you decide to check out, not necessarily
the latest.

In Subversion 1.14 and earlier, you will also get an extra copy called
"pristine version" (hidden in the administrative directory .svn) for each
version of the file you have had in your working copy. If the user wants to
switch to another version, a simple local copy is the only thing required.
The downside is of course the extra storage space required, in particular
when working with a lot of different revisions of each file. The command
svn cleanup can remove unused pristine copies to save disk space.

In Subversion 1.15 (not yet released) there will be an option to skip the
pristine copies, effectively cutting storage requirement in half, at the
expense of more network traffic. When running in this mode, the client will
only have one copy of each file with only a tiny bit of overhead for
configuration.


>
> If SVN has these  features natively, it would be greatest tool.
> Otherwise, how would it  be possible to make such a setup?
>

In general, storing large binary files is an area where the design of
Subversion is superior to Git (where you need addons such as LFS).


>
> Robin
>

Kind regards,
Daniel

Re: Subversion 1.14.2 on Linux how to enable plaintext password store?

[Daniel Sahlberg]

fre 1 dec. 2023 kl. 22:15 skrev Mark Phippard :

> Correct me if I am wrong Nathan, but there is no option that allows
> plaintext passwords on Linux.
>
> https://subversion.apache.org/docs/release-notes/1.14.html#plaintext-passwords-disabled


In the original post there was a quote from svn —version showing that
plaintext cache was one of the available stores. I guess svn was built with
the
--enable-plaintext-password-storage option. Then plaintext password cache
would be enabled, unless disabled in the config files, right?


> I thought that was a change in trunk to put that back as an option for
> 1.15?  https://svn.apache.org/repos/asf/subversion/trunk/CHANGES


Wasn’t this change just to revert to the old default to enable plaintext
cache unless disabled by configure?

Kind regards
Daniel



>
>
> Mark
>
>
>
> On Fri, Dec 1, 2023 at 12:55 AM Nathan Hartman 
> wrote:
> >
> > On Thu, Nov 30, 2023 at 6:43 PM Bo Berglund 
> wrote:
> > >
> > > When I installed subversion on a Raspberry Pi4B and checked the
> installed
> > > version afterwards it printed this:
> > >
> > > $ svn --version
> > > svn, version 1.14.2 (r1899510)
> > >compiled Nov 12 2022, 20:30:30 on arm-unknown-linux-gnueabihf
> > >
> > > Copyright (C) 2022 The Apache Software Foundation.
> > > This software consists of contributions made by many people;
> > > see the NOTICE file for more information.
> > > Subversion is open source software, see http://subversion.apache.org/
> > >
> > > < cut >
> > >
> > > The following authentication credential caches are available:
> > >
> > > * Plaintext cache in /home/bosse/.subversion
> > > * Gnome Keyring
> > > * GPG-Agent
> > > * KWallet (KDE)
> > >
> > > I have had a lot of problems with password caching for a number of
> years since I
> > > am working on these devices mainly on the command line via ssh and
> when I issue
> > > a svn command against a server on our LAN what happens is that svn
> pops up a
> > > password entry dialog on the (invisible) **GUI screen**!
> > > And the operation started on the command line fails...
> > >
> > > It was not always so but some svn update changed the way svn
> operates
> > >
> > > Now I see the banner above where it looks like it is again available:
> > >
> > > * Plaintext cache in /home/bosse/.subversion
> > >
> > > The problem is that in the config file there is no example of the
> syntax for
> > > enabling this
> > >
> > > So my question here is:
> > > How do I enable the plaintext cache in svn client version 1.14.2 on a
> Raspberry
> > > Pi4B running Pi-OS?
> > >
> > >
> > > --
> > > Bo Berglund
> > > Developer in Sweden
> >
> >
> > In the user's home directory, there should be a subdirectory called
> > .subversion which contains a file called config. In that file, there
> > is a section called [auth] which contains a setting called
> > "password-stores". It might be commented, or it might say something
> > like "password-stores = gpg-agent,gnome-keyring,kwallet". This setting
> > determines the order in which the different password stores
> > (credential caches) are used. You could set this to "password-stores =
> > plaintext". Make sure you don't have "store-passwords = no" or
> > "store-plaintext-passwords = no". I think this will solve the issue --
> > though note that if the password has not been saved to the plaintext
> > cache yet, the SVN client should prompt for it once, and then prompt
> > whether you accept the risk to save it in the plaintext cache. This
> > should take place on the command line, so I think you won't have the
> > issue with the inaccessible GUI dialog box on the remote machine. Once
> > saved, it shouldn't prompt for it anymore.
> >
> > Note: In addition to the user's ~/.subversion/config file I mentioned
> > above, there is also a systemwide /etc/subversion/config. If changes
> > in the user-level file don't appear to work, check the systemwide one
> > as well.
> >
> > Hope this helps,
> > Nathan
>

Re: Subversion 1.14.2 on Linux how to enable plaintext password store?

[Daniel Sahlberg]

Den fre 1 dec. 2023 kl 08:35 skrev Bo Berglund :

> As it has been for some time now when I enter a command window svn command
> that
> requires authentication it pops up a dialog on the GUI window which is
> invisible
> to me at that point.
> It took a while before I understood what was going on, at first I thought
> svn
> had crashed or similar. It just hung there on the command window. :(
>

What does echo $DISPLAY return? I think it is awfully strange that an SSH
session on the PiOS would start a graphical program, but if DISPLAY is set,
maybe you can unset it and at least the GUI part would be solved?


> So on this new system I want to avoid this from happening and was
> encouraged by
> the output shown when I checked the svn version.
>
> I have no idea if any of the allowed stores mentioned (gnome-keyring,
> kwallet,
> gpg-agent) will work inside an SSH command line section...
>

I don't think any of those stores works on the command line. No idea what
Subversion will do but I assume it will fall back to inputting the password
on the command line.

Kind regards,
Daniel

Re: Is there a write opposite to "svn cat"?

[Daniel Sahlberg]

Den tis 28 nov. 2023 kl 16:13 skrev Nathan Hartman :

> On Mon, Nov 27, 2023 at 1:47 AM Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com> wrote:
>
>> Den sön 26 nov. 2023 kl 22:51 skrev Graham Leggett via users <
>> users@subversion.apache.org>:
>>
>>> On 25 Nov 2023, at 13:40, Pavel Lyalyakin 
>>> wrote:
>>>
>>> `svnmucc put` perhaps?
>>> https://svnbook.red-bean.com/en/1.8/svn.ref.svnmucc.re.html
>>>
>>>
>>> From reading the manual it looks perfect, but I’m having no luck:
>>>
>>> [root@seawitch postgres]# cat db.sql | svnmucc put -
>>> file:///var/lib/svn/db/db.sql
>>>
>>> svnmucc: invalid option:
>>>
>>> Type 'svnmucc --help' for usage.
>>>
>>> Alas the error message mentions an invalid option, but doesn’t say which
>>> option, or why it is invalid.
>>>
>>
>> The documentation say:
>> [[[
>>   put SRC-FILE URL   : add or modify file URL with contents copied
>> from
>>SRC-FILE (use "-" to read from standard input)
>> ]]]
>>
>
>
> Probably we should expand the above doc to avoid future confusion, e.g.,
> "...SRC-FILE (to read from standard input, use "--" to stop option
> processing followed by "-" to indicate standard input)."
>

Thanks! I've committed this exact help text in r1914222.

Kind regards,
Daniel

Re: Is there a write opposite to "svn cat"?

[Daniel Sahlberg]

Den sön 26 nov. 2023 kl 22:51 skrev Graham Leggett via users <
users@subversion.apache.org>:

> On 25 Nov 2023, at 13:40, Pavel Lyalyakin 
> wrote:
>
> `svnmucc put` perhaps?
> https://svnbook.red-bean.com/en/1.8/svn.ref.svnmucc.re.html
>
>
> From reading the manual it looks perfect, but I’m having no luck:
>
> [root@seawitch postgres]# cat db.sql | svnmucc put -
> file:///var/lib/svn/db/db.sql
>
> svnmucc: invalid option:
>
> Type 'svnmucc --help' for usage.
>
> Alas the error message mentions an invalid option, but doesn’t say which
> option, or why it is invalid.
>

The documentation say:
[[[
  put SRC-FILE URL   : add or modify file URL with contents copied from
   SRC-FILE (use "-" to read from standard input)
]]]

So as far as I'm reading the documentation, the command you are using
should be supported. I would say this is a bug, either in the argument
handling or in the documentation.

Can you instead try:
$ svnmucc put db.sql file:///var/lib/svn/db/db.sql

I will bring this discussion to the d...@subversion.apache.org to figure out
if we need to change the documentation or if we can fix the code.

Kind regards,
Daniel

Re: LDAP authentication not working after the domain controller changed

[Daniel Sahlberg]

Den fre 10 nov. 2023 kl 11:58 skrev Rajesh N :

> Hello Team ,
>
> We are using LDAP authentication in SVN and recently we moved old DC to
> new DC (Windows Server 2019 ) .
> After moving Subversion LDAP authentication is not working with the new
> DC, which is causing the old DC to fail. But LDAP authentication is working
> perfectly when the old DC up.
> Ensured that the LDAP configuration points to the new DC. However, there
> is some kind of dependency with old DC that we cannot trace.
>
> Any idea about this dependency? Any expert advice?
>

Have you double checked that the DNS settings are correct so that there
isn't anything in them pointing to the old DC? I don't really know LDAP but
I know other parts of Active Directory are very dependent on the DNS
records pointing to the new DC server.

Kind regards,
Daniel

Sharing the version of the subversion server and the configuration of LDAP
> below.
> SVN server versions:
>
> OS : Ubuntu 20.4.5 LTS
> Subversrion : 1.13.0
> Apache : 2.4
>
> And LDAP Configuration in the Apache config file is
>
>
>
>
>
>
>
> Best Regards,
>
> Rajesh N
>
> Lead  IT | Kimball Electronics (India) Pvt Ltd | M:
> +91 8289836955 | T: +91 471 2700175 | rajesh.n 
> @geservs.com  |
>
> *www.geservs.com **| *
>
>
>

Re: Command to list all revisions (with date?) when a particular was modified?

[Daniel Sahlberg]

mån 6 nov. 2023 kl. 21:42 skrev Bo Berglund :

> On Mon, 06 Nov 2023 11:53:30 -0800, Kenneth Porter 
> wrote:
>
> >--On Monday, November 06, 2023 7:32 PM +0100 Bo Berglund
> > wrote:
> >
> >> I am hunting for when a particular change was made in a file under
> version
> >> control. It happened years ago.
> >
> >svn blame path > path.blame
> >
> >That gives you the file annotated with each line showing which revision
> it
> >last changed on.
> >
>
> Thanks, but:
>
> I tried blame:
> svn blame
> https://svnserver/svn/pc/AgiSSAdmin/trunk/Source/class_SuperSting.pas
> > blame.txt
>
> It produced a text file containing the content of the source file as it
> looks
> today with each line annotated when that line was committed the *last*
> time.
>
> But that is not what I want, instead I want to know *all* revisions in
> which the
> file was modified so I can look at these revisions and see what changed
> between
> them concerning the function I want to inspect.


svn blame accepts an -r N:M so if you know the revisions that occurred in
the time period of interest (maybe also works with the date range arguments
already suggested by Nathan) you should be able to limit the revision
numbers.

But since you use TortoiseSVN I might suggest that you look at Tortoise’s
graphical Blame. It looks much like the command line client in that you get
the revision number each line was changed but you can right click a
revision number and “blame previous revision” which will give the previous
time that line was changed. I find this helps a lot to figure out past
refactorings.


>
> If I could get the rev numbers at the beginning of each result line in
> numerical
> order and nothing else I would be done with the list.
>
> with this command:
>
> svn log -q
> https://svnserver/svn/pc/AgiSSAdmin/trunk/Source/class_SuperSting.pas
> > log.txt
>
> I got a file containing a reverse ordered list of revisions looking like
> this:
>
> r200 | bosse | 2001-06-24 17:29:47 +0200 (Sun, 24 Jun 2001)
> 
> r197 | bosse | 2001-06-23 12:12:37 +0200 (Sat, 23 Jun 2001)
> 
>
> with 106 revisions present.
>
> So log is the better solution.
> Now I need to figure out how to best attack this analysis with so many
> commits...
>

Kind regards
Daniel


>
> --
> Bo Berglund
> Developer in Sweden
>
>

Re: Upgrade Subversion 1.13 to 1.14 LTS ( Ubuntu 20.04.5)

[Daniel Sahlberg]

Den ons 1 nov. 2023 kl 16:07 skrev JITHIN K :
[...]

> Does that mean in the next Ubuntu 20.04.x release they include patches for
> these vulnerabilities?
>

I know there has been other e-mails clarifying that those CVEs were not for
Subversion, but just to comment that it is probably better to direct this
question to the security team of your distribution. The Subversion project
has no control over if/how/when downstream packagers apply patches. In the
case of Ubuntu: https://wiki.ubuntu.com/SecurityTeam/FAQ#Contact

Kind regards,
Daniel Sahlberg

Re: Checksum mismatch in single repo

[Daniel Sahlberg]

Den fre 27 okt. 2023 kl 07:30 skrev Felix Natter :

> Dear svn experts,
>
> I do a daily dump+backup of my svn server. Without any known trigger
> (no server crash, except about 2 months ago I had a single I/O error on
> the
> ProxMox virtualization server), the dump of one repo failed with:
>
> svnadmin: E200046: LZ4 decompression failed
>
> The svnadmin verify I ran to double check that also failed for that one
> repo:
>
> verifying /repos/X/Y...
> * Error verifying repository metadata.
> svnadmin: E160004: Checksum mismatch in item at offset 18983705 of length
> 11921122 bytes in file /repos/X/Y/db/revs/0/221
>
> After I restored X/Y from the last backup, and ran a dump/backup/verify,
> everything is fine for 4 days now.
>
Good thing you did the dump/backup and verify steps!

Do I understand the issue occurred about a week ago, you restored the
backup and now it has been working fine for the last 4 days? As compared
with the known I/O error 2 month ago (ie, a lot earlier)?


> I couldn't find an error in the system logs (especially no I/O errors).
> The repos are on a HDD (in my experience they last longer than SSDs
> with lots of write activity, i.e. daily dumps/backups/etc...).
>
> Question: Can I rule out software failure?
>
It is difficult to rule out, but there are not many reports of this failure
so I would guess it is more likely to be a corrupted bit of data on your
HDD.


> I am running svn 1.14.1
> on ALMA Linux 8.x. Shall I install on a new HDD?
>
You should probably check the SMART stats on the drive (on the
virtualisation host!) or any other indications you might have on an
upcoming failure to see if the HDD is indeed the issue.


> No action needed?
> Any other advice?
>
> Many Thanks in Advance and Best Regards,
> Felix
>

Kind regards,
Daniel Sahlberg

svnadmin hotcopy E150002 Destination already exists

[Daniel Sahlberg]

Hi,

A user reported the above error in the TortoiseSVN user group [1]. I
advised them to send it here but for some reason that doesn’t work (I’ve
checked that it isn’t waiting for moderation). I’m taking the liberty to
copy the original question below:

——
Hey there, we do hotcopies of our repos every night. Occasionally, for some
time now, hotcopy fails with the following error:

  svnadmin: E150002: Destination 'K:\repo01\db\locks\2ca' already exists

Mostly, a second run finishes without any errors.

It does not happen to the same repos every day. So the next day it could be:
  svnadmin: E150002: Destination 'K:\repo05\db\locks\02c' already exists
or
  svnadmin: E150002: Destination 'K:\repo13\db\locks\039' already exists

The affected locks-folders are always different.

It happens to old repos that were not touched in a long time, as well as
currently used ones.

Destination is a SMB file share on a Synology NAS (HDDs). As I see,
svnadmin hotcopy clears the locks-folders in the destination every time.
Can it be that the NAS is just too slow and cannot keep up with this
process?

Thanks!
——
Kind regards,
Daniel Sahlberg

1 https://groups.google.com/g/tortoisesvn/c/YxC51xgZn_8

Re: SVN update not working in MacOS Sonoma

[Daniel Sahlberg]

Den fre 6 okt. 2023 kl 10:58 skrev :

> Hi Daniel,
>
> I tried Fiddler, but no network data is capturing when I run the SVN
> commands in the terminal. Check the attached video
>
> May I  know what exactly you are looking for in the network data, I just
> wanted to know why the svn commands working fine without any issue in macos
> 13 and why not in macos 14
>

I'm looking for information in the HTTP headers that could lead us to
understand why you have problems. Obviously you should filter out any
credentials or other sensitive information.

Pavel has confirmed that Subversion works for him without any issues on
macOS 14 and I can see no reason why it wouldn't work for you. This is the
reason why both Pavel and I have asked for more details regarding your
network environment, your server etc.

Unable to see the attached file.

Kind regards,
Daniel

Re: SVN update not working in MacOS Sonoma

[Daniel Sahlberg]

Den tors 5 okt. 2023 kl 10:13 skrev :

> Hi Daniel,
>
> What exactly you are referring about "Have you tried to catch the network
> traffic?" , can you please help how to check this network network traffic
> while running svn commands
>
> Regards
> Pavan
>

Someone with more MacOS experience can probably help but Wireshark and/or
Telerik Fiddler (both seems to have Mac versions) is probably a good start.

Kind regards,
Daniel

>

Re: SVN update not working in MacOS Sonoma

[Daniel Sahlberg]

Den ons 4 okt. 2023 kl 11:22 skrev :

> Hi Daniel,
>
> I attempted to use svn commands in the terminal on the latest version of
> MacOS and encountered errors with both "svn update" and "svn checkout".
> However, when I ran the same commands on an earlier version of MacOS using
> a virtual machine, I did not encounter any issues.
>

Have you tried to catch the network traffic?

Kind regards,
Daniel Sahlberg

>

Re: SVN update not working in MacOS Sonoma

[Daniel Sahlberg]

Den tis 3 okt. 2023 kl 11:09 skrev :

> Hi Daniel,
>
> Thanks for the quick reply.
>
>
> Our repository is currently hosted on AWS EC2.
>
> To check the issue in other OS's, I have set up Ubuntu and MacOS 13
> virtual machines on my MacBook using UTM. I have not encountered any issues
> with the "svn update" and "svn checkout" commands while running them on
> both the Ubuntu and MacOS 13 virtual machines. However, when running these
> commands on my MacBook, which has the latest MacOS 14 version installed, I
> encounter some errors which I shared earlier
>
> I hope this info will help to debug issue
>

I saw you were using SmartSVN. Just to rule out any issues in this
software, have you tried the Subversion command line client? I'm no Mac
user myself but I understand there are several options available using
Fink, Homebrew or MacPorts, see
https://subversion.apache.org/packages.html#osx

Can you catch the network traffic to see exactly what is sent to the
servern and the replies?

Kind regards,
Daniel Sahlberg

Re: SVN update not working in MacOS Sonoma

[Daniel Sahlberg]

Den tis 3 okt. 2023 kl 08:28 skrev :

> Hi Pavel,
>
> Thanks for the quick reply.
>
> I m using my personal macbook, so I dont have any proxy server, reverse
> proxy or application firewall.
>

Where is your repository located?

A reverse proxy is something you would expect to have on the server side.
Depending on your network there could also be a transparent proxy server
and/or package inspecting firewall interfering with the traffic. Your
system administrator should know about this.

Kind regards,
Daniel Sahlberg

Apache Subversion 1.10.x end of life

[Daniel Sahlberg]

The Subversion 1.10.x line is end of life (EOL). It was released on
2018-04-13
and was supported for the last four years according to the LTS release
life-cycle (see How we plan releases[1]). We recommend everyone to update
to the current LTS release 1.14.2 as soon as practically possible since
we've stopped accepting bug reports against 1.10.x and will not make any
more 1.10.x releases. The last 1.10.x release (1.10.8) was made on
2022-04-12
and is available to anyone who can't update to 1.14.

Thanks,
- The Subversion Team

[1] https://subversion.apache.org/roadmap.html#release-planning



https://subversion.apache.org/mailing-lists.html#unsubscribing

Re: Problem storing passwords when using subversion

[Daniel Sahlberg]

Den fre 1 sep. 2023 kl 14:57 skrev Mark Wood-Patrick <
mwoodpatr...@nvidia.com>:

> Where can I find the correct version of the docs for subversion 1.14.1
>

You get a long way with:
$ svn help

Otherwise the SVN book is still mostly accurate, there are only a few new
features not yet described:
https://svnbook.red-bean.com/nightly/en/index.html

Kind regards,
Daniel


>
>
> Mark
>
> *From:* Daniel Sahlberg 
> *Sent:* Friday, September 1, 2023 5:54 AM
> *To:* Mark Wood-Patrick 
> *Cc:* users@subversion.apache.org
> *Subject:* Re: Problem storing passwords when using subversion
> *Importance:* High
>
>
>
> *External email: Use caution opening links or attachments*
>
>
>
> Den fre 1 sep. 2023 kl 14:04 skrev Mark Wood-Patrick via users <
> users@subversion.apache.org>:
>
> I'm using subversion 1.14.1 on CentOS release 6.8 and trying to get
> subversion to store my credentials.
>
>
>
> Please check the svn --version command, it should say something like this
> towards the end of the output:
>
>
>
> [[[
>
> The following authentication credential caches are available:
>
>
>
> * Plaintext cache in /home/dsg/.subversion
>
> * Gnome Keyring
>
> * GPG-Agent
>
> * KWallet (KDE)
>
> ]]]
>
>
>
>
> Viewing ~/.subversion/servers it seems like passwords should be stored by
> default.
>
> In
>
> ~/.subversion/config
>
> I have:
>
>   password-stores = gpg-agent,gnome-keyring,kwallet
>
> However, when I try to do a checkout it continues to prompt me to enter my
> password, any idea what I'm doing wrong or how to determine why it's not
> working?
>
>
>
> Have you configured gnome keyring or kwallet?
>
>
>
> Are you using Subversion within a graphical session or through SSH? I
> think gnome keyring/kwallet are only available in graphical sessions.
>
>
>
>
> Where can I find the correct version of the docs for subversion 1.14.1
>
>
>
> The default compile time configuration in Subversion 1.12 to 1.14 disables
> the plaintext cache (as you can see above, I have compiled my own version
> and enabled the plaintext cache).
>
>
>
> The FAQ explain this in more details.
>
>
>
> If you can accept the security implications of storing the password in
> plaintext there is a script available in the FAQ:
> https://subversion.apache.org/faq.html#plaintext-passwords
>
>
>
> Kind regards,
>
> Daniel Sahlberg
>
>
>

Re: Problem storing passwords when using subversion

[Daniel Sahlberg]

Den fre 1 sep. 2023 kl 14:04 skrev Mark Wood-Patrick via users <
users@subversion.apache.org>:

> I'm using subversion 1.14.1 on CentOS release 6.8 and trying to get
> subversion to store my credentials.
>

Please check the svn --version command, it should say something like this
towards the end of the output:

[[[
The following authentication credential caches are available:

* Plaintext cache in /home/dsg/.subversion
* Gnome Keyring
* GPG-Agent
* KWallet (KDE)
]]]


>
> Viewing ~/.subversion/servers it seems like passwords should be stored by
> default.
>
> In
>
> ~/.subversion/config
>
> I have:
>
>   password-stores = gpg-agent,gnome-keyring,kwallet
>
> However, when I try to do a checkout it continues to prompt me to enter my
> password, any idea what I'm doing wrong or how to determine why it's not
> working?
>

Have you configured gnome keyring or kwallet?

Are you using Subversion within a graphical session or through SSH? I think
gnome keyring/kwallet are only available in graphical sessions.


>
> Where can I find the correct version of the docs for subversion 1.14.1
>

The default compile time configuration in Subversion 1.12 to 1.14 disables
the plaintext cache (as you can see above, I have compiled my own version
and enabled the plaintext cache).

The FAQ explain this in more details.

If you can accept the security implications of storing the password in
plaintext there is a script available in the FAQ:
https://subversion.apache.org/faq.html#plaintext-passwords

Kind regards,
Daniel Sahlberg

Re: Subversion sasl authentication fails with openssl3.1

[Daniel Sahlberg]

Den sön 27 aug. 2023 kl 22:28 skrev Fischer, Michael <
michael.fisc...@yale.edu>:

> Dear Daniel,
>
> Thank you for the careful reply.  Some answers are interspersed below.
>
> On 8/22/23 7:40 AM, Daniel Sahlberg wrote:
>
> Den sön 20 aug. 2023 kl 17:14 skrev Fischer, Michael <
> michael.fisc...@yale.edu>:
>
>> I have many repositories configured for sasl authentication.  The svn
>> client for Mac osx, built using MacPorts, recently stopped working.  I
>> first reported the problem to the MacPorts bug list but have been advised
>> to report it to the subversion developers.  (See below.)
>>
>> Here's the error I get when trying to update a working directory.
>>
>> > svn update
>> Updating '.':
>> svn: E170013: Unable to connect to a repository at URL '
>> svn://ohia.cs.yale.edu/cs414-2022f'
>> svn: E170001: SASL authentication error: SASL(-1): generic failure:
>> internal error: failed to init cipher 'rc4'
>>
>> What is the version of Subversion on the above server? What version of
> Sasl and OpenSSL?
>
> subversion:  1.14.2
> cyrus-sasl: 2.1.28
> GNU sasl library (libgsasl): 1.10.0
> OpenSSL: 3.09; also 1.1.1q
>
> The server is running Fedora 38 linux.  I don't know which sasl library
> the server is actually linked to, but the server works find with all
> clients except for the MacPorts one.
>

So it seems you have recent versions of all the libraries, in particular
OpenSSL. Then there should be newer ciphers available on the server side.

The problem seems to be that Sasl3.1 is not upwards compatible with
>> sasl2.
>>
>
> Are you confusing Sasl with OpenSSL here? I believe Sasl is only on
> version 2.1 while OpenSSL recently released versions 3.0 and 3.1 (there
> never was an OpenSSL 2.x).
>
> Yes, I'm afraid so.  
> I believe MacPorts is linking to openssl3, which is why my workaround
> (below) fixes the problem.
>
> This causes the Macports build of svn to fail when attempting to log into
>> a server configured to use_sasl.  A workaround is to rebuild the openssl3
>> port with the command
>>
>> sudo port upgrade --enforce-variants openssl3 +legacy
>>
>> I'm guessing, based on the "+legacy" argument, that the server you try to
> connect to is using RC4 and since this is deprecated in OpenSSL 3 (see
> https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html) you
> are unable to connect.
>
> If this assumption is correct, then this is neither a bug in Subversion,
> nor in Sasl or OpenSSL. Rather it is a case of mismatching configuration
> and software versions between the server and the client. Updating the
> server to support newer chiphers should probably resolve the situation.
>
> I think you are correct in your analysis of why the MacPorts client fails
> to connect without the "+legacy" argument.
>
> I reported this as MacPorts bug #67931
>> <https://trac.macports.org/ticket/67931>.  A comment by ryandesign said,
>>
>>  A port "can't" depend on a variant of another port (see #126). It can use
>>  the active_variants 1.1 portgroup, but that requires manual intervention
>>  from the user, and prevents the buildbot from automatically creating
>>  binary archives of the port.
>>
>>  Have you reported this problem to the developers of Subversion? If not,
>>  please do, and put the URL of the report here.
>>
>> I am attempting to do so here.  Apparently the email is required before I
>> can make a bug report.
>>
>> Please let me know how to proceed with the bug report.
>>
>
> You've done absolutely correct in sending an e-mail here. I assume you
> have already seen the guidance on the website (
> https://subversion.apache.org/docs/community-guide/issues.html) on why we
> don't want anything added to the issue tracker before it has been accepted
> as a bug on the mailing list.
>
> Kind regards,
> Daniel Sahlberg
>
> You've convinced me that this is not a subversion problem but rather one
> of attempting to build it against the openssl3 library rather than against
> the cyrus-sasl2 library.  This would seem to be a problem with the MacPorts
> build script attempting to use the wrong library for subversion.  MacPorts
> does know about cyrus-sasl2 (and in fact it is installed on my node).
> Unfortunately, I do not know enough about how MacPorts works to suggest the
> fix, but I think it is clear now what needs to be done.
>

I think you are mixing up the functions of openssl and cyrus-sasl.

OpenSSL provide encryption while Sasl provide authentication (over an
encrypted channel provided by OpenSSL). So there is no "built against X
rather than against Y", you need both if you want encrypted authentication.

I would look at the server configuration and check the enabled ciphers,
comparing with the your Mac and make sure there is at least one common
cipher. Since both computers have OpenSSL 3, I'm guessing there is a
configuration disabling the newer ciphers on at least one of the machines.

Kind regards,
Daniel

Re: “passwd” file stores plain text passwords - how to protect it

[Daniel Sahlberg]

Den ons 23 aug. 2023 kl 06:32 skrev Channakeshavala, Sriharsha <
s.channakeshav...@sap.com>:

> Thanks for the quick response.
>
>
>
> Subversion credential cache is something that is done on the client side.
>
>
>
> But we have an issue storing plain text passwords in the “passwd” on the
> server side.
>
> Could you please suggest on it.
>

I assume you use plain svnserve (ie, the url start with svn:// ). In that
case I don't think it is possible to protect the passwords. You could
switch to mod_svn (in this case the password is hashed) or use svnserve
over SSH (in which case the user is authenticated by the SSH server).

See the SVN book for a detailed description of the different options:
https://svnbook.red-bean.com/nightly/en/svn.serverconfig.html

Kind regards,
Daniel Sahlberg




>
>
> Your help will be much appreciated.
>
>
>
> Thanks,
>
> Sriharsha
>
>
>
> *From:* Daniel Sahlberg 
> *Sent:* 22 August 2023 16:44
> *To:* Channakeshavala, Sriharsha 
> *Cc:* users@subversion.apache.org
> *Subject:* Re: “passwd” file stores plain text passwords - how to protect
> it
>
>
>
> You don't often get email from daniel.l.sahlb...@gmail.com. Learn why
> this is important <https://aka.ms/LearnAboutSenderIdentification>
>
> Den tis 22 aug. 2023 kl 13:00 skrev Channakeshavala, Sriharsha via users <
> users@subversion.apache.org>:
>
> Hello,
>
>
>
> Since the “passwd” file stores plain text passwords, it is vulnerable for
> the SVN users.
>
> We have not compiled the subversion 1.14.2 with “cyrus SASL” library and
> hence cannot use SASL authentication mechanisms.
>
>
>
> Could you please suggest any other alternative to secure the passwd file ?
>
>
>
> The following FAQ article on the Subversion website should probably answer
> your questions: https://subversion.apache.org/faq.html#plaintext-passwords
>
>
>
> Please note that for Subversion 1.12 until 1.14 the default was to disable
> the plaintext password cache. In Subversion 1.15 the plaintext password
> cache will again be enabled by default.
>
>
>
> Kind regards,
>
> Daniel
>
>
>

Re: passwd file stores plain text passwords - how to protect it

[Daniel Sahlberg]

Den tis 22 aug. 2023 kl 17:53 skrev Bo Berglund :

> On Tue, 22 Aug 2023 17:38:12 +0200, Bo Berglund 
> wrote:
>
> >On Tue, 22 Aug 2023 13:14:25 +0200, Daniel Sahlberg
> > wrote:
> >
> >>Please note that for Subversion 1.12 until 1.14 the default was to
> disable
> >>the plaintext password cache. In Subversion 1.15 the plaintext password
> >>cache will again be enabled by default.
>

Subversion 1.15 is not even released yet, so I probably jumped the gun
slightly. I should have said that "Plans are that Subversion 1.15, when
released, will again enable the plaintext password store by default".

>
> >I am using svn a lot on raspberry pi devices and I have now checked the
> current
> >version on one of them:
> >
> >$ svn --version
> >svn, version 1.14.1 (r1886195)
> >   compiled Apr  5 2022, 23:23:59 on arm-unknown-linux-gnueabihf
> >
> >So in order to get back the file cache again I need a version update,
> right?
>

Yes, either from your distribution's repository or build your own from the
current trunk.

Otherwise you can store the unencrypted password using the script linked in
the FAQ entry previosuly mentioned (
https://subversion.apache.org/faq.html#plaintext-passwords).


> >
> >Does anyone know when Debian will move ahead to 1.15?
> >PiOS is based on Debian, so I guess it will be guided by that...
>
>
> >Or is it possible to force a version update via apt?
>
> Forgot to say that PiOS ia version bullseye at the moment...
>

That is a question better directed to the distribution, of course after
Subversion 1.15 is actually released.

Kind regards,
Daniel Sahlberg

Re: Subversion sasl authentication fails with openssl3.1

[Daniel Sahlberg]

Den sön 20 aug. 2023 kl 17:14 skrev Fischer, Michael <
michael.fisc...@yale.edu>:

> I have many repositories configured for sasl authentication.  The svn
> client for Mac osx, built using MacPorts, recently stopped working.  I
> first reported the problem to the MacPorts bug list but have been advised
> to report it to the subversion developers.  (See below.)
>
> Here's the error I get when trying to update a working directory.
>
> > svn update
> Updating '.':
> svn: E170013: Unable to connect to a repository at URL '
> svn://ohia.cs.yale.edu/cs414-2022f'
> svn: E170001: SASL authentication error: SASL(-1): generic failure:
> internal error: failed to init cipher 'rc4'
>
> What is the version of Subversion on the above server? What version of
Sasl and OpenSSL?

>
> The problem seems to be that Sasl3.1 is not upwards compatible with
> sasl2.
>

Are you confusing Sasl with OpenSSL here? I believe Sasl is only on version
2.1 while OpenSSL recently released versions 3.0 and 3.1 (there never was
an OpenSSL 2.x).

This causes the Macports build of svn to fail when attempting to log into a
> server configured to use_sasl.  A workaround is to rebuild the openssl3
> port with the command
>
> sudo port upgrade --enforce-variants openssl3 +legacy
>
> I'm guessing, based on the "+legacy" argument, that the server you try to
connect to is using RC4 and since this is deprecated in OpenSSL 3 (see
https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html) you are
unable to connect.

If this assumption is correct, then this is neither a bug in Subversion,
nor in Sasl or OpenSSL. Rather it is a case of mismatching configuration
and software versions between the server and the client. Updating the
server to support newer chiphers should probably resolve the situation.

> I reported this as MacPorts bug #67931
> <https://trac.macports.org/ticket/67931>.  A comment by ryandesign said,
>
>  A port "can't" depend on a variant of another port (see #126). It can use
>  the active_variants 1.1 portgroup, but that requires manual intervention
>  from the user, and prevents the buildbot from automatically creating
>  binary archives of the port.
>
>  Have you reported this problem to the developers of Subversion? If not,
>  please do, and put the URL of the report here.
>
> I am attempting to do so here.  Apparently the email is required before I
> can make a bug report.
>
> Please let me know how to proceed with the bug report.
>

You've done absolutely correct in sending an e-mail here. I assume you have
already seen the guidance on the website (
https://subversion.apache.org/docs/community-guide/issues.html) on why we
don't want anything added to the issue tracker before it has been accepted
as a bug on the mailing list.

Kind regards,
Daniel Sahlberg

Re: “passwd” file stores plain text passwords - how to protect it

[Daniel Sahlberg]

Den tis 22 aug. 2023 kl 13:00 skrev Channakeshavala, Sriharsha via users <
users@subversion.apache.org>:

> Hello,
>
>
>
> Since the “passwd” file stores plain text passwords, it is vulnerable for
> the SVN users.
>
> We have not compiled the subversion 1.14.2 with “cyrus SASL” library and
> hence cannot use SASL authentication mechanisms.
>
>
>
> Could you please suggest any other alternative to secure the passwd file ?
>

The following FAQ article on the Subversion website should probably answer
your questions: https://subversion.apache.org/faq.html#plaintext-passwords

Please note that for Subversion 1.12 until 1.14 the default was to disable
the plaintext password cache. In Subversion 1.15 the plaintext password
cache will again be enabled by default.

Kind regards,
Daniel

Re: Unable to commit code in SVN repo

[Daniel Sahlberg]

Den tors 13 juli 2023 kl 18:13 skrev Pothkanoori, Praveen Kumar(HCL) <
praveenkumar.pothkano...@mattel.com>:

> HI Daniel,
>
>
>
> Thanks for the inputs.
>
>
>
> Upon my analysis – I could conclude that pre commit hook error is not
> causing the issue as we could even see these error while commit was working.
>
>
>
> Also, this commit issue started only from June 20, 2023 – some 3 weeks ago.
>
>
>
> I completely understand it is very old version that we are using, but it
> broke suddenly, and no fix is working.
>
>
>
> Can we upgrade to latest version with this issue ongoing? And this upgrade
> doesn’t corrupt the files?
>
>
I would suggest you first run svnadmin verify on the repositories.  Report
back if there are any issues!

Please also verify that there is enough disk space available on the server.

You should be able to upgrade the server without making any changes to the
repositories (however some releases added new features to the repository
format in which case you might want do to a dump/load cycle to access
benefit from the new features). Please check the release notes, for example
https://subversion.apache.org/docs/release-notes/1.14.html (change the
version number in the end of the URL to 1.13, 1.12 etc. for each release
down to 1.6).

Before upgrading, make sure you have a backup of the repositories and the
server.

Kind regards,
Daniel




>
>
> *Best Regards,*
>
> *Praveen Pothkanooru*
>
> *Mattel ECOM Support*
>
> *HCL Tech | Mattel Inc*
>
>
>
> *From:* Daniel Sahlberg 
> *Sent:* Thursday, July 13, 2023 9:34 PM
> *To:* Pothkanoori, Praveen Kumar(HCL)  >
> *Cc:* users@subversion.apache.org
> *Subject:* Re: Unable to commit code in SVN repo
>
>
>
> Hi
>
>
>
> I believe the pre commit hook message is unrelated since it is on a
> completely different date. Anyway you have some information about it in
> Nathan’s mail.
>
>
>
> I’ve searched for MKACTIVITY and error code 500 with very little success
> but some sources point to incorrect file system rights on the server. You
> should probably also run svnadmin verify on your repository (see
>
> https://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.verify.html
> <https://urldefense.com/v3/__https:/svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.verify.html__;!!Hd5UnLY!x0JjYMuE4TyeUHButiACY2o3Ir5onMPE0hdtWfKbv4yrzAHyMEim0zZuiTM1m9tsHlgkfbLSj1aysaO92tjc9kYfLBOOzpXkGzW-V4k$>
> ).
>
>
>
> You are running a version of Subversion that is over 10 years old. While I
> can’t say that this is the cause of your problem, it might be a bug that
> has been fixed in later versions. There may also be security fixes in later
> versions so I really encourage you to upgrade to Subversion 1.14.
>
>
>
> Kind regards
>
> Daniel Sahlberg
>
>
>
> tors 13 juli 2023 kl. 16:08 skrev Pothkanoori, Praveen Kumar(HCL) <
> praveenkumar.pothkano...@mattel.com>:
>
> Hi Daniel,
>
>
>
> Below are the details requested –
>
>
>
> *SVN version*
>
>
>
> $ svn --version
>
> svn, version 1.6.11 (r934486)
>
>compiled Aug  4 2015, 09:07:02
>
>
>
> Copyright (C) 2000-2009 CollabNet.
>
> Subversion is open source software, see http://subversion.tigris.org/
> <https://urldefense.com/v3/__http:/subversion.tigris.org/__;!!Hd5UnLY!x0JjYMuE4TyeUHButiACY2o3Ir5onMPE0hdtWfKbv4yrzAHyMEim0zZuiTM1m9tsHlgkfbLSj1aysaO92tjc9kYfLBOOzpXkyTrFclc$>
>
> This product includes software developed by CollabNet (
> http://www.Collab.Net/
> <https://urldefense.com/v3/__http:/www.Collab.Net/__;!!Hd5UnLY!x0JjYMuE4TyeUHButiACY2o3Ir5onMPE0hdtWfKbv4yrzAHyMEim0zZuiTM1m9tsHlgkfbLSj1aysaO92tjc9kYfLBOOzpXk4LiMc9Q$>
> ).
>
>
>
> The following repository access (RA) modules are available:
>
>
>
> * ra_neon : Module for accessing a repository via WebDAV protocol using
> Neon.
>
>   - handles 'http' scheme
>
>   - handles 'https' scheme
>
> * ra_svn : Module for accessing a repository using the svn network
> protocol.
>
>   - with Cyrus SASL authentication
>
>   - handles 'svn' scheme
>
> * ra_local : Module for accessing a repository on local disk.
>
>   - handles 'file' scheme
>
>
>
> *Linux version *
>
>
>
> $ lsb_release -a
>
> LSB Version:
> :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
>
> Distributor ID: RedHatEnterpriseServer
>
> Description:Red Hat Enterprise Linux Server release 6.10 (Santiago)
>
> Release:6.10
>
> Codename:   Santiago
>
>
>
> *Errors: *
>
>
>
> 10.1.174.152 - - [07/Jul/2023:07:

Re: Use of ssh for authentication?

[Daniel Sahlberg]

Den tors 13 juli 2023 kl 19:08 skrev David Aldrich <
david.aldr...@emea.nec.com>:

> Hi Doug
>
>
>
> Thanks for your reply.
>
>
>
> > Gnome keyring is the normal answer, yes.  Once setup it's pretty stable.
>
>
>
> The issue for us is that I believe Gnome keyring requires a GUI desktop.
> We want something that works in a terminal ssh session (no desktop). Do you
> know of a way around this?
>
>
>
> Would svn+ssh actually avoid password authentication in this scenario?
> Unfortunately, it’s not easy to understand how to go about it.
>

svn+ssh can be made to work this way if you setup public key
authentication. See for example
https://www.ssh.com/academy/ssh/public-key-authentication

The first step is probably to make sure you can access the server via SSH
using your public/private key. Next you must make sure that your user has
write access to the repository. It is possible to configure the server to
only allow SVN access (no shell access) if that is desired.

The Subversion book has a lot of useful information, for example:
https://svnbook.red-bean.com/en/1.7/svn.serverconfig.choosing.html#svn.serverconfig.choosing.svn-ssh
https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth

Of course, if you protect your private key with a passphrase, you will have
to enter that passphrase every time you access the server, basically
substituting one password for another. You can store your private key
without a passphrase but it is up to you to decide if that is acceptable
from a security perspective.

If you allow storing the private key without a passphrase (=> basically
letting anyone with enough authority on the computer to access the home
directory also access the Subversion server) you could also consider
storing the Subversion password in plain text. For more information, see
the following FAQ item on our website:
https://subversion.apache.org/faq.html#plaintext-passwords

Kind regards,
Daniel Sahlberg

Re: Unable to commit code in SVN repo

[Daniel Sahlberg]

Hi

I believe the pre commit hook message is unrelated since it is on a
completely different date. Anyway you have some information about it in
Nathan’s mail.

I’ve searched for MKACTIVITY and error code 500 with very little success
but some sources point to incorrect file system rights on the server. You
should probably also run svnadmin verify on your repository (see
https://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.verify.html).

You are running a version of Subversion that is over 10 years old. While I
can’t say that this is the cause of your problem, it might be a bug that
has been fixed in later versions. There may also be security fixes in later
versions so I really encourage you to upgrade to Subversion 1.14.

Kind regards
Daniel Sahlberg

tors 13 juli 2023 kl. 16:08 skrev Pothkanoori, Praveen Kumar(HCL) <
praveenkumar.pothkano...@mattel.com>:

> Hi Daniel,
>
>
>
> Below are the details requested –
>
>
>
> *SVN version*
>
>
>
> $ svn --version
>
> svn, version 1.6.11 (r934486)
>
>compiled Aug  4 2015, 09:07:02
>
>
>
> Copyright (C) 2000-2009 CollabNet.
>
> Subversion is open source software, see http://subversion.tigris.org/
>
> This product includes software developed by CollabNet (
> http://www.Collab.Net/).
>
>
>
> The following repository access (RA) modules are available:
>
>
>
> * ra_neon : Module for accessing a repository via WebDAV protocol using
> Neon.
>
>   - handles 'http' scheme
>
>   - handles 'https' scheme
>
> * ra_svn : Module for accessing a repository using the svn network
> protocol.
>
>   - with Cyrus SASL authentication
>
>   - handles 'svn' scheme
>
> * ra_local : Module for accessing a repository on local disk.
>
>   - handles 'file' scheme
>
>
>
> *Linux version *
>
>
>
> $ lsb_release -a
>
> LSB Version:
> :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
>
> Distributor ID: RedHatEnterpriseServer
>
> Description:Red Hat Enterprise Linux Server release 6.10 (Santiago)
>
> Release:6.10
>
> Codename:   Santiago
>
>
>
> *Errors: *
>
>
>
> 10.1.174.152 - - [07/Jul/2023:07:31:14 -0700] "MKACTIVITY
> /pvcs/mattel/!svn/act/1ac6f174-a536-ae47-85d4-15f6183c211d HTTP/1.1" 401
> 487 "-" "SVN/1.9.7 (x64-microsoft-windows) serf/1.3.9
> TortoiseSVN-1.9.7.27907"
>
> 10.1.174.152 - DUTTAOIS [07/Jul/2023:07:31:26 -0700] *"MKACTIVITY
> /pvcs/mattel/!svn/act/1ac6f174-a536-ae47-85d4-15f6183c211d HTTP/1.1" 500*
> 620 "-" "SVN/1.9.7 (x64-microsoft-windows) serf/1.3.9
> TortoiseSVN-1.9.7.27907"
>
> 10.1.174.152 - DUTTAOIS [07/Jul/2023:07:31:27 -0700] "DELETE
> /pvcs/mattel/!svn/act/1ac6f174-a536-ae47-85d4-15f6183c211d HTTP/1.1" 500
> 620 "-" "SVN/1.9.7 (x64-microsoft-windows) serf/1.3.9
> TortoiseSVN-1.9.7.27907"
>
>
>
> [Sun May 28 03:38:02 2023] [notice] Apache/2.2.15 (Unix) DAV/2 SVN/1.6.11
> configured -- resuming normal operations
>
> [Wed May 31 01:40:22 2023] [error] [client 10.7.52.182] Could not MERGE
> resource "/repos/wc/!svn/act/f8303ca6-08cd-854f-b08c-4f146a96" into
> "/repos/wc/onestore/branch/WCSPOD_2020/workspace/CSRStores/WebContent/Widgets/MattelCSRLineItemNotes".
> [409, #0]
>
> [Wed May 31 01:40:22 2023] [error] [client 10.7.52.182] Commit blocked by
> pre-commit hook (exit code 1) with
> output:\n\nCOMMIT
> VIOLATION:\nCommit comment must start with Jira issue IDs, like
> ASDF-0001, OWL-1234, AGCUP-567, or NONE, followed by ":"\nRevision
> property "svn:log" did not match regex
> "^((NONE)|((OWL|AEMECOM|CM|AGDT|ADA|AGDH|TPP|DPS|WCSPB)-[0-9]+,?)+):"\nMore
> info at http://svn/repos/wc/onestore/admin/rules.html\n  [409, #165001]
>
> [Wed May 31 10:52:29 2023] [error] [client 10.7.52.182] Could not MERGE
> resource "/repos/wc/!svn/act/cab5ba16-3390-6c47-93a3-92ba30ec5780" into
> "/repos/wc/onestore/tag/QA_latest/workspace/CSRStores".  [409, #0]
>
> [Wed May 31 10:52:29 2023] [error] [client 10.7.52.182] Commit blocked by
> pre-commit hook (exit code 1) with
> output:\n\nCOMMIT
> VIOLATION:\nCommit comment must start with Jira issue IDs, like
> ASDF-0001, OWL-1234, AGCUP-567, or NONE, followed by ":"\nRevision
> property "svn:log" did not match regex
> "^((NONE)|((OWL|AEMECOM|CM|AGDT|ADA|AGDH|TPP|DPS|WCSPB)-[0-9]+,?)+):"\n-

Re: Unable to commit code in SVN repo

[Daniel Sahlberg]

tors 13 juli 2023 kl. 15:11 skrev Pothkanoori, Praveen Kumar(HCL) via users
:

> Hi Team,
>
>
>
> Please help with any solution to fix the code commit issue in SVN repo.
> There is no issue in code check out, only it is throwing below error while
> doing code commits.
>
>
>
> We tried all the major troubleshooting steps to fix the issue – yet it is
> not working.
>
>
>
> Some of selected resources were not committed.
> RA layer request failed
> svn: Commit failed (details follow):
> svn: Unexpected server error 500 'Internal Server Error' on
> '/repos/dca/!svn/act/593a4397-bae7-704a-a828-6e8f2d1aee63'
> Additional errors:
> RA layer request failed
> svn: Unexpected server error 500 'Internal Server Error' on
> '/repos/dca/!svn/act/593a4397-bae7-704a-a828-6e8f2d1aee63'
>
>
>
> *Regards,*
>
> *Praveen Pothkanoori*
>
> *ECOM Support | India*
>

What version are you running (both server and client)?

Are there any error messages in the server logs?

Kind regards
Daniel Sahlberg

Re: calling svnsync synchronize

[Daniel Sahlberg]

Den fre 23 juni 2023 kl 14:55 skrev Steudel, Philipp <
philipp.steu...@worldline.com>:

> Hi support,
>
>
>
> calling svnsync synchronize now ends in attached dump.
>
> First I got a message like “Failed to load module for FS type 'bdb'
> tortoise” or like
>
>
>
> svnsync: E170013: Unable to connect to a repository at URL 'file:///…'
>
> svnsync: E180001: Unable to open repository 'file:///…'
>
> svnsync: E160043: Expected FS format between '1' and '7'; found format '8'
>
>
>
> although in the file format there was a 5.
>
>
>
> I tried different numbers, but got the message above or to use 5 or 7, but
> after some trials now I get this hard error.
>
>
>
> How can I synchronize my repo successfully?
>

Did you change anything in any of the repository files? That is not
supported and you have a high risk of ruining things. Please restore any
changes and check the original error message.

You mention "bdb" and "tortoise" leading me to believe you have installed
TortoiseSVN and trying to access a repository in the bdb format. I don't
think TortoiseSVN is capable of accessing a BDB repository (since the
required modules are not included in the default compilation settings -
maybe you can get lucky if you find a really old version). Some more
information on the bdb format:
https://subversion.apache.org/faq.html#bdb-fsfs-convert

Kind regards,
Daniel Sahlberg

Re: svn up -r {DATE} returns E1000104

[Daniel Sahlberg]

Den tis 13 juni 2023 kl 17:33 skrev Mun Johl :

[... snip ...]

> Which protocol do you use for accessing the repository? (svn info
> --show-item url should give the url, the protocol is the first part)
>
>
>
> *[Mun] svn:*
>

Thanks for checking! Then we need to look at svnserve.

Can you figure out how it is started? It can be run either in daemon mode
(starting as a standalone daemon using the -d | --daemon argument) or
started from [x]inetd (using the -i | --inetd argument).

Do you see anything in the server log files?
>
>
>
> *[Mun] Our Linux Administrator stated he didn’t see anything pertinent in
> the server logs.  Is there any way to increase verbosity or something so as
> to log debug information?*
>

I haven't used svnserve myself in production so I'm a little bit in the
dark here, but if I'm reading the code correctly you need to add the
--log-file FILENAME argument when you start svnserve. How to do this
depends on if you run the service as a daemon or from x[inetd], and also
depends on your Linux distribution.

Is it a large repository and could it by any chance be a network issue,
> where the network connection times out while Subversion is trying to find
> the revision number corresponding with the date?
>
>
>
> *[Mun] I wouldn’t necessarily consider it a large repository—but it’s not
> small either.  Your network issue concern is interesting since the server
> is now at a different corporate site.  However, empirically I would have
> expected that perhaps the issue would be intermittent if it were a network
> issue.  This problem occurs every time I’ve tried the command—even at
> different times of the day.  Not that that proves anything—it’s just meant
> to be a data point.*
>
>
>
> *I’ve tried the command in a branch that isn’t very large—but maybe that
> doesn’t make a difference if it’s the total repository size that makes a
> difference—and I still had the same issue with ‘svn up -r {DATE}’.*
>

These are valid points. There could still be a network issue, for example a
package inspecting firewall that trigger on something when you run svn up
-r {DATE}, but I agree this seems unlikely. Still, to rule out network
issues, can you try the same command on the svn server itself or at least
from a computer on the same site/network? If you don't have access, maybe
the Linux admins can help you out.

Kind regards,
Daniel Sahlberg

Re: svn up -r {DATE} returns E1000104

[Daniel Sahlberg]

Den mån 12 juni 2023 kl 20:45 skrev Mun Johl :

> Hi all,
>
>
>
> Let me start out by saying I know we are on an old version of SVN on
> RHEL7, and I apologize in advance for that fact.  Our SVN revision is:
> v1.9.12
>
>
>
> We had to obsolete our old local SVN server and then we moved to a remote
> VM running the aforementioned version of SVN.  Our old local SVN server was
> running v1.9.3 .  We were trying to keep the SVN revision on the new server
> close to what we were running in the past to try and avoid any disruptions.
>

You should be able to update to any later server version without any
problem. Older clients might not be able to use all the features of the new
server but there should be cross compatibility with all versions.


>
> Just about everything on the new SVN server works fine, except for: ‘svn
> up -r {DATE}’.  That command returns the following output:
>
> Updating '.':
>
> svn: E000104: Can't read from connection: Connection reset by peer
>

Which protocol do you use for accessing the repository? (svn info
--show-item url should give the url, the protocol is the first part)

Do you see anything in the server log files?

Is it a large repository and could it by any chance be a network issue,
where the network connection times out while Subversion is trying to find
the revision number corresponding with the date?

Kind regards,
Daniel Sahlberg

>

Re: Build Error When Running make swig-pl-lib on Centos 7/Perl 5.36.1/Swig 4.1.1 - Subversion 1.14.2

[Daniel Sahlberg]

Den tors 25 maj 2023 kl 19:41 skrev Rahr, Jeffrey A (US) <
jeffrey.r...@baesystems.com>:

> I am trying to build the perl swig links in Subversion 1.14.2.
>
> Unfortunately this is on a non internet connected system with no ability
> to export build logs.
>
>
> Environment:
>
> Centos 7
>
> Perl 5.36.1
>
> Swig 4.1.1
>
> gcc 4.8.5
>
>
> make swig-pl-lib
>
> generates a message of "PL_current_context" undeclared on the line - #
> define PERL-GET-CONTEXTPL_current_context
>
> in the file perl/5.36.1/lib/5.36.1/x86_64-linux-thread-multi/CORE/thread.h
>
>
> Anyone have any idea where PL_current_context is defined? Guessing this is
> more of a subversion/perl integration issue as opposed to a subversion
> issue and possibly a problem with the perl build and a libc (v2.17) that is
> no longer being updated on Centos 7.
>

I'm by no means a Perl expert, but I just downloaded 5.36.1 from perl.org
and in this archive, the file thread.h contains the following
(lines 386-388):
[[[
extern PERL_THREAD_LOCAL void *PL_current_context;

#  define PERL_GET_CONTEXTPL_current_context
]]]
(I assume the "-" in your message was mistyped.). Is it the same in your
thread.h? The paths you mention doesn't quite match up so maybe there is
something with your perl source.

Kind regards,
Daniel Sahlberg

Update WANdisco links on /packages.html (Was: Re: Hello)

[Daniel Sahlberg]

Den ons 24 maj 2023 kl 21:58 skrev Doug Robinson :

> WANdisco stopped requiring registration to download Subversion binaries a
> while ago.  Please check out [4].
> Can we get the Apache website updated?
>

Thanks Doug for pointing this out. I've updated the website in r1910032 and
merged to site/publish in r1910034.

Kind regards,
Daniel Sahlberg

Re: Hello

[Daniel Sahlberg]

I'm afraid the reply you already received on the dev@ list [1] is about the
best reply you can get: You need to find and install a newer version of the
Subversion Edge server. Unfortunately it seems that Collab.Net (now part of
Digital.AI) has decided to remove Subversion Edge from their website. (In a
related e-mail thread, it has been decided that the Subversion project will
remove the links to Collab.Net from the Binary packages webpage[3], since
it doesn't offer a download anymore).

>From the paths in the error message, it seems you are running your server
on Windows. There are two different vendors listed on the Binary packages
webpage [3], you can probably download one of them and configure to use the
existing repositories.

Kind regards,
Daniel Sahlberg

[1] https://lists.apache.org/thread/cshn51y8psq4n4nt8lxz31b6nxjrqc1f
[2] https://lists.apache.org/thread/lyzrdm9hr7fo5z21zho72j8n3kx2h4b7
[3] https://subversion.apache.org/packages.html#windows

Den mån 22 maj 2023 kl 14:02 skrev Yaniv Waldman :

>
>
>
>
> Hello
>
>
>
> I’m forwarding this Email after contact Pavel Lyalyakin , Basically he
> said that I need to upgrade my svn version.
>
>
>
> This is the original mail I sent -
>
>
>
>
>
> Hello
>
> I hope you can assist me
>
>
>
> I had to reinstall collabnet subversion svn server, and some of my
> repositories are not working.
>
> I assume it’s because different versions.
>
>
>
> My svn server is 3.3.1
>
>
>
> The error is –
>
>
>
> Python Traceback
>
>
>
> Traceback (most recent call last): File "C:\csvn\lib\viewvc\viewvc.py",
> line 4872, in main request.run_viewvc() File
> "C:\csvn\lib\viewvc\viewvc.py", line 321, in run_viewvc self.repos.open()
> File "C:\csvn\lib\viewvc\vclib\svn\svn_repos.py", line 387, in open
> self.repos = repos.svn_repos_open(self.rootpath) File
> "C:\csvn\lib\svn-python\libsvn\repos.py", line 211, in svn_repos_open
> return _repos.svn_repos_open(*args) SubversionException: 160043 - Expected
> FS format between '1' and '4'; found format '6
>
>
>
> I think I need to upgrade to version 4.0.11
>
> But I can’t find any site with this installation file.
>
>
>
> Can you help me with that please  ?
>
>
>
> Yaniv
>
> Benarit LTD
>
>
>

Re: display web contents from svn repository

[Daniel Sahlberg]

Den mån 24 apr. 2023 kl 20:16 skrev Marco Asa :

> Nice, I was not aware of hooks and post-commit would work very nicely
> for the pourpose. I still had to make it work in a convoluted way
> since I deployed the svm server manager in an isolated container and
> the post-commit hook could not access directly the checkout that i
> need to update. Still, I could easily exploit the hook to write date
> and revision number in a text file accessible to both the container
> and the host; this file became my target to monitor with incron which
> is now triggered only once per commit.
>

Good to hear, thank you for reporting back on the mailing list!

Kind regards,
Daniel

Re: display web contents from svn repository

[Daniel Sahlberg]

Den mån 24 apr. 2023 kl 13:19 skrev Marco Asa :

> Hello,
>
> I set up a combined svn server / web server where the latter displays
> contents taken directly from one of the repositories. It runs fine but
> I would like to make it work a bit more efficiently.
>
> At the moment it works like this:
> 1) Both the svn repository and one checkout of it in "/example" are
> hosted on the same machine
> 2) the svn repository folder  is monitored for changes by an incron job
> 3) when a file modification is made to the repository (by a commit for
> instance), incron triggers svn update /example
> 4) the webserver points to /example and displays /example/index.html
>
> My two questions are the following
> a) can I avoid the checkout altogheter and save disk space? I.e.can I
> configure the svn server so that I could take html pages and related
> images directly from the HEAD revision?
>

If the SVN repository is available over http/https, then it should be
possible to configure mod_rewrite so that any access to the web server is
redirected to the Subversion server.

For example, the Subversion projects front page is available directly from
SVN here:
https://svn.apache.org/repos/asf/subversion/site/publish/index.html

(It looks like crap, since the page require the use of server side includes
to render some part of the page including a lot of the page structure).

I would assume serving the page this way would require a lot more CPU
cycles compared to serving it directly from the file system so depending on
your use case it might not be feasible.


> b) If not, I would like to improve step 3). At the moment svn update
> is called tens of times for each commit (any kind of modification
> triggers it as I am looking at the whole folder). What would be a good
> file to monitor with incron in the repository that will always be
> modified by a new commit?
>

Even if you find such a file, there is always a risk a future version of
Subversion accesses the repository differently making this a fragile
solution. It is probably better to look at a post-commit repository hook,
see the SVN book [1]. The hook should trigger only once and only after
completion of commits. I assume (although I never investigated) that the
Subversion website is handled this way - on updates we just commit to
https://svn.apache.org/repos/asf/subversion/site/publish/ and it appears
within a moment on https://subversion.apache.org/.

I hope it works out for you!

Kind regards,
Daniel Sahlberg

[1] https://svnbook.red-bean.com/en/1.7/svn.ref.reposhooks.post-commit.html



> Thanks for your attention,
> --
> Asa Marco  朝
>

Re: Crashes in subversion with unexpected targets

[Daniel Sahlberg]

Den tors 20 apr. 2023 kl 01:22 skrev sebb :

> On Wed, 19 Apr 2023 at 23:52, Daniel Sahlberg
>  wrote:
> >
> > Den ons 19 apr. 2023 kl 11:44 skrev sebb :
> >>
> >> I've seen some crashes in SVN where the target does not have the
> expected type.
> >
> >
> > Both asserts also on a recent trunk build, so at least it isn't resolved
> yet.
> >
> >>
> >>
> >> For example:
> >>
> >> $ svn info https://www.apache.org/foundation/records/990-2016.pdf
> >> svn: E235000: In file
> >>
> '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c'
> >> line 96: assertion failed
> >> (svn_uri__is_ancestor(pathrev->repos_root_url, url))
> >> Aborted (core dumped)
> >
> >
> > The same assert has been reported previously (
> https://lists.apache.org/thread/s24v9f8klx8pwn9lk0oqxng1cpxg12vw)
> although with a different use case.
> >
> > From what I can see in GDB, Subversion seems to be able to open a WebDAV
> session with www.apache.org. It asks for the
> DAV:version-controlled-configuration which seems to return
> https://www.apache.org/repos/asf. Now, since
> https://www.apache.org/foundation/records/ is not a child of
> https://www.apache.org/repos/asf it triggers an assert.
> >
> > Is it correct that https://www.apache.org/foundation/records/ responds
> to WebDAV commands, and why does it reply with
> https://www.apache.org/repos/asf?
>
> No idea. The redirect works fine for the main purpose which is
> displaying a PDF file from SVN.
>

Which redirect? Subversion handles a 301/302 redirect just fine. The
headers looks like a file served directly from the web server. (Maybe there
is a behind-the-scenes redirect somehow that doesn't show here, but then
should the server really reply to DAV requests?

[[[
C:\Users\dsg>curl -I https://www.apache.org/foundation/records/990-2016.pdf
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 329732
Server: Apache
Last-Modified: Sat, 15 Apr 2023 10:22:29 GMT
ETag:
"1909150//infrastructure/site/trunk/content/foundation/records/990-2016.pdf"
Cache-Control: max-age=604800, max-age=3600
Content-Type: application/pdf
Via: 1.1 www.apache.org, 1.1 varnish, 1.1 varnish
Expires: Mon, 17 Apr 2023 13:30:44 GMT
Content-Security-Policy: default-src 'self' 'unsafe-inline'
https://www.apachecon.com/ https://www.google.com/cse/
https://cse.google.com/ https://www.googleapis.com/generate_204 http://*.
google.com/generate_204 https://afs.googlesyndication.com/
https://csp.withgoogle.com/ https://www.google.com/images/
https://ssl.gstatic.com/ui/ https://docs.google.com/forms/
https://www.youtube.com/embed/; script-src 'self' 'unsafe-inline'
'unsafe-eval' https://cse.google.com/
http://cse.google.com/adsense/search/async-ads.js
https://www.google.com/cse/ https://partner.googleadservices.com/;
style-src 'self' 'unsafe-inline' https://www.google.com/cse/;
frame-ancestors 'none';
Strict-Transport-Security: max-age=31536000; preload
Accept-Ranges: bytes
Date: Thu, 20 Apr 2023 06:01:27 GMT
Age: 0
X-Served-By: cache-hel1410029-HEL, cache-bma1680-BMA
X-Cache: HIT, HIT
X-Cache-Hits: 1, 1
X-Timer: S1681970487.818068,VS0,VE377
Vary: Accept-Encoding
]]]


Kind regards,
Daniel

Re: Crashes in subversion with unexpected targets

[Daniel Sahlberg]

Den ons 19 apr. 2023 kl 11:44 skrev sebb :

> I've seen some crashes in SVN where the target does not have the expected
> type.
>

Both asserts also on a recent trunk build, so at least it isn't resolved
yet.


>
> For example:
>
> $ svn info https://www.apache.org/foundation/records/990-2016.pdf
> svn: E235000: In file
>
> '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c'
> line 96: assertion failed
> (svn_uri__is_ancestor(pathrev->repos_root_url, url))
> Aborted (core dumped)
>

The same assert has been reported previously (
https://lists.apache.org/thread/s24v9f8klx8pwn9lk0oqxng1cpxg12vw) although
with a different use case.

>From what I can see in GDB, Subversion seems to be able to open a WebDAV
session with www.apache.org. It asks for the
DAV:version-controlled-configuration which seems to return
https://www.apache.org/repos/asf. Now, since
https://www.apache.org/foundation/records/ is not a child of
https://www.apache.org/repos/asf it triggers an assert.

Is it correct that https://www.apache.org/foundation/records/ responds to
WebDAV commands, and why does it reply with https://www.apache.org/repos/asf
?

I'm leaning towards an incorrect server configuration.

$ svn pl -v https://dist.apache.org/repos/dist/dev/whimsy/test.txt
> Properties on 'https://dist.apache.org/repos/dist/dev/whimsy/test.txt':
>   svn:eol-style
> native
>
> $ svn ps svn:mime-type text/plain
> https://dist.apache.org/repos/dist/dev/whimsy/test.txt
> svn: E235000: In file
>
> '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_subr/dirent_uri.c'
> line 1634: assertion failed (! svn_path_is_url(relative))
> Aborted (core dumped)
>

Setting a versioned property on a URL is not supported if I'm reading the
SVN Book correctly (
https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.ref.svn.c.propset).
It is obviously wrong to hit an assertion, there should be an error message
instead if trying to operate on a URL. I did a very quick sketch and it
seems easy enough (a few lines of code in propset-cmd.c), but it is getting
too late to get it into style and run all testcases tonight.

Feel free to add this as an issue in JIRA.

For the record, if someone else sees this thread. svnmucc should be the
correct tool in this case, it will create a new revision adding the
versioned property to the URL target.

Kind regards,
Daniel

Re: Spurious "server ... does not support the HTTP/DAV protocol" error

[Daniel Sahlberg]

Den ons 19 apr. 2023 kl 16:47 skrev Ian Miller :

> This is not a problem on the server.  As I wrote in my original e-mail,
> there is no network traffic at all between the client and server in the
> failure case.
>
> I have confirmed this by reproducing the problem when the server has its
> network cable unplugged.   I know what the message is supposed to mean, but
> the client is reporting the wrong error.
>
> After some further experimentation, I have come to the conclusion that it
> is treating the hostname “svn” specially.  The host has another hostname in
> DNS and I can correctly access the server using that name.
>

I don't think there is any special treatment of the hostname "svn" within
the Subversion codebase. As a test, I added "svn" in my hosts file and I
was able to checkout http://svn/svn/repo just fine. (The server would
normally be http://some.domain.tld/svn/repo).

I suspect that you have some special handling of "svn" on your
computer/local network. Either you have it in the hosts file or you have a
domain suffix search list specified and svn.searchlist.domain resolves to a
different machine compared to the FQDN you are using.

What IP address is used if you try to ping just svn? What IP address is
used if you ping the FQDN?

[[[
C:\Users\dsg>ping svn

Pinging svn [192.168.193.10] with 32 bytes of data:
Reply from 192.168.193.10: bytes=32 time=4ms TTL=64
...
]]]

It is conceivable that there is a DNS resolver problem.  However the error
>> message being produced is completely wrong and grossly misleading.
>>
> The error message indicates that there is a server responding on whatever
IP address "svn" resolves to. If you would use an address that is not
resolvable you would get an error message indicating unknown hostname. If
you use the correct host name but an incorrect repository or an incorrect
path within that repository you will get two other error messages
indicating that Subversion is unable to connect to the repository or the
path doesn't exist.

If the address actually resolves to something, it is impossible to say if
that result is wrong (compared to what you expect). Thus the error message
can only say "we found a server at the requested address but it doesn't
want to speak to us". I can agree that the "HTTP/DAV protocol" is not very
helpful but rather technical.

Kind regards,
Daniel

Re: svnlook history is not working with a subpath?

[Daniel Sahlberg]

Den tis 18 apr. 2023 kl 18:44 skrev Laurens Rodriguez :

> Hello,
> I'm trying to get the history of a subpath from a repository with:
> /usr/bin/svnlook history -r 1000 -l 5 /path/to/my/repo /trunk
> I'm sure the path /trunk exists, but it is failing with:
>
> REVISION   PATH
>    
> svnlook: E160013: File not found: revision 1090, path '/trunk'
>
> If I try with:
> /usr/bin/svnlook history -r 1000 -l 5 /path/to/my/repo /
> or omitting the path completely:
> /usr/bin/svnlook history -r 1000 -l 5 /path/to/my/repo
>
> it works as expected:
> REVISION   PATH
>    
> 1090   /
> 1089   /
> 1088   /
> 1087   /
> 1086   /
>

Are you sure /trunk actually existed in revision 1000? I've made a quick
test, /trunk was added in revison 15 in my test repo. This is what I get:

[[[
daniel@srv:~$ svnlook history -r 14 -l 5 /data/svn/test/ /trunk
REVISION   PATH
   
svnlook: E160013: File not found: revision 14, path '/trunk'
daniel@srv:~$ svnlook history -r 15 -l 5 /data/svn/test/ /trunk
REVISION   PATH
   
  15   /trunk
]]]

My version is:
>
> svnlook, version 1.9.7 (r1800392)
>compiled May 21 2022, 07:24:25 on x86_64-pc-linux-gnu
>

Please note that Subversion 1.9 is out of support since a few years. I
don't think it matters in this case since I can reproduce the issue even
with the latest version. But there may be bugs or even security issues that
won't be fixed in 1.9.

Kind regards,
Daniel Sahlberg

Re: When backing up an svn server, why shouldn't we use copy and move provided by linux and should we use svnadmin dump?

[Daniel Sahlberg]

Den mån 17 apr. 2023 kl 17:44 skrev 김성민 [넷마블에프앤씨/R빌드파트] <
sungmin4...@nm-fc.com>:

> hello. I am sending an e-mail because I have a question during the svn
> backup process.
>
> When backing up svn, you are backing up using svnsync or dump.
>
> However, if you try to move and use the copy command or move command
> provided by linux os
>
> to change only the location on the same computer (server), normal
> operation is impossible.
>
> Could you please explain the reason for this?
>

Do I understand it correctly that you have moved the repository using mv(1)?

In that case it depens on how you access your repository. If you are using
HTTP/mod_dav_svn then you need to update your httpd configuration to point
to the new location of the repository. If you are using plain svnserve you
should update your service configuration. If you are accessing the
repository via the file:// protocol, you can use the svn relocate command
to point your working copy to the new location.

Kind regards,
Daniel

Re: Spurious "server ... does not support the HTTP/DAV protocol" error

[Daniel Sahlberg]

Den mån 17 apr. 2023 kl 20:20 skrev Ian Miller :

> Before reporting this as a bug, I am posting it here as suggested on the
> “How to report a bug” page.
>
> After upgrading my O/S to Debian 11, and with it the subversion client to
> version 1.14.1 (r1886195), I started getting
> the following error whenever I tried to access the server:
>
> svn: E175003: The server at 'http://svn/singularis/trunk' does not
> support the HTTP/DAV protocol
>
> I checked to see what the network traffic associated with this and found
> that there was none.  I get the same error attempting make a new checkout.
> However if I substitute the server’s IP address into the URI it works.
> It also works with a FQDN.   It seems that it failing resolve the
> hostname.   Everything else on the host seems to be able to resolve the
> hostname.  /etc/resolv.conf seems to be correct.
>
> It is conceivable that there is a DNS resolver problem.  However the error
> message being produced is completely wrong and grossly misleading.
>

The error message basically means that the URL supplied by the client isn't
an SVNPath in the server conf.

Could it be that the HTTPD configuration has several virtual hosts where
the ServerName "svn" is handled by another virtual host compared to the
FQDN?

Kind regards,
Daniel

Re: OpenSSL 1.1.x EOL - upgrade to 3.x planned?

[Daniel Sahlberg]

Den ons 5 apr. 2023 kl 20:51 skrev Andreas Stieger :

> Hello,
>
> > [OpenSSL 3.0 and Apache Subversion]
>
> Subversion supports OpenSSL 3 if serf (it's http library dependency) or,
> respectivey, httpd (for mod_dav_svn) are build against it:
>

FWIW: I spent the weekend switching TortoiseSVN to OpenSSL 3.1.0. It was a
very straightforward process apart with only some minor adjustments in the
TSVN build process and the issue below.

If you are looking for a patch to make serf work with OpenSSL 3 here is one:
>
> https://build.opensuse.org/package/view_file/devel:libraries:c_c++/libserf/openssl3.patch
> I can check if this is still needed. If not this may be easier for you. If
> not serf might want to do a release.
>

Serf has been patched to work with OpenSSL (r1901937), but it has not been
released yet, so there might be some patching needed for building Serf
1.3.9. I've sent a mail to the Serf mailing list [1] to see if something
can be done to speed up a release. I ended up building against Serf trunk
for the moment.

Kind regards,
Daniel Sahlberg

[1] https://lists.apache.org/thread/6m7s6pwjzvjh4w8rvc133rq3jmwqtjmg

Re: Test suite fails when run in parallel for i686-linux

[Daniel Sahlberg]

Den lör 8 apr. 2023 kl 21:18 skrev Maxim Cournoyer <
maxim.courno...@gmail.com>:
[...]

Thanks for your help in verifying my environment!


> > I'm currently leaning towards something fishy with compiler/libraries
> used
> > in guix. I'm trying to figure out exactly how this goes wrong, but
> threads
> > programming is far from my comfort zone. In case anyone else would like
> to
> > pick up, feel free!
>
> I think the problem probably be reproducible from another i686-linux
> distribution; perhaps it could be tried using Docker for example.
>

I've spent the afternoon setting up two virtual machines under Virtual Box
6.1:

- Debian 11.6 i386 (uname -a says "5.10.0-21-686 #1 SMP Debian 5.10.162-1
(2023-01-21 i686 GNU/Linux")

- Guix 1.4.0 i686 (uname -a says "6.0.10-gnu #1 SMP PREEMPTY_DYNAMIC 1 i686
GNU/Linux")

Both are assigned 6 CPUs each and 4GB memory. Both run APR 1.7.0

On the Debian machine, I've checked out Subversion trunk and on Guix I've
downloaded the distrubution tarball for 1.14.2.

Both are configured with --enable-maintainer-mode and nothing else. On the
Debian machine I have gcc 10.2.1-6. On Guix, I did "guix install gcc@10.3".
I've also added libraries as needed to have configure complete
successfully. Unfortunately, I can't figure out some libraries/function
under Guix, for example Serf, Boost and APXS (for building mod_dav_svn).

On the good side: Under Guix, I can reproduce the same error as Maxim,
mostly the assert on put_xlate_handle_node. I've run the test suite 5 times
and only once was it successful. This at least proves there isn't a problem
in the way the Guix system download and configure Subversion.

However under Debian, I can't see the same error. I've run the test suite
at least 5 times and not a single failure.

I've checked apr.h on both systems and APR_HAS_THREADS is 1 on both of them.

At this point, I can't figure out what else to do. To me it still seems
there is something strange with the Guix environment / distribution.
Obviously the tests above are not completely the same, for example because
of the differences in libraries I'm using (in particular, I can't see if
there was any specific options in the APR build).

Kind regards,
Daniel

Re: Test suite fails when run in parallel for i686-linux

[Daniel Sahlberg]

Den mån 3 apr. 2023 kl 17:35 skrev Maxim Cournoyer <
maxim.courno...@gmail.com>:

> Oh.  This suggests your installation does not make use of the available
> binary substitutes that would dramatically speed things up and
> workaround the bug you encountered (which is caused by TLS certificates
> expiring in the OpenSSL test suite, see:
> https://issues.guix.gnu.org/56137).
>

I used the --no-substitutes argument as suggested. Maybe this is the reason?

The substitute servers key should have been authorized at installation
> by the guix-install.sh script, and Guix as of 1.4.0 uses both
> 'https://ci.guix.gnu.org' and 'https://bordeaux.guix.gnu.org' as its
> default substitute providers.
>
> What does 'cat /etc/guix/acl' show?  It should have something like, the
> first entry being Bordeaux and the second one for Berlin.
>
> --8<---cut here---start->8---
> (acl
>  (entry


[...]

  )
> )
> --8<---cut here---end--->8---
>

I have the same keys, only in opposite order.


> 'guix weather openssl' should show it being available.  I'd also like to
> see the output of 'guix describe', to know from on which commit your
> Guix is at.
>

dsg@dsg-ubuntu2210:~$ guix weather openssl
hint: Consider installing the `glibc-locales' package and defining
`GUIX_LOCPATH', along these lines:

 guix install glibc-locales
 export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

computing 1 package derivations for x86_64-linux...
looking for 3 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org ☀
  100.0% substitutes available (3 out of 3)
  at least 11.4 MiB of nars (compressed)
  32.6 MiB on disk (uncompressed)
  0.977 seconds per request (2.9 seconds in total)
  1.0 requests per second

  at least 1,000 queued builds
  aarch64-linux: 947 (94.7%)
  powerpc64le-linux: 51 (5.1%)
  i686-linux: 2 (.2%)
  build rate: 13.32 builds per hour
  i686-linux: 5.36 builds per hour
  x86_64-linux: 4.97 builds per hour
  aarch64-linux: 2.18 builds per hour
  powerpc64le-linux: 0.83 builds per hour
  armhf-linux: 0.04 builds per hour
looking for 3 store items on https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org ☀
  100.0% substitutes available (3 out of 3)
  at least 7.8 MiB of nars (compressed)
  32.6 MiB on disk (uncompressed)
  0.244 seconds per request (0.7 seconds in total)
  4.1 requests per second
  (continuous integration information unavailable)
dsg@dsg-ubuntu2210:~$ guix describe
hint: Consider installing the `glibc-locales' package and defining
`GUIX_LOCPATH', along these lines:

 guix install glibc-locales
 export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

Generation 1Apr 02 2023 09:27:21(current)
  guix f0c8cb4
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: f0c8cb44a4d912263025616bc921c011fcb1f0b4

If it isn't try with --substitute-urls; perhaps the default ones differ
> for some reason:
> --8<---cut here---start->8---
> guix weather openssl \
>   --substitute-urls='https://bordeaux.guix.gnu.org https://ci.guix.gnu.org
> '
> --8<---cut here---end--->8---
>

In the meantime, I manually set the date/time to 2022-01-01 and that seemed
to do the trick. The build completed successfully.

In the Subversion build/test I see the same errors you have. I then did:

[[[
$ guix build --no-substitutes --no-grafts --system=i686-linux --keep-failed
subversion
...
$ cd /tmp/guix-build-subversion-1.14.2.drv-0/
$ source environment-variables
$ cd subversion-1.14.2
$ make check -j4 PARALLEL=4
]]]

This is now a functional environment to do more tests. I've been able to
reproduce the error in this environment.

If I did the same, without sourcing the environment variables (I had to
make clean; ./config.nice before make), ie using the compiler and libraries
included with the distribution, the tests succeed.

I'm currently leaning towards something fishy with compiler/libraries used
in guix. I'm trying to figure out exactly how this goes wrong, but threads
programming is far from my comfort zone. In case anyone else would like to
pick up, feel free!

Kind regards,
Daniel

Re: Checkout problem via http with file external pointing at redirected URL

[Daniel Sahlberg]

Den sön 12 mars 2023 kl 22:46 skrev Nathan Hartman :

> On Tue, Feb 7, 2023 at 9:05 AM Baldauf Christoph
>  wrote:
> >
> > Hi,
> >
> > I think, I encountered a problem with the handling of file externals
> > that point to a redirected URL.
> > It looks to me like this issue is related to
> > https://issues.apache.org/jira/browse/SVN-4428, with the difference,
> > that file externals are involved instead of normal externals.
> > When doing a checkout of a project that contains such file externals,
> > the command line client returns the following error message:
>

[...]


> Thanks for the report.
>
> The issue is confirmed to still exist in 1.14.2: See the mail Pál
> Kovács to users@s.a.o with title "redirection error with file
> externals - possible bug" dated Saturday, March 11, 2023, archived
> https://lists.apache.org/thread/go4r3lflzy7yvq7bt4rnofyc46n59whh (and
> other places).
>
> I have filed this issue as SVN-4911:
> https://issues.apache.org/jira/browse/SVN-4911
>
> Until it is fixed, have you found any kind of workaround that might
> benefit other users?
>
> Thanks,
> Nathan
>

For the benefit of everyone watching this thread I'm cross posting what
I've already written in the other thread:

The issue #4428 was fixed in r1525902 but only for directory externals. The
same fix could be applied for file externals and I've committed a fix as
r1908926.

I will also nominate this fix for backport to 1.14.

Kind regards,
Daniel Sahlberg

Re: redirection error with file externals - possible bug

[Daniel Sahlberg]

Den sön 2 apr. 2023 kl 20:08 skrev Daniel Sahlberg <
daniel.l.sahlb...@gmail.com>:

> I've spent some time today looking at the issue. I've been able to
> reproduce it, but my reproduction is not in a shape where I can share it.
>
> Basically I've setup a server where the repository was hosted at
> http://localhost/repo, configured an external. Then reconfigured the
> server so the repository is at http://localhost/r2 with
> http://localhost/repo issuing a http level redirect to /r2.
>
> I'm then able to reproduce the issue.
>
> Den sön 12 mars 2023 kl 22:42 skrev Nathan Hartman <
> hartman.nat...@gmail.com>:
>
>> On Sat, Mar 11, 2023 at 4:29 PM Daniel Sahlberg <
>> daniel.l.sahlb...@gmail.com> wrote:
>>
>>> Den lör 11 mars 2023 kl 13:06 skrev Pál Kovács <81.kovacs...@gmail.com>:
>>>
>>>>
>>>>
>>>> Dear All,
>>>>
>>>> I'd like to setup http traffic to be redirected to https on our svn
>>>> server.
>>>> Redirection works all right in most of the cases, except when we have a
>>>> file-external with http in the url.
>>>> For file-externals, svn export works as expected (in the export log it
>>>> is visible that there was a redirection and the file is fetched).
>>>> However when trying to checkout a working copy, file-externals are not
>>>> downloaded, the log shows errors like this:
>>>>
>>>> Redirecting to URL '
>>>> https://myserver/svn/myrepo/TestFolder/Project2/test.txt':
>>>> Fetching external item into 'checkout_target\test.txt':
>>>> svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed:
>>>> EXTERNALS.def_repos_relpath
>>>>
>>>
> This error occurs in subversion/libsvn_wc/wc_db.c line 3365 (as of
> r1908925), where ieb->recorded_repos_relpath is null for a file external.
> For a folder external, it contains the folder name.
>
> I didn't check where recorded_repos_relpath came from but I think this is
> the logical next step.
>
>
>> I found a similar bug report for folder-externals, which was fixed in SVN
>>>> 1.8.5
>>>>
>>>> https://issues.apache.org/jira/browse/SVN-4428
>>>>
>>>
> I'm running out of time to check r1525902 (as referenced by this issue)
> but maybe this problem was fixed for folders and a similar fix can be
> applied also for files.
>

r1525902 indeed fixed the problem but only for directory externals. The
same fix could be applied for file externals and I've committed a fix as
r1908926.

I will also nominate this fix for backport to 1.14.

Kind regards,
Daniel Sahlberg

Re: Test suite fails when run in parallel for i686-linux

[Daniel Sahlberg]

Den sön 2 apr. 2023 kl 05:01 skrev Maxim Cournoyer <
maxim.courno...@gmail.com>:
[...]

> The OS is Guix System; I'm currently running the 5.15.103 kernel.  I was
> testing on the staging branch, which has 1.14.2.  Assuming you have Guix
> installed on your GNU/Linux system:
>
> --8<---cut here---start->8---
> wget -O guix-install.sh https://guix-install.sh
> chmod +x guix-insall.sh
> yes | sudo ./guix-install.sh
> # Quit, then reopen your session
> guix pull   # update Guix itself
> --8<---cut here---end--->8---
>
> You should be able to reproduce on a x86_64 system with:
>
> --8<---cut here---start->8---
> guix build --no-substitutes --no-grafts --system=i686-linux subversion
> --8<---cut here---end--->8---
>

Now this is slightly off-topic, but since I'l like to see the reproduction
of this error, I spent the better part of the day waiting for the build to
complete, however run into problems with openssl test 80-test_ssl_new.t.
Any ideas how to get past that one?

Kind regards,
Daniel Sahlberg

Re: redirection error with file externals - possible bug

[Daniel Sahlberg]

I've spent some time today looking at the issue. I've been able to
reproduce it, but my reproduction is not in a shape where I can share it.

Basically I've setup a server where the repository was hosted at
http://localhost/repo, configured an external. Then reconfigured the server
so the repository is at http://localhost/r2 with http://localhost/repo
issuing a http level redirect to /r2.

I'm then able to reproduce the issue.

Den sön 12 mars 2023 kl 22:42 skrev Nathan Hartman :

> On Sat, Mar 11, 2023 at 4:29 PM Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com> wrote:
>
>> Den lör 11 mars 2023 kl 13:06 skrev Pál Kovács <81.kovacs...@gmail.com>:
>>
>>>
>>>
>>> Dear All,
>>>
>>> I'd like to setup http traffic to be redirected to https on our svn
>>> server.
>>> Redirection works all right in most of the cases, except when we have a
>>> file-external with http in the url.
>>> For file-externals, svn export works as expected (in the export log it
>>> is visible that there was a redirection and the file is fetched).
>>> However when trying to checkout a working copy, file-externals are not
>>> downloaded, the log shows errors like this:
>>>
>>> Redirecting to URL '
>>> https://myserver/svn/myrepo/TestFolder/Project2/test.txt':
>>> Fetching external item into 'checkout_target\test.txt':
>>> svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed:
>>> EXTERNALS.def_repos_relpath
>>>
>>
This error occurs in subversion/libsvn_wc/wc_db.c line 3365 (as of
r1908925), where ieb->recorded_repos_relpath is null for a file external.
For a folder external, it contains the folder name.

I didn't check where recorded_repos_relpath came from but I think this is
the logical next step.


> I found a similar bug report for folder-externals, which was fixed in SVN
>>> 1.8.5
>>>
>>> https://issues.apache.org/jira/browse/SVN-4428
>>>
>>
I'm running out of time to check r1525902 (as referenced by this issue) but
maybe this problem was fixed for folders and a similar fix can be applied
also for files.

Kind regards,
Daniel Sahlberg

Re: Test suite fails when run in parallel for i686-linux

[Daniel Sahlberg]

Thanks for the tests.log! I've tried to look into it and sending some
comments below!

Den fre 31 mars 2023 kl 23:35 skrev Maxim Cournoyer <
maxim.courno...@gmail.com>:

> Hello,
>
> Nathan Hartman  writes:
>
> > On Thu, Mar 30, 2023 at 11:13 PM Maxim Cournoyer
> >  wrote:
>

[...]

I assume the log is from this build:


> And on an old 4 cores desktop:
>
> --8<---cut here---start->8---
> At least one test FAILED, checking
> /tmp/guix-build-subversion-1.14.2.drv-0/subversion-1.14.2/tests.log
> FAIL:  fs-fs-pack-test: Unknown test failure (-6); see tests.log.
>

fs-fs-pack-test: subversion/libsvn_subr/utf.c:424: put_xlate_handle_node:
Assertion `node->next == NULL' failed.


> FAIL:  fs-test: Unknown test failure (-6); see tests.log.
>

fs-test: subversion/libsvn_subr/utf.c:424: put_xlate_handle_node: Assertion
`node->next == NULL' failed.


> FAIL:  io-test: Unknown test failure (-6); see tests.log.
>

io-test: subversion/libsvn_subr/utf.c:424: put_xlate_handle_node: Assertion
`node->next == NULL' failed.


> FAIL:  op-depth-test: Unknown test failure (-6); see tests.log.
>

op-depth-test: subversion/libsvn_subr/utf.c:424: put_xlate_handle_node:
Assertion `node->next == NULL' failed.

There is some mutex handling in utf.c. I'm thinking if APR is missing the
appropriate mutex handling in some weird way. What is the exact versions of
APR/APR-util in your builld?

FAIL:  repos-test 2: test deletions under copies in node_tree code
>

svn_tests: E02: Repository creation failed
svn_tests: E02: Creating db lock file
svn_tests: E02: Can'FAIL:  repos-test 1: test svn_repos_dir_delta2
svn_tests: E02: Repository creation failed
svn_tests: E02: Creating db logs lock file
svn_tests: E02: Can't open file
'/tmp/guix-build-subversion-1.14.2.drv-0/subversion-1.14.2/subversion/tests/libsvn_repos/test-repo-del-under-copy/locks/db-logs.lock':
No such file or directory
FAIL:  repos-test 2: test deletions under copies in node_tree code


> FAIL:  repos-test 3: test svn_repos_history() (partially)
>

svn_tests: E02: Repository creation failed
svn_tests: E02: Creating lock dir
svn_tests: E02: Can't create directory
'/tmp/guix-build-subversion-1.14.2.drv-0/subversion-1.14.2/subversion/tests/libsvn_repos/test-repo-revisions-changed/locks':
No such file or directory
FAIL:  repos-test 3: test svn_repos_history() (partially)

FAIL:  repos-test 5: test svn_repos_node_locations some more
>

svn_tests: E02: Repository creation failed
svn_tests: E02: Creating pre-commit hook
svn_tests: E02: Can't change perms of file
'/tmp/guix-build-subversion-1.14.2.drv-0/subversion-1.14.2/subversion/tests/libsvn_repos/test-repo-node-locations2/hooks/pre-commit.tmpl':
No such file or directory
FAIL:  repos-test 5: test svn_repos_node_locations some more


> FAIL:  repos-test: Unknown test failure (-11); see tests.log.
>

Since each test operate on its own WC, I can't really figure out why there
would be issues with these tests, unless there is an error in
svn_atomic_inc() (see subversion/tests/svn_test_main.c, test_thread())
causing the same test to be started more than once (by separate threads).


> So the failures appear to be non-deterministic, although some test suite
> such as repos-test fail more often than not.
>

What is the exact OS (distribution/release/kernel version) you are running?

Kind regards,
Daniel Sahlberg

Re: Property svn:ignore reported as inherited by svn proplist

[Daniel Sahlberg]

Den mån 20 mars 2023 kl 21:09 skrev Xsawer xsawer :

> Both are correct in my eyes, just the information, that svn:ingore is
> listed by svn propget/proplist when using parameter --show-inherited-props,
> is missing. I would write something like:
> ...the patterns found in the svn:ignore property apply only to the
> directory on which that property is set, and not to any of its
> subdirectories, however it will still be listed by svn propget/proplist
> commands on subdirectories when using parameter --show-inherited-props.
>

As this is a change to the book, it should probably be discussed on the
svnbook-dev list (see
https://mailman.red-bean.com/mailman/listinfo/svnbook-dev).

I'm not personally convinced since the inheritance (or rather
non-inheritance) is discussed in the section about inheritable properties (
https://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.inheritable),
that section is prior to the section about ignoring unversioned items. But
we can have that discussion on the correct mailing list.

Kind regards,
Daniel

Re: Property svn:ignore reported as inherited by svn proplist

[Daniel Sahlberg]

Den mån 20 mars 2023 kl 20:16 skrev Xsawer xsawer :

> Well, one way or the other, proper documentation would do the job in this
> case.
> At minimum it should be clearly documented that --show-inherited-props
> lists properties which are set on parent folders and not really inherited.
>

+1


>
> -- Původní e-mail ------
> Od: Daniel Sahlberg 
> Komu: Xsawer xsawer 
> Kopie: users@subversion.apache.org
> Datum: 20. 3. 2023 19:44:05
> Předmět: Re: Property svn:ignore reported as inherited by svn proplist
>
> Den mån 20 mars 2023 kl 19:04 skrev Xsawer xsawer :
>
> [...]

>
>
> Documentation here says:
> ...the patterns found in the svn:ignore property apply only to the
> directory on which that property is set, and not to any of its
> subdirectories.
>
> https://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.ignore.html
>
> On the other hand svn proplist --help says:
> --show-inherited-props   : retrieve properties set on parents of the target
>
> Not a word about inheritance.
>
> Can you suggest another wording (for either of these)?

Kind regards,
Daniel

Re: Property svn:ignore reported as inherited by svn proplist

[Daniel Sahlberg]

Den mån 20 mars 2023 kl 19:04 skrev Xsawer xsawer :

> Hi,
> thank you for quick response.
> I would say this is kind of gray zone.
> I don't want svn:ignore to be inherited to all the subfolders. Not at all.
> For what svn:global-ignores would be then?
> I only think when something is inherited then it is automatically applied.
> What else would be the meaning of word "inheritance"?
> In my eyes parameter --show-inherited-props should only list properties
> which are really inherited.
>

I see your point. However it might be difficult to know what properties are
actually "inherited". For the Subversion reserved properties that exist
within the client's version we will know (for a 1.8 client, only
svn:auto-props and svn:global-ignores). But the properties are not limited
to the predefined property names and it will be impossible to know if a
property is intended to be applied to just one folder or if it should be
applied to child items. For example TortoiseSVN defines a couple of
properties in the tsvn:* namespace which are truly inherited (ie applied to
all child items). If I set these using TortoiseSVN, then view the
repository using the command line client, I would like to see them. Then we
have the properties which people will invent themselves and possibly use in
different ways to automate things.


> Documentation here says:
> ...the patterns found in the svn:ignore property apply only to the
> directory on which that property is set, and not to any of its
> subdirectories.
>
> https://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.ignore.html
>
> On the other hand svn proplist --help says:
> --show-inherited-props   : retrieve properties set on parents of the target
>
> Not a word about inheritance.
>

Maybe the --show-inherited-props was a poorly chosen name? Unfortunately I
think it will be very difficult to change it now without breaking things
(and we are not even close to https://xkcd.com/1172/). Adding
--show-truly-inherited-svn-props might be helpful, but it will eventually
show different things depending on the version of the client (as Subversion
learns about new inherited properties in future versions) and it will never
show inherited properties defined by other clients (and end users).

Kind regards,
Daniel

Re: Property svn:ignore reported as inherited by svn proplist

[Daniel Sahlberg]

Den mån 20 mars 2023 kl 17:39 skrev Xsawer xsawer :

> Hi,
> Say I have following folder structure:
> main
>  - config
>
> Folder main has set property svn:ignore to:
> abc
> def
> ghi
>
> Folder config has no properties set. Property svn:ignore is not
> inheritable.
> I am wondering why is property svn:ignore reported as inherited from
> folder main
> when querying e.g. via
> svn proplist config --show-inherited-props
>
> Here is the output:
> svn proplist config --show-inherited-props
> Inherited properties on 'config',
> from '/tmp/main':
>   svn:ignore
>
> Isn't it a bug?
>

Hi,

There is some information in the Subversion book[1], in particular the
(i)-box towards the end of the section. In short: The
--show-inherited-props only figure out what properties are listed for the
parent(s) of the current path, but it doesn't automatically mean that a
property is applied on a subdirectory (as you have already figured out).

Now, we can regard this as a bug or as "works as intended". I can see a
point in svn:ignore being applied also to subdirectories, however this will
mean a change in behaviour between how older and newer versions of the
Subversion client work with a particular repository and I suppose this was
the reason why it was decided not to have all properties apply to
subdirectories.

The svn:global-ignores property [2] should be applied to any
subdirectories, so if you switch to this property you will probably get the
behaviour you are looking for.

Kind regards,
Daniel


[1]
https://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.inheritable
[2]
https://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.ref.versioned

Re: redirection error with file externals - possible bug

[Daniel Sahlberg]

Den lör 11 mars 2023 kl 13:06 skrev Pál Kovács <81.kovacs...@gmail.com>:

>
>
> Dear All,
>
> I'd like to setup http traffic to be redirected to https on our svn server.
> Redirection works all right in most of the cases, except when we have a
> file-external with http in the url.
> For file-externals, svn export works as expected (in the export log it is
> visible that there was a redirection and the file is fetched).
> However when trying to checkout a working copy, file-externals are not
> downloaded, the log shows errors like this:
>
> Redirecting to URL '
> https://myserver/svn/myrepo/TestFolder/Project2/test.txt':
> Fetching external item into 'checkout_target\test.txt':
> svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed:
> EXTERNALS.def_repos_relpath
>
> I found a similar bug report for folder-externals, which was fixed in SVN
> 1.8.5
>
> https://issues.apache.org/jira/browse/SVN-4428
>
>
> Reproduction:
>  - the webserver should be setup to redirect http traffic to https. In my
> case this is in the httpd config:
>
> Listen "80" http
> 
>  UseCanonicalName off
>  SSLEngine off
>  RewriteEngine on
>  RewriteRule ^/(.*) https://%{SERVER_NAME}:443/$1 [R=301,L]
> 
>
>  - use this script to create a file external with http url, then run an
> export (there should be no problem) and a checkout (file external should
> fail with the above error)
>  - assuming you have an empty TestFolder in SVN
>  - create a batch file in an empty local folder and run it:
>
> svn co https://myserver/svn/myrepo/TestFolder
> cd TestFolder
> md Project1
> md Project2
> echo "test file" > .\Project2\test.txt
> svn add --force *
> svn commit -m "commit test structure"
> svn propset svn:externals "
> http://myserver/svn/myrepo/TestFolder/Project2/test.txt test.txt" Project1
> svn commit -m "added http external"
> cd ..
> svn export "http://myserver/svn/myrepo/TestFolder/Project1;
> .\export_target
> svn checkout "http://myserver/svn/myrepo/TestFolder/Project1;
> .\checkout_target
> pause
>
> - you can find the output of my test attached
>
>
> Test environment:
>  - Operating system is Windows 10 Home [10.0.19044]
>  - I have tested with a fresh installation of VisualSVN server (5.1.3)
> with no customisation, except enabling the http-https redirect
>  - VisualSVN came with Subversion 1.14.2 client
>
>
> Could you advise if this is a bug or I'm missing something?
>
> Thanks and kind regards,
>
> Pal Kovacs
> 81.kovacs...@gmail.com
>

There was a very similar report about one month ago (
https://lists.apache.org/thread/x0v1tj68d2mz4vdoxj0bts8h5x892q9n) but it
didn't receive a reply at that time. I've been meaning to take a closer
look but I haven't found the time yet.

Anyway, thanks for your very detailed report, it should make it a lot
easier to reproduce and hopefully fix.

Kind regards,
Daniel

Re: Regarding details of SVN Cleanup command

[Daniel Sahlberg]

Den mån 20 feb. 2023 kl 12:21 skrev Kalkar, Gauri via users <
users@subversion.apache.org>:

> Hi Team,
>
>
>
> Can anyone please help me to understand how “SVN Cleanup” command exactly
> works?
>
>
>
> I want to know what these default checked options exactly do with working
> copy. Refer below image.
>
>
>
>
As Yasuhito FUTATSUKI already mentioned elsewhere in the thread this dialog
is indeed from TortoiseSVN. The best place to ask questions about
TortoiseSVN is the following mailing list:
https://groups.google.com/g/tortoisesvn

I believe the TortoiseSVN manual should answer your questions:
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-cleanup.html

Kind regards,
Daniel


>
> These default checked options are automatically executed when I will
> execute “SVN cleanup” from command line tools?
>
>
>
> Thanks,
>
>
>
> Regards,
>
> Gauri
>
>

Re: New Server can't get my SVN back online

[Daniel Sahlberg]

Den mån 6 feb. 2023 kl 23:00 skrev James Hart :

> K made some progress figured out why I didn’t have command line and got
> them installed
>
>
>
> Did this
>
>
>
> C:\Users\jhart>svnadmin create d:/P-Drive/SVN/DCI-Repo
>
> svnadmin: E165002: 'D:\P-Drive\SVN\DCI-Repo' is an existing repository
>
>
>
> Next step ?
>

Well, I guess that means you've figured out the path to your repository.
You should check if you have more repos in the same directory.

Now continue with the steps in the SVN book to create a service for
svnserve serving that repository (
https://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.invoking.winservice
).

Please note that in Subversion "repository" is the central database (on the
server) where you have all your versioning data. The folder where you do
your actual work is a "working copy" and it only contains the current
revision of each file. This is a characteristic of a "centralized version
control software" compared to a "distributed version control software" (for
example git).

The "relocate" (as referenced in the other mail) is used when you have
moved the repository (ie, changed the URL, for example server name) and you
need to point your working copy to a new URL. This may or may not be
required in your case depending on if the new server has inherited the ip
address and/or the server name of the old server.

Kind regards,
Daniel

Re: New Server can't get my SVN back online

[Daniel Sahlberg]

Den fre 27 jan. 2023 kl 20:51 skrev James Hart :

> Current Server is Windows Server 2019 Essentials
>
>
>
> Old Server that ran SVN for years was Windows Server 2012… still have old
> machine it was running on vmware
>
> It has been so long since I tried to get it going I can’t exactly remember
> what I did.
>
>
>
> I used just plain subversion
>
>
>
> https://”Server address”:3690/svn
> 
>
>
>
> Says please wait while repository browser is initializing… never comes back
>

Your URL is a bit ambiguous; it says "https" while at the same time using
the port 3690. The port number indicates that you want to use the svn://
protocol - but it is of course possible to configure a http server on port
3690, although a bit unusual.

If you would like to use the svn:// protocol, you must configure svnserve
to listen to that port. Check the svn book:
https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.invoking.winservice

(You must also configure the Windows Firewall to allow svnserver/port 3690
through the firewall).

If you want to use the https:// protocol, you must setup a web server to
listen to port 3690.

Kind regards,
Daniel

Re: Is it possible to export multiple files in one command?

[Daniel Sahlberg]

Den lör 21 jan. 2023 kl 10:31 skrev Bo Berglund :

> I have a script, which is used in our installer creation process and it
> works as
> follows (on Windows):
>
> - Create a new target directory
> - Run svn commands to get the needed files into that dir
> - Run svn command to download the installer engine binary into its own dir
> - Run svn command to download the installer script itself
> - Start the installer engine with the script as argument
>
> This produces a new installation file in the installers directory.
>
> The svn command I am using is svn export since I don't want to create a
> versioned container and I also want to collect files from various different
> locations including documentation which will be part of the installer.
>
> What I would like to know is if there is an svn export command switch of
> some
> kind that can be used to export a set of files in one go if they reside in
> the
> same subversion directory?
>
> Right now I am repeating the following typical sequence, where the svn
> commands
> have to be run *inside* the target directory (variable SVNREPO has been
> set to
> the repository URL earlier):
>
> if EXIST Manager rmdir /s /q Manager
> mkdir Manager
> cd Manager
> svn export %SVNREPO%/Manager.exe .\
> if errorlevel 1 goto error
> svn export %SVNREPO%/ssleay32.dll .\
> if errorlevel 1 goto error
> svn export %SVNREPO%/libeay32.dll .\
> if errorlevel 1 goto error
> svn export %SVNREPO%/doc/Manager_instructions.pdf .\
>
> So to get these 4 files I have to issue 4 different svn commands...
>
> And I have had to create the target dir and move into it before doing this
> because otherwise the command instead of creating a subdir to stuff the
> file
> into exports the source file into a file named as the directory it is
> supposed
> to go into...
>
> Example:
> svn --force export %SVNREPO%/ssleay32.dll TargetDir
>
> This creates a *file* TargetDir with the content of ssleay32.dll instead of
> ssleay32.dll inside of TargetDir
>
> I would like to use a single svn command per source dir and get all the
> needed
> files from there at the same time according to a supplied list.
>
> Is this possible at all?


I believe you can do this using the svn:externals property. I have the
following repository layout
[root]
+-- manyfiles
| +--- 1file
| +--- 2file
| +--- 3file
| +--- 4file
| +--- 5file
+--- somefiles

The manyfiles directory contains 5 different files. The somefiles directory
contains none, however it has the svn:externals property set to point to
each of the files needed for the installation script (1file, 3file, 5file):
$ svn proplist -v somefiles
Properties on 'somefiles':
  svn:externals
^/manyfiles/1file 1file
^/manyfiles/3file 3file
^/manyfiles/5file 5file

I can now do
$ svn export REPOPATH/somefiles

This will give me a directory tree containing the requested files:
+--- somefiles
  +--- 1file
  +--- 3file
  +--- 5file

Obviously, you can get creative in your external definitions, for example
pegging to a specific revision. See the SVN Book for the full syntax:
https://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html

Of course this means that you now have two places to maintain your build
scripts; both the actual script do to the build process and the
svn:externals property. You must decide if the additional burden of
splitting out the file list to SVN is worth the effort. (You could
potentially have the directory "somefiles" in the repository without the
svn:externals property, check it out as a working copy, set the
svn:externals property as part of the script and do an svn up to get all
the files).

Kind regards,
Daniel Sahlberg

Re: New Server can't get my SVN back alive

[Daniel Sahlberg]

Den tors 19 jan. 2023 18:23James Hart  skrev:

> I have done something wrong in my import and it is killing me not having
> the SVN feature after using it for years. Is there anyone I could get help
> from remotely to resolvehi
>
>
> Hi
I think you will get good help here by describing what servers you have
(os/versions, if you use plain Subversion or any of the paid offerings),
the repository access methods (http/https, svnserve, local), what you have
done so far, what error messages you get etc.
Kind regards
Daniel Sahlberg

>
>

Re: filename encodings and conversion failure

[Daniel Sahlberg]

Den tors 22 dec. 2022 kl 23:40 skrev Karl Berry :

> Clearly those UTF-8 code points cannot be "converted" by svn to the
> 7-bit ASCII locale that is "C". Fine; I don't expect it to.  Is there a
> way to force svn to complete the checkout anyway? That is, just check
> out the file and let the name be whatever the bytes are. I don't
> understand why any "conversion" by svn is necessary merely to operate on
> files.
>

Not at all related to this issue except it also concerns filenames: It is
possible to commit files with a filename that works on only one platform,
making a checkout/update fail on other platforms.

Example: Commit a file with ? (questionmark) in the filename on Linux and
checkout the file on Windows.

[[[
D:\temp>svn co https://svn.apache.org/repos/private/pmc/subversion/pr/
private_wc
[...]
svn: E155009: Failed to run the WC DB work queue associated with
'D:\temp\private_wc\YYY_folder', work item 54 (file-install XY?Z.html 1 0 1
1)
svn: E720123: Can't move 'D:\temp\private_wc\.svn\tmp\svn-C3A15B21' to
'D:\temp\private_wc\XY?Z.html': The filename, directory name, or volume
label syntax is incorrect.
]]]

(The above example is from the Subversion private repository, I've masked
the actual folders/filenames but it should be reproducible for anyone with
access to the repository).

This is a case where a conversion might /be/ necessary (although I don't
have a concrete idea of what the conversion should be). Or else these files
should just be ignored on checkout.

I'm just mentioning this in case someone looks at the code and decides make
changes to the conversions.

Kind regards,
Daniel

Re: line 1634: assertion failed (! svn_path_is_url(relative))

[Daniel Sahlberg]

Den tors 15 dec. 2022 kl 13:36 skrev Olivier Bodarwé <
olivier.boda...@labsolution.lu>:

> ---
>
> Subversion Exception!
>
> ---
>
> Subversion encountered a serious problem.
>
> Please take the time to report this on the Subversion mailing list
>
> with as much information as possible about what
>
> you were trying to do.
>
> But please first search the mailing list archives for the error message
>
> to avoid reporting the same problem repeatedly.
>
> You can find the mailing list archives at
>
> https://subversion.apache.org/mailing-lists.html
>
>
>
> Subversion reported the following
>
> (you can copy the content of this dialog
>
> to the clipboard using Ctrl-C):
>
>
>
> In file
>
>
> 'D:\Development\SVN\Releases\TortoiseSVN-1.14.1\ext\subversion\subversion\libsvn_subr\dirent_uri.c'
>
> line 1634: assertion failed (! svn_path_is_url(relative))
>
> ---
>
> OK
>
>
What happens is probably that TortoiseSVN is calling the Subversion
libraries with an incorrect URL/path to either the working copy or the
repository. I've seen this happening from time to time in TortoiseSVN.

I had this error 2 times now.
> The first time when I tried to merge.
>
> The second time when I was trying to revert a change from a revision.
>
> After a CleanUp I could continue my work.
>

Can you reproduce the problem, ie, create it consistently? If so, can you
explain the steps? In particular, where you start the process (from Windows
Explorer in the working copy, from Repository Browser, from Project monitor
etc.). In that case there is a much higher chance we can figure out what is
going on.

Can you retry the same actions using the command line client? (These can be
installed from the TortoiseSVN installer, if you don't know the command
line client, we can probably help you with the equivalent command).


> I’m working on Window 10 with Tortoise SVN version
>
>
>
> TortoiseSVN 1.14.1, Build 29085 - 64 Bit , 2021/02/09 16:17:02
>

I notice that you are using an older version of TortoiseSVN. Is there any
chance you can upgrade to the latest release (1.14.5 at the time of
writing)? If you can reproduce it - does it also reproduce the same in the
latest release?

If this is only an issue with TortoiseSVN and not in the command line
client, you should probably report it to the TortoiseSVN user group (
https://groups.google.com/g/tortoisesvn) - I know this is contrary to the
error message you received but it has to be fixed in TortoiseSVN. There are
a couple of people active in both groups (I'm one of them).

Kind regards,
Daniel

Re: Subversion assertion upon commit

[Daniel Sahlberg]

Den tors 15 dec. 2022 kl 06:04 skrev Nathan Hartman <
hartman.nat...@gmail.com>:

> On Wed, Dec 14, 2022 at 2:24 PM Don Newbold (GSC)
>  wrote:
> > To be clear, I have never seen any SVN related ASSERTION on any other
> > occasion.
> >
> > The file in question is named "release.txt" and contains release notes
> > for a driver. I've got over 50 different such files and collectively
> > have made perhaps 500 different commits of these files. I see the commit
> > failure on the file's parent documentation subdirectory often enough
> > that I typically go to dos2unit on this file without checking to see
> > what the complaint is.
> >
> > The property are ...
> >
> > EOL: native
> > MIME: test/plain
> > Keywords: author, date, ID, revision, URL
> > needs lock: *
> > No other properties are set.
> >
> > The file is virtually always edited under Windows using Visual Studio
> > 2005. This inserts Windows style line endings. However, the file is used
> > under Linux and is run through dos2unix as part of the release
> > procedure. To clarify, the file is maintained with UNIX style line
> > endings, but gets Windows style line endings for newly added lines. The
> > SVN properties are set automatically based on it being a .txt file.
> > Every release includes one or more other .txt files, with identical SVN
> > properties. I'm sure I see this commit failure periodically with other
> > .txt files, but they aren't changed enough for me to have developed an
> > automatic response when a commit fails.
>

[...]

Meanwhile, a request: If you (or anyone) sees this again, please save a
> copy of the file that exposes it and then talk to us so that with your
> help we could figure out what is the offending sequence and how to
> reproduce it for debugging and regression testing...


The mentioning of Windows and Linux above makes me wonder if you are using
the same working copy from both Windows and Linux (WSL/Cygwin)
environments. It was discussed on the TortoiseSVN mailing list a while ago
[1] but I don't think anyone actually encountered an assertion and I'm not
able to reproduce it either. (All my experiments ended with "E135000:
Inconsistent line ending style"). The conclusion was to maintain separate
working copies for the different environments.

If you use svn:eol-style native you should be able to checkout the file
under Linux (including WSL/Cygwin) and automatically have \n line endings
without any need for conversion. When you checkout the file under Windows
(using TSVN or the svn command line tools) you will get \r\n line endings.

Kind regards,
Daniel

[1] https://groups.google.com/g/tortoisesvn/c/6g9nucDEtlA/m/no_3CEvbAAAJ

Re: [UK OFFICIAL] TortoiseSVN (64-bit) - v1.8.0.24401 - Windows Server 2019

[Daniel Sahlberg]

Den tis 13 dec. 2022 kl 12:05 skrev Byles Bernard via users <
users@subversion.apache.org>:

> Classification: UK OFFICIAL
>
>
> Hi Pavel,
>
> Thanks for the prompt response. I'll just add some further details.
>
> The customer has a Windows 2008 R2 server. On this server they have
> TortoiseSVN client installed with a specific drive dedicated for their
> repository which I believe can only be accessed from the server itself
> rather than over the network (I'm not 100% sure as unfortunately no one
> really knows much about this app).
>
> If possible, we need to migrate this application to a brand new Windows
> 2019 Server which you have confirmed won't support their existing version
> of TortoiseSVN therefore a brand new client install is required.
>
> Therefore in terms of migration i.e. the data repository. How can this be
> moved from one server to another ? Assume you treat it like a file
> migration or is there specific steps for this.
>

You can treat this as a basic file migration - you must obviously make sure
no-one accesses the files after you initiate the migration.

In case you have new drive names/paths on the new server, the users may
have to "relocate" their working copies (relocate = connect the working
copy to the new location of the repository). This is done using the "svn
relocate" command or in the context menu of Windows Explorer (in the
working copy folder), TortoiseSVN, Relocate.

Kind regards,
Daniel Sahlberg

Re: Backup and Restore of SVN Server

[Daniel Sahlberg]

Den ons 7 dec. 2022 kl 12:06 skrev Felix Natter :

> Dear SVN community,
>
> I have a few questions regarding backup and restore of a SVN Server:
>
> 1. I would like to create daily backups to a cloud service using duplicity
>  (basically full/incremental tars). Now I can do this (a) with a simple
> filesystem
>  backup or (b) create dumps using svnadmin dump and backup them using
>  duplicity.
>
This is discussed in the SVN Book, see [1].

>   -> (a) is not safe in case someone does a commit during the backup?
>
I think it was mentioned somewhere on the list that you *could* do this if
you are very careful with the order you copy the files, basically coping
metadata first then actual contents. But it seems risky and prone to errors
in case future Subversion versions changes things in the repository layout.

Look at svnadmin freeze which was added in Subversion 1.8.0, see the SVN
book[2]. This is explicitly intended to "[A]llow[s] safe use of third-party
backup tools on a live repository." (copied from the output of svnadmin
help freeze).

>   -> (b) would take much more time (we have many, sometimes big, repos),
>   so it might not finish over night?
>
>   -> which one is better? Or is there a (c)?
>
If you are not able to lock the repository (as in (a)) for the time the
backups take), you could use svnsync to copy the repository to a remote
server and take the backups from there. See the SVN book[3] and pay
attention to the copy-revprops command and to backup any hook scripts
manually.

Or you can use svnadmin hotcopy (with --incremental?) if you have space to
spare at the Subversion server, see [4].

> 2. I think I shall use --force-uuid when replaying the dumps (in case of
> (b))
> so that colleagues can just "svn relocate" and continue working?
>
> 3. Are there limitations on what "svn relocate" can handle? Do I need to
> test
> some corner cases? (Both servers are using svn+ssh:// but with totally
>different paths and different auth)
>
> 4. Are there best practices / blogs for migrating svn repos to another
> server?
>
Kind regards,
Daniel


[1]
https://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.backup

[2] https://svnbook.red-bean.com/nightly/en/svn.ref.svnadmin.c.freeze.html
(I have to look to the svn book nightly, since the last published book only
covers 1.7.)
[3]
https://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.replication
[4] https://svnbook.red-bean.com/nightly/en/svn.ref.svnadmin.c.hotcopy.html

Re: svnsync on SVNParentPath

[Daniel Sahlberg]

Den mån 21 nov. 2022 kl 12:02 skrev Andreas Stieger :

> Hi,
>
> > Is it possible to setup svnsync from an SVNParentPath?
> > I'd like to avoid reconfiguring the mirror every time a new repository
> is created.
>
> No, needs some mild scripting, also to put in place the hooks for each
> repo.
>

Thanks for confirmation! I'll figure out a way to script this.

Kind regards,
Daniel

svnsync on SVNParentPath

[Daniel Sahlberg]

Hi,

Is it possible to setup svnsync from an SVNParentPath? I'd like to avoid
reconfiguring the mirror every time a new repository is created.

I checked the SVN book and I couldn't find any references.

Kind regards,
Daniel

Re: SVN tool to get the Line of code

[Daniel Sahlberg]

Den tis 15 nov. 2022 kl 20:45 skrev JITHIN K :

> Hello Team,
>
> We are using Subversion for the source code management  ( Software
> development ).
> Are there any SVN tools available to calculate the line of code
>
>
I can't really understand what you are looking for, it seems the question
was cut short in the middle.

Kind regards,
Daniel

Re: svnsync: E120106: ra_serf: The server sent a truncated HTTP response body.

[Daniel Sahlberg]

Den mån 14 nov. 2022 kl 13:31 skrev JITHIN K :

> Hello Team,
>
> I use Subversion 1.13 in Ubuntu 20.04.5 LTS and sync a repository size of
> 300GB to a mirror server ( same version of SVN and OS ).
>
> I get the following warning svnsync: E120106: ra_serf: The server sent a
> truncated HTTP response body every time ( I had to take a dump of
> specific revisions and load it in the mirror server ).  Did anyone face
> this problem while in sync? Is there any solution?
>

Do you see any common pattern with the revisions causing trouble? Possibly
if they are very large or contain a lot of files.

This was mentioned once before on the list [1]. I don't see if the user
found a way around it, but he mentions that the troublesome revisions were
large imports.

Kind regards,
Daniel

[1] https://lists.apache.org/thread/cmc872c221o0r5mvhk16lcjfnd4xwtl1


>

Re: Unable to pull full commit history; Malformed XML not well-formed (invalid token)

[Daniel Sahlberg]

Den tors 29 sep. 2022 kl 14:15 skrev Carl Henrik Bernhoft :

> Using SVN version:
> svn, version 1.14.1 (r1886195)
>   compiled May 21 2022, 10:52:35 on x86_64-pc-linux-gnu.
>
> I tried pulling the commit log from
> https://github.com/haskell/random/branches/master but the process snags
> on
> https://github.com/haskell/random/commit/a44b801ab0033970660396a42462c4f7b4df56bb
>  which
> corresponds to revision 897.
>
> The error is reproducible from the command line with
> svn log --xml -r897 https://github.com/haskell/random/branches/master
>
> The output is
> svn: E175009: The XML response contains invalid XML
> svn: E130003: Malformed XML: not well-formed (invalid token) at line 8
>
>
The error reproduces without the --xml argument as well:

C:\Users\dsg>svn log -r897 https://github.com/haskell/random/branches/master
svn: E175009: The XML response contains invalid XML
svn: E130003: Malformed XML: not well-formed (invalid token) at line 8

I suppose the "XML" mentioned in the error message is because the http /
webdav protocol is XML based. XML is quite picky about encoding certain
characters.

I was expecting control characters to be stripped, fuzzified or otherwise
> handled. The offending line in the commit, when printed with 'git log'
> displays as: 'Merged Martin SjA?gren's patch for multiline descriptionsb'
> which looks like reasonable output by comparison.
>
> I'm saw that handling unicode and control characters was a topic of
> discussion years ago but this case looks like a bug to me. It doesn't seem
> reasonable for the process to crash when pulling a remote commit log of a
> repo I don't own/control.
>

I'm guessing - but didn't verify yet since I couldn't figure out a way to
quickly sniff the network traffic - that Github's servers are not encoding
the character properly when they send it to the client. My google-fu wasn't
enough to find if the error has been discussed on the GitHub side.

Kind regards,
Daniel

Re: --revision option is not forwarded to svn:externals references

[Daniel Sahlberg]

Den ons 28 sep. 2022 kl 11:52 skrev Harald Oehlmann <
harald.oehlm...@elmicron.de>:

> Am 28.09.2022 um 11:43 schrieb Daniel Sahlberg:
> > Den ons 28 sep. 2022 kl 10:29 skrev Harald Oehlmann
> > mailto:harald.oehlm...@elmicron.de>>:
> >
> > ( I have chosen the same title as SVN-2516, as it addresses the same
> > issue )
> >
> > Thank you for great subversion. I am a happy user with TortoiseSVN on
> > Windows with a Linux server since 20 years.
> >
> > I was hit by a quality department request to restore a revision, I
> have
> > tagged before. Unfortunately, this does not work, if there are
> > externals
> > on externals.
> >
> > I have only one repository and the externals all go to the same
> > repository.
> >
> > There are hints on stack overflow to run over the files and search
> for
> > any ".svn" folder and call "svn up -r 123" if they are found.
> > That is great. Unfortunately, I use a lot of externals only to one
> file
> > (typically image files for buttons).
> >
> > I find it really sad, that there is no command:
> >
> > "svn up -r 123 -propage-externals", which will checkout also the
> > externals, as if "-r 123" would be set for the externals.
> > For me, this is the main point missing in SVN and a blocker for any
> > use,
> > as a tagged version may never be restored and the quality department
> > will say to you: you are not able to reproduce the source code.
> >
> >
> > I assume your externals property doesn't specify a PEG revision (see the
> > SVN book [1]). If you did, then the external would update to that
> > particular peg revision, otherwise the peg revision defaults to HEAD.
> >
> > In /trunk it is probably tempting to have the externals tracking HEAD.
> > But when you tag a release it should be part of your process to freeze
> > all externals to a certain point in time (either to switch them to a
> > specific tag or pegging them to a revision). That way you can easily go
> > back in time to and restore the complete working copy. The TortoiseSVN
> > repository [2] is using this for all release tags, they are updating all
> > externals to the desired tag in the external repository.
> >
> > As for your use case, I can see a point in having the externals
> > definition default to the same revision as the rest of the working copy
> > (since they are in the same repository and share the same revision
> > number sequence). But I feel the same way as C. Michael Pilato in his
> > first comment: "The disparity between behaviors for externals that
> > happen to point to the same repository and those that point to a
> > different repository bothers me.". It will for sure make things more
> > difficult to explain if externals pointing to another repository default
> > to HEAD while intra-repository externals point to "same revision" (that
> > would be BASE, I think).
> >
> > Kind regards,
> > Daniel
> >
> >
> > [1] https://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html
> > <https://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html>
> > [2] https://osdn.net/projects/tortoisesvn/scm/svn/
> > <https://osdn.net/projects/tortoisesvn/scm/svn/>
> >
>
> Dear Daniel,
>
> thank you for the answer.
> No, there are no PEG-revisions in the externals. I don't want them. I
> have two use-cases, where SVN is apparently not the solution:
>
> R1) always have the head in externals (normal developping mode)
> R2) be able to check-out an exact version, as it was checked out with a
> distinct version later on (mode to get again, what was true before for
> quality/archiving/documentation purposes.
>
> The advice "use a versioned external" does not help, as this contradicts
> R1). Tagging a version works for externals, but not for externals on
> externals.
>

Well, both use cases are possible, just not at the same time.


> For me, it is hard to understand that this is wanted like that. For me,
> a revision system should have the capability to checkpoint. But it has
> not. I can understand, that multiple repositories is another story. But
> the power of SVN is, to have one exact revision number which gives
> everything. And it is sad, that this great tool is not usable for
> externals.
>

For me, the argument by Mike (as quoted already) that Subversion should
behave identically whether or not the external is an internal or external
repository has higher priority. But I would not stand in the way of
consensus if others believe your suggestion is sound.

Considering the low number of developers working on this, any help is
appreciated. I'm sure if you would like to contribute the code to change
Subversion's behaviour you would get the necessary support on the dev@ list
to have this committed.

Kind regards,
Daniel

Re: --revision option is not forwarded to svn:externals references

[Daniel Sahlberg]

Den ons 28 sep. 2022 kl 10:29 skrev Harald Oehlmann <
harald.oehlm...@elmicron.de>:

> ( I have chosen the same title as SVN-2516, as it addresses the same issue
> )
>
> Thank you for great subversion. I am a happy user with TortoiseSVN on
> Windows with a Linux server since 20 years.
>
> I was hit by a quality department request to restore a revision, I have
> tagged before. Unfortunately, this does not work, if there are externals
> on externals.
>
> I have only one repository and the externals all go to the same repository.
>
> There are hints on stack overflow to run over the files and search for
> any ".svn" folder and call "svn up -r 123" if they are found.
> That is great. Unfortunately, I use a lot of externals only to one file
> (typically image files for buttons).
>
> I find it really sad, that there is no command:
>
> "svn up -r 123 -propage-externals", which will checkout also the
> externals, as if "-r 123" would be set for the externals.
> For me, this is the main point missing in SVN and a blocker for any use,
> as a tagged version may never be restored and the quality department
> will say to you: you are not able to reproduce the source code.
>

I assume your externals property doesn't specify a PEG revision (see the
SVN book [1]). If you did, then the external would update to that
particular peg revision, otherwise the peg revision defaults to HEAD.

In /trunk it is probably tempting to have the externals tracking HEAD. But
when you tag a release it should be part of your process to freeze all
externals to a certain point in time (either to switch them to a specific
tag or pegging them to a revision). That way you can easily go back in time
to and restore the complete working copy. The TortoiseSVN repository [2] is
using this for all release tags, they are updating all externals to the
desired tag in the external repository.

As for your use case, I can see a point in having the externals definition
default to the same revision as the rest of the working copy (since they
are in the same repository and share the same revision number sequence).
But I feel the same way as C. Michael Pilato in his first comment: "The
disparity between behaviors for externals that happen to point to the
same repository and those that point to a different repository bothers
me.". It will for sure make things more difficult to explain if externals
pointing to another repository default to HEAD while intra-repository
externals point to "same revision" (that would be BASE, I think).

Kind regards,
Daniel


[1] https://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html
[2] https://osdn.net/projects/tortoisesvn/scm/svn/

Re: How much is too much data in an svn repository?

[Daniel Sahlberg]

Hi,

In addition to all other responses, I'd like to advertise the "pristines on
demand" feature that got some traction in the spring.

Subversion is normally storing all files twice on the client side (in the
"working copy": once for the actual file and once as a "pristine", ie as
the file was when checking out, in the .svn folder). The idea with
"prisines on demand" is to store the file only once, on the expense of some
operations requiring more bandwidth. I'm not sure about the status, but it
is not part of any current release yet. Karl Fogel and Julian Foad was
involved in this, more details can be found in the list archives on the
d...@subversion.apache.org list.

Kind regards,
Daniel



Den tors 22 sep. 2022 kl 21:59 skrev Sean McBride :

> Hi all,
>
> Our svn repo is about 110 GB for a full checkout. Larger on the server of
> course, with all history, weighting about 142 GB.
>
> There haven't been any performance issues, it's working great.
>
> But now some users are interested in committing an additional 200 GB of
> mostly large binary files.
>
> I worry about it becoming "too big".  At what point does that happen?
> Terabytes?  Petabytes?  100s of GB?
>
> Thanks,
>
> Sean
>

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

[Daniel Sahlberg]

I'm following up on an old e-mail [1] on how to use IIS as a reverse proxy
in front of Apache Subversion.

Previously I found found a way to use the URL Rewrite module to forward
requests to mod_dav_svn. This was working fine until I tried to access a
file with a "+" encoded in the filename.

[[[
$ svn log "https://svn.example.com/svn/repo/file with + in filename.txt"

svn: E170013: Unable to connect to a repository at URL '
https://svn.example.com/svn/repo/file%20with%20+%20in%20filename.txt'

svn: E160013: '/svn/repo/file%20with%20+%20in%20filename.txt' path not found

$
]]]

It turns out that IIS will not accept requests with "+" and will reply with
http error 404.11 instead of rewriting the request and forwarding to
mod_dav_svn.

A similar problem is described here [2] and IIS can be configured to
"allowDoubleEscaping" [3]. With this configuration changed everything
worked as expected.

The solution was found by supp...@visualsvn.com (we use their software
stack on the server).

The relevant parts of web.config can be found below.

Kind regards,
Daniel Sahlberg


[1] https://lists.apache.org/thread/bcx15smyth43v1t1vvhqnc8bhxt5b5kd
[2] https://github.com/go-gitea/gitea/issues/10236
[3]
https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/#attributes

[[[









https://{HTTP_HOST}{REQUEST_URI};
/>







http://{C:1}; />

http://127.0.0.1:81/{R:0};
logRewrittenUrl="true" />




http://127.0.0.1:81/{R:0};
logRewrittenUrl="true" />







]]]

Re: SVN pre- commit hook failed

[Daniel Sahlberg]

Den tis 20 sep. 2022 kl 21:42 skrev Balaji, Yuvaraj via users <
users@subversion.apache.org>:

>
>
> Hi,
>
> I was not able to commit the changes in one of my repository after
> merging.
>
> Kindly let me know how can make it work.
>
> It will take more time for Merging if I need to redo it again.
>
> Kindly let me know if you can help me on this.
>
>
>
> Please check the below screen shot.
>
>
>
>
This indicates a crash on the server side. apr_exit_why_e is an enum [see
1] where 2 seems to be "APR_PROC_SIGNAL", I guess this means something
killed the pre_commit process.

Can you check the logs and dump files on the server?

There is one previous mention of this in the archives:
https://svn.haxx.se/users/archive-2016-07/0045.shtml, however the user
never came back with a solution.

Kind regards,
Daniel


[1] https://apr.apache.org/docs/apr-util/trunk/group__apr__thread__proc.html

Re: svn client - how do I force IPv6?

[Daniel Sahlberg]

Den mån 19 sep. 2022 kl 14:49 skrev Graham Leggett :

> On 19 Sep 2022, at 13:36, Mark Phippard  wrote:
>
> Daniel gave the answer I was typing. Here is info on enabling IPv6 for
> your JVM:
>
> https://stackoverflow.com/questions/18697091/ipv6-support-in-java
>
>
> Alas this is the info for the JVM and does not work in this case. Most
> Java communication libraries ignore the JVM parameters for their own
> implementations. This is true of SVNKit, which reports that it relies
> completely on the configuration of the native svn client.
>
> https://svnkit.com/documentation.html
>
> "Native Subversion configuration files are used by default.”
>

Well, it says "used by default" which is not the same as "completely". As
SVNKit doesn't share any code with Apache Subversion, any configuration
that we add in Apache Subversion has to be implemented in SVNKit as well.

There is already a FAQ entry on the SVNKit wiki regarding connection
problems where there were differences between a "native client"
(TortoiseSVN, which IS using Apache Subversion code) and SVNKit, tldr: due
to how certain JVMs handle address lookup.

https://wiki.svnkit.com/SVNKit_FAQ#Q:_Problem_on_Windows_Vista.2C_connecting_a_repository_through_the_svn_protocol:_org.tmatesoft.svn.core.SVNException:_svn:_connection_refused_by_the_server

Google site search unfortunately didn't turn up any other useful results at
svnkit.com. I'm sorry not to be of any more help but I believe your best
bet is to wait for a reply in the forum thread you linked to elsewhere.

Kind regards,
Daniel

Re: svn client - how do I force IPv6?

[Daniel Sahlberg]

Den mån 19 sep. 2022 kl 11:50 skrev Graham Leggett via users <
users@subversion.apache.org>:

> Hi all,
>
> What setting option under the ~/.subversion directory will force the use
> of IPv6 on outbound connections?
>
> The backstory is that I have some SVNKit code that is stubbornly insisting
> on using IPv4 and failing. The SVNKit docs say it gets its config from the
> native ~/.subversion directory, but I can find no mention of IPv6 and the
> native svn client config. I am specifically talking about an svn client
> accessing an IPv6 server over https, I am not using svnserve.
>

Hi,

SVNKit is a Java implementation of Subversion and doesn't share any code
with Apache Subversion. Even if SVNKit honors the configuration in
~/.subversion, there are no guarantees that a particular option used by
Apache Subversion works the same way with SVNKit. Thus I would suggest that
you ask the same question in the SVNKit forums.

I can't recollect seeing any options for IPv6 (as you have also found out).
I would assume Apache Subversion is using OS defaults when it comes to
trying IPv4 or IPv6 first if a certain server has both addresses. When it
comes to SVNKit I can't guess how Java handles IPv4 och IPv6 connections.

Kind regards,
Daniel

Re: Problem about svnadmin load

[Daniel Sahlberg]

Den fre 9 sep. 2022 kl 19:53 skrev 李斌 :

> Thank you for replying.
>
> Yeah, when I used svnadmin load I got an error about  “* dump version” so
> I used grep -v.  As you have said. I will try it again. But due to the
> project “UEProject” used 900G hard disk space, so maybe it is hard to
> compare two files different.
>

So if you get a further error message when loading the unmodified dump
file, please come back and we will look at it again.

svn, version 1.8.10 (r1615264)
>>
>
Any chance you can try with a newer version? 1.8.10 has been out of support
for a really long time.

Kind regards,
Daniel


> can you tell me how to resolve it?
>>
>
> Wild guess: You had the string "* Dumped revision" somewhere in the
> contents or properties and your grep filtered this out of the file so the
> file doesn't match the expected dump file format. If you compare the
> UEProject.svn and UEProject-clear.svn files you will probably find some
> missing data.
>
> Kind regards,
> Daniel
>
>

Re: Problem about svnadmin load

[Daniel Sahlberg]

Den fre 9 sep. 2022 kl 12:14 skrev 李斌 :

> Hi
>
> There is a problem when load file via *'svnadmin load'*.
>
> Command: *'nohup svnadmin load /data/UEProject <
> /data/UEProject-clear.svn > ./nohup.log 2>&1 &'*.
>
> UEProject-clear.svn is a dump file generated by *'nohup svnadmin dump
> /root/SVN/UEProject > /data/UEProject.svn &' && ** 'nohup grep
> --binary-files=text -v '^* Dumped revision' ./UEProject.svn >
> ./UEProject-clear.svn &**'.*
>
Why grep -v?


> But when the file be loaded, I get the following error log from nohup.log.
>
>  * adding path :
> UnrealEngine/4.26.2/Templates/TemplateResources/Standard/VehicleAdv/FeaturePack/manifest.json
> ... done.
>
>  * adding path :
> UnrealEngine/4.26.2/Templates/TemplateResources/Standard/VehicleAdv/Media
> ... done.
>
>  * adding path :
> UnrealEngine/4.26.2/Templates/TemplateResources/Standard/VehicleAdv/Media/VehicleAdv.png
> ... done.
>
>  * adding path :
> UnrealEngine/4.26.2/Templates/TemplateResources/Standard/VehicleAdv/Media/VehicleAdv_Preview.png
> ... done.
>
>  * adding path : UnrealEngine/4.26.2/UE4.sln ... done.
>
>  * adding path : UnrealEngine/4.26.2/UE4Games.uprojectdirs ... done.
>
>  * adding path : UnrealEngine/4.26.2/cpp.hint ... done.
>
> svnadmin: E140001: Unrecognized record type in stream
>
> svn, version 1.8.10 (r1615264)
>
> can you tell me how to resolve it?
>

Wild guess: You had the string "* Dumped revision" somewhere in the
contents or properties and your grep filtered this out of the file so the
file doesn't match the expected dump file format. If you compare the
UEProject.svn and UEProject-clear.svn files you will probably find some
missing data.

Kind regards,
Daniel