Re: GUI interface to Subversion via web browser?

[Nathan Hartman]

On Fri, May 24, 2024 at 10:03 AM Johan Corveleyn  wrote:
>
> On Fri, May 24, 2024 at 3:18 PM Mark Phippard  wrote:
> > On Fri, May 24, 2024 at 9:11 AM Johan Corveleyn  wrote:
>
> > > What lots of people these days are looking for (myself included) is a
> > > modern "Code Forge" ...
> >
> > Beanstalk has always seemed like a solid service:  https://beanstalkapp.com/
> > And Assembla still exists: https://get.assembla.com/
> >
> >
> > > Seriously, if we'd ever start such a sub-project under the Apache
> > > Subversion umbrella one day, I'd be interested in joining the effort
> > > :-).
> >
> > The Apache project for this is Allura: https://allura.apache.org/
>
> Thanks for these suggestions Mark. Interesting to look around a bit.
>
> Concerning Allura: I find it quite strange that this project is
> completely disconnected from the Subversion project, being both Apache
> projects. We don't know each other at all. This is the first time the
> name "Allura" is mentioned on users@s.a.o ever since I was subscribed
> (since 2010). On dev@s.a.o it was mentioned only once in 2013, during
> a discussion on where to move the issue tracker. Sounds like marketing
> / making contact with potentially interested communities was not high
> on the agenda.
>
> --
> Johan


Well now, this is interesting. Just a quick glance into the Allura
site and at [1] under "Code Repository" it says Allura supports Git,
Mercurial, and Subversion. The feature comparison page at [2] may be
interesting, as it helps discover some other similar and open source
products.

I sent a "hello" message to Allura's dev list :-) [3]

[1] https://forge-allura.apache.org/p/allura/wiki/Features/

[2] https://forge-allura.apache.org/p/allura/wiki/Feature%20Comparison/

[3] https://lists.apache.org/thread/gns66ls2v3hqzkxmgwl5ykpqkd4dxpn1

Cheers,
Nathan

Re: Migrate from Git to SVN on Fedora server

[Nathan Hartman]

On Tue, May 21, 2024 at 6:55 AM Jeffrey Walton  wrote:

> Hi Everyone,
>
> I'd like to migrate some source code from Git to SVN on my Fedora
> server. The rub is, I'd like to use Nginx instead of Apache.
>
> I think I can switch the repo from Git to SVN by performing the
> following at the server:
>
> cd /var/test-src
> find . -name '.git' -exec rm -rf {} \;
> svnadmin create /var/test-src
>
> That should stand up the SVN server on the existing source code (that
> was formerly under Git). Also see
> .
>
> What I am less sure about is, how to put a Nginx web front-end on the
> SVN repo. What I have come across is using Apache+Nginx with Nginx in
> a proxy configuration. I would prefer to have a purely Nginx web
> server.
>
> Does anyone have a recommendation for a Nginx web front-end?
>
> Thanks in advance.
>

Hi Jeffrey,

The reason why you can find setups that use Apache-only or Apache+Nginx,
but not Nginx alone, is because access to Subversion repositories through
Apache requires use of an Apache module (mod_dav_svn). Currently there
isn't such a module for Nginx.

Hope this helps,
Nathan

Re: PoshSvn – Subversion for PowerShell

[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

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

[Nathan Hartman]

On Sun, Jan 21, 2024 at 3:08 PM Nathan Hartman  wrote:
>
> On Sun, Jan 21, 2024 at 12:06 PM Daniel Sahlberg
>  wrote:
> >
> > 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
>
>
> I also saw this when trying to reconcile staging and publish during
> the 1.14.3 release. I also thought this was an error, but after
> further examination I came to the conclusion that the message was
> correct. I can try to look into it later, but if you'd like to
> experiment with it first, I suggest looking at 'svn mergeinfo
> --show-revs eligible' of both branches and seeing what those unmerged
> revs are. I did this when I worked on the release and IIRC this is
> what I found:
>
> There are two different issues here (from what I remember):
>
> (1) Some time ago, there were some typos that I found in one of the
> release note pages and I subsequently grepped and fixed in multiple
> places on the staging branch. Those typos were also present in the
> 1.15 release notes, which are present in staging but not in publish.
> Unfortunately, when I fixed the typos (including in the 1.15 release
> notes), it didn't occur to me that they could not be merged cleanly to
> publish until publish also gained the 1.15 release notes.
>
> (2) svn-role updates the "upcoming changes in the next release"; since
> release(s) were made in the meantime, many of those "upcoming" changes
> are no longer listed -- svn-role deleted those texts. So, if you try
> cherrypicking those commits across the branches, I think you'll see
> text of old "upcoming changes" being added, and eventually being
> deleted again; the sum total is that no textual changes should remain
> once they're all merged, except text about the few backported changes
> that happened in the last 3 weeks.
>
> To get past the error, I think you can identify which revisions from
> that "missing ranges" list we don't actually need to merge from
> publish to staging (all svn-role "upcoming changes" up to the 1.14.3
> release) and do a --record-only merge; that will add those revs to
> staging's mergeinfo without changing any text. I think that should
> eliminate most of the complaint. If any revs remain, we can look into
> those and see what happened. Alternatively, if you don't feel
> comfortable with a --record-only merge, you could cherrypick them
> one-by-one and watch the text being added and subsequently removed.
>
> All that is from memory; hopefully I remember correctly. I'll try to
> look into it later...
>
> Hope this helps,
> Nathan


Okay here's what's going on:

You wanted to catch staging up to publish. Subversion wants the
reintegrate source (in this case, publish) to be strictly newer than
the destination (in this case, staging). This means we can do a bunch
of work on publish and merge it to staging; then we can do a bunch of
work on staging and merge it to publish. In effect, we alternately
make one branch newer and then reintegrate it to the other, and then
vice versa.

But, since we have some long-lived items in staging that have not yet
been merged to publish (namely, the not-yet-released 1.15 release
notes), publish is no longer strictly newer than staging. (Indeed, I
examined all the revisions it complains about and all of them happened
on the staging branch and involve the 1.15 release notes file.) This
is why we fail the checks that happen before the merge takes place and
we see the error. This is touched upon in the 1.18 release notes:

https://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate

Note: In my previous message I mistakenly said that some svn-role
revisions were involved; I remembered incorrect

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

[Nathan Hartman]

On Sun, Jan 21, 2024 at 12:06 PM Daniel Sahlberg
 wrote:
>
> 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


I also saw this when trying to reconcile staging and publish during
the 1.14.3 release. I also thought this was an error, but after
further examination I came to the conclusion that the message was
correct. I can try to look into it later, but if you'd like to
experiment with it first, I suggest looking at 'svn mergeinfo
--show-revs eligible' of both branches and seeing what those unmerged
revs are. I did this when I worked on the release and IIRC this is
what I found:

There are two different issues here (from what I remember):

(1) Some time ago, there were some typos that I found in one of the
release note pages and I subsequently grepped and fixed in multiple
places on the staging branch. Those typos were also present in the
1.15 release notes, which are present in staging but not in publish.
Unfortunately, when I fixed the typos (including in the 1.15 release
notes), it didn't occur to me that they could not be merged cleanly to
publish until publish also gained the 1.15 release notes.

(2) svn-role updates the "upcoming changes in the next release"; since
release(s) were made in the meantime, many of those "upcoming" changes
are no longer listed -- svn-role deleted those texts. So, if you try
cherrypicking those commits across the branches, I think you'll see
text of old "upcoming changes" being added, and eventually being
deleted again; the sum total is that no textual changes should remain
once they're all merged, except text about the few backported changes
that happened in the last 3 weeks.

To get past the error, I think you can identify which revisions from
that "missing ranges" list we don't actually need to merge from
publish to staging (all svn-role "upcoming changes" up to the 1.14.3
release) and do a --record-only merge; that will add those revs to
staging's mergeinfo without changing any text. I think that should
eliminate most of the complaint. If any revs remain, we can look into
those and see what happened. Alternatively, if you don't feel
comfortable with a --record-only merge, you could cherrypick them
one-by-one and watch the text being added and subsequently removed.

All that is from memory; hopefully I remember correctly. I'll try to
look into it later...

Hope this helps,
Nathan

Re: 100% CPU utilization by mod_authz_svn

[Nathan Hartman]

On Fri, Dec 22, 2023 at 6:23 AM radek.krotil.siemens.com via users <
users@subversion.apache.org> wrote:

> 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: Subversion 1.14.2 on Linux how to enable plaintext password store?

[Nathan Hartman]

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: Is there a write opposite to "svn cat"?

[Nathan Hartman]

On Mon, Nov 27, 2023 at 1:47 AM Daniel Sahlberg 
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)."

Cheers
Nathan

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

[Nathan Hartman]

On Mon, Nov 6, 2023 at 1:34 PM Bo Berglund  wrote:
>
> I am hunting for when a particular change was made in a file under version
> control. It happened years ago.
>
> The versioning system was migrated from CVSNT to Subversion back in 2017 and 
> the
> old CVS repository was imported into SVN with all branches and tags etc
> available.
>
> The change I am looking for should have happened back in 2004 when the 
> property
> behind what I am hunting for was changed but I cannot find any message about
> this in my archives...
>
> So now I am looking for *when* a particular section of a source file was 
> changed
> so I would like to list all revisions when this file had a commit to it at 
> all.
>
> Then I will extract the revisions in a binary fashion to find when exactly the
> change that should have been done in 2004 was actually done.
>
> Can this be done somehow using the command line interface to svn?
> If so what would be the correct command to issue?
>
>
> I need to get a list of the revisions where the file was changed.
>
> I tried reading the redbean documentation on line but I am not sure I 
> understand
> the way the export works for different revisions of the same file.
>
> The way I understand svn the revision when you export/checkout a file at a
> specific rev number is the file as it existed at the time that revision was
> committed. So even if the file did not change during that revision there will 
> be
> an exported file if I use the -r argument, right?
>
> So I need to start by some command to give me the revision numbers when the
> specific file *actually changed*. So I can focus on the commits when this file
> changed instead of getting lots of the same file because the revisions were 
> done
> because something else changed..
>
> Can that be done?
>
> --
> Bo Berglund
> Developer in Sweden
>


Some things that might be helpful:

(1) The '--quiet' (or '-q') switch to 'svn log', together with the
 as mentioned by Robert, e.g.,:

$ svn log --quiet 

Using the INSTALL file in a working copy of Subversion's sources as an example:

$ svn log --quiet INSTALL


r1911278 | hartmannathan | 2023-07-25 23:25:21 -0400 (Tue, 25 Jul 2023)

r1905955 | kotkov | 2022-12-13 04:49:29 -0500 (Tue, 13 Dec 2022)

r1903577 | hartmannathan | 2022-08-19 12:31:35 -0400 (Fri, 19 Aug 2022)

r1899399 | hartmannathan | 2022-03-30 17:26:30 -0400 (Wed, 30 Mar 2022)

r1894501 | dsahlberg | 2021-10-23 03:20:35 -0400 (Sat, 23 Oct 2021)

r1894491 | dsahlberg | 2021-10-22 14:43:24 -0400 (Fri, 22 Oct 2021)

r1881958 | julianfoad | 2020-09-23 11:04:31 -0400 (Wed, 23 Sep 2020)

r1877960 | futatuki | 2020-05-20 14:58:15 -0400 (Wed, 20 May 2020)

(snip some 600 lines)

r840117 | kevin | 2001-09-05 09:59:27 -0400 (Wed, 05 Sep 2001)

r840082 | kfogel | 2001-08-31 02:15:13 -0400 (Fri, 31 Aug 2001)

r840068 | kfogel | 2001-08-30 23:22:56 -0400 (Thu, 30 Aug 2001)

r839979 | kfogel | 2001-08-16 17:03:09 -0400 (Thu, 16 Aug 2001)

r839944 | kfogel | 2001-08-14 20:28:37 -0400 (Tue, 14 Aug 2001)

r839943 | kfogel | 2001-08-14 20:23:24 -0400 (Tue, 14 Aug 2001)

r839929 | kfogel | 2001-08-13 20:54:08 -0400 (Mon, 13 Aug 2001)

r839536 | kfogel | 2001-06-15 13:00:25 -0400 (Fri, 15 Jun 2001)

r836593 | kfogel | 2000-06-06 13:47:11 -0400 (Tue, 06 Jun 2000)


(2) The '--revision' (or '-r') switch with a {DATE} (or {DATE}:{DATE}
range) instead of a revision number. For example, with the same
INSTALL file, if I want to see the changes made in 2014:

$ svn log --quiet --revision {2014-01-01}:{2014-12-31} INSTALL

r1572339 | breser | 

Re: Checksum mismatch in single repo

[Nathan Hartman]

On Fri, Oct 27, 2023 at 6:42 AM Pierre Fourès 
wrote:

> Hi Felix,
>
> Your SMART data looks good to me, except for the hard drive temperature.
> Experiencing 53°C looks quite a lot to me. Yet, this should not be the
> cause of your corrupted data.
>
> Two data-corruption problems on the same server which looks independant
> from each other, and occured at a quite long time range interval from each
> other, reminds me of a server who caused me lots of trouble until I
> discovered it had memory defects. I suspected hard disk failure and/or hard
> drive data corruption, but couldn't nail it with smartctl nor with the
> badblocks utility. I eventually nailed the problem when doing extensive
> test with the stress utility, showing that in some runs, the memory was
> corrupting data (which ended up corrupting data on disk). I had to run the
> tests many times to spot the defect. Subtle defects are real hard to spot
> on.
>
> IMO, I would advice you to do a full scan of this server to spot where the
> problem is in order to file this trail of problems as definitively solved.
> In my situation, similar to your one, the problems occured too distantly
> from each other to commit resources to investigate thoroughly. This period
> of uncertaintly and intuitive distrust of the server caused us a hidden
> costs like stress and fatigue. Having experienced it, if that happened
> again, I would prefer to rule out this situation quickly instead of knowing
> it dormant.
>
> Here are some links which might be relevant to you :
>   - https://en.wikipedia.org/wiki/Badblocks
>   - https://wiki.archlinux.org/title/Badblocks
>   - https://man.archlinux.org/man/stress.1
>   - https://wiki.archlinux.org/title/Stress_testing
>   - https://www.memtest.org/
>
> Best Regards,
> Pierre.
>


I can speak to RAM corruption as well. In one instance, we were
experiencing the strangest problems and blamed just about everything until
I ran the above memtest utility and it showed tremendous numbers of memory
errors. When I opened up the hardware, I found dust on and around the
memory. I cleaned that very thoroughly, put the system back together, and
ran memtest overnight or over a weekend with zero errors. Evidently, dust
can be conductive enough to act like a bunch of resistors across pins that
shouldn't have resistors across them.

As trivial as that sounds, I recommend to check for things like dust, and
since heat was mentioned, I'd check for fans that don't spin very freely. I
also recommend running memtest over a weekend, and finally, I am with the
camp who believe that ECC RAM is a good idea, so I'd suggest to check
whether you are using ECC RAM.

Hope this helps,
Nathan

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

[Nathan Hartman]

>
>  Forwarded Message 

(snip headers)

>
> Hello Users Community,
>
> Hope you are doing great.
> I have installed Apache Subversion 1.13 in Ubuntu 20.04.5 using apt-get (
>  From Ubuntu package ) and also installed libapache2-mod-svn.
> I do not have any plan to upgrade the OS to Ubuntu 22.04. I am looking if I
> use apt-get upgrade subversion will automatically upgrade Subversion to
> 1.14 and also upgrade the library.



Not by default (however see below): Generally, once a Ubuntu release line
like 20.04.x is made, software in the Ubuntu package repositories will get
only bug fixes and security fixes, not new features. This means that the
Subversion packages will remain at 1.13.x for Ubuntu 20.04.x when using the
default package repositories.

However, it is likely that Ubuntu's backports repositories have the newer
Subversion 1.14.x releases. The backports repositories are the preferred
way to install newer releases of software packages on older releases of
Ubuntu.

I haven't used Ubuntu in many years so I cannot give detailed steps, but
this documentation looks promising:

https://help.ubuntu.com/community/UbuntuBackports

Hope this helps,
Nathan

Re: svnadmin dump much slower in Debian Bookworm than in Debian Bullseye

[Nathan Hartman]

On Thu, Aug 10, 2023 at 6:53 PM  wrote:
>
> Let me start by saying that I recognize that this situation is probably 
> specific to Debian.  Even so, it seems possible that someone here might be 
> able to give me helpful ideas about where or how to start looking to track 
> down the symptom I am seeing.
>
> A set of svnadmin dump commands that run as part of a backup procedure seem 
> to be _much_ slower in Bookworm than in Bullseye.  Prior to the upgrade to 
> Bullseye, these commands took slightly less than one hour.  After the 
> upgrade, similar commands (dumping a few more revisions) require more than 
> six hours.  The script that performs these commands has not been changed.
>
> Bookworm has subversion 1.14.2.  Bullseye had 1.14.1.
>
> If you had these symptoms, where would you start to look?
>
> Thanks,
>
> Ken


That's a pretty significant slowdown.

Unfortunately there's no easy way to say what might cause it, since
many things can happen (and change) between OS releases. Subversion is
only one of many, probably thousands, of components that changed
during the OS upgrade. Whatever is causing the slowdown could be in
Subversion or in another component.

I assume the two releases are running on the same hardware? Same
storage hardware? Same file system format?

Can you think of anything else significant that may have changed in
the system besides the OS upgrade itself?

Has anything very large, or a very large number of revisions, been
committed to the repository after the OS upgrade took place?

Could anything significant be happening in the background? Especially
something related to disks?

The strategy should be divide and conquer, trying to isolate the
problem to a specific component or at least rule out as many things as
possible to narrow down the search space. Since you've noticed a
slowdown related to dumping the Subversion repositories, and if
there's nothing else that you can easily test first, then you might
try to rule out (or rule in) whether the slowdown is caused by changes
in Subversion between 1.14.1 and 1.14.2. Since it was "fast" with
1.14.1 and "slow" with 1.14.2, the way I might approach it would be to
build both 1.14.1 and 1.14.2 on the new OS and try the dump with each.
You don't need to build with all the options and dependencies; you
only need the minimal dependencies (APR, APR-util,
sqlite-amalgamation, and utf8proc) to get a functional svnadmin. You
probably shouldn't do builds and tests on a production system that is
serving repositories; I would use another machine for the tests.

If your builds of 1.14.1 and 1.14.2 take approximately the same time
to perform the dump, then the problem is not in Subversion itself,
you've ruled that out, and you'd have to look elsewhere in the system:

If both are "slow" then something else changed in the OS or hardware
or the repository being dumped.

If both are "fast" while the package manager's 1.14.2 is "slow" then
I'd wonder what's different about the packaged binaries.

If, however, there is a significant speed difference -- i.e., if
1.14.1 is "fast" and 1.14.2 is "slow" -- then I'd start looking into
what changed in Subversion; if we get to this stage, then I would go
into strategies of how to minimize the search effort within
Subversion. But first, we have to know whether Subversion is the
component to dive further into.

By the way, this is the list of changes between 1.14.1 and 1.14.2,
with the trunk revision from which each change was merged to the
1.14.x branch. Before I wrote the above, I looked over this list to
see if anything glaringly obvious caught my attention; I didn't see
anything like that, which is why I'm suggesting to rule out effects
from other components first.

 * r1889487
   swig-py: Fix doubly destroying memory pool with cyclic garbage collector.

 * r1896877
   Fix misleading -r option documentation for some svnadmin subcommands.

 * r1887704
   Follow up to r1865987, r1866588: Unbreak a msgid.

 * r1891908
   Fix a bug where «make davautocheck» immediately after configure failed
   hard because of an unbuilt dependency.

 * r1885199
   swig-py: Skip some tests on Python 2 if default encoding is 'utf-8'.

 * r1886708
   swig-py: Fix dependency of make copy-swig-py target.

 * r1883838, r1883989, r1886460, r1886582
   Add test coverage for CVE-2020-17525 (mod_authz_svn NULL deref)

 * r1887641, r1890013
   Fix encoding of error message on failure of system() call.

 * r1889629
   Document how the port number is passed to custom tunnels.

 * r1897449
   tests: Include additional information in an error message.

 * r1894734
   Fix issue #4880, "Use-after-free of object-pools when running in httpd"

 * r1892121
   Fix an error message when running make davautocheck.

 * r1883355
   Use the APR-1.4+ API for flushing file contents to disk.

 * r1899227
   Don't show unreadable copyfrom paths in 'svn log -v'

 * r1898633
   Fix sporadic testCrash_RequestChannel_nativeRead_AfterException failure

 * r1892470, 

Re: Use of ssh for authentication?

[Nathan Hartman]

On Thu, Jul 13, 2023 at 1:49 PM Daniel Sahlberg
 wrote:
>
> Den tors 13 juli 2023 kl 19:08 skrev David Aldrich 
> :
>>
>> 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


(Looks like Daniel already touched on some of these points while I was
writing the following, but maybe there's still something helpful
here...)

If I understand correctly, the issue you are encountering is as
follows: The Subversion working copy, as well as the Subversion
command line client, are on a remote machine running some Unix(like)
OS (Linux, BSD, etc). You are accessing that machine by a
terminal-based SSH session. While working with the Subversion client,
any operation that requires a password (e.g., 'svn commit') pops up a
GUI password dialog on that *remote* machine, not the machine you're
sitting in front of. And that remote machine might be in another
country.

See further below for workarounds, but first...

One solution that should work, but another user and I both tried and
were not successful, is to use GPG Agent instead of KDE's and GNOME's
keychains. With GPG Agent, it should be possible to either (1) get a
text-based password prompt that works over SSH, or (2) using a
different module, to automatically load a password from some encrypted
store and cache it in memory so that you aren't prompted at all. Maybe
you can make one of these scenarios work and, if so, any pointers
would be greatly appreciated. The following archived email, part of a
larger discussion about the very issue of SVN client use through a SSH
session, may be of interest:

https://lists.apache.org/thread/lfz4dzy0q8q8jdcd04wv4qzjvbp2ytfk

Now, the workarounds. Neither of these are optimal, but they are known to work.

Workaround 1: In addition to SSH, also have a VNC (or similar GUI
access) session to the remote machine, so that you can access the GUI
password dialog when it pops up. To reduce the number of times that
happens, I think there is a way to configure the GNOME keyring on that
remote machine to cache passwords in memory for a longer period of
time; I don't use GNOME so I can't give a step-by-step for that,
unfortunately.

Workaround 2: If Workaround 1 is too annoying and if the risk of
Workaround 2 is acceptable, Subversion supports a plaintext password
cache. If your Subversion client is version 1.12.x through 1.14.x, it
may or may not be able to *store* passwords in the plaintext cache,
depending on how the Subversion client was compiled; however, it will
use such cached passwords if already stored. There is a Python script
that can store a password in that cache. You could run that once and
then not be bothered by password prompts anymore (as long as the
password continues to be accepted by the Subversion server). Note
again that in this scenario, the password would be cached on disk in
plaintext, which may or may not be acceptable to you in your use case.

If you're interested in Workaround 2, the following section of the
Subversion FAQ discusses how passwords are cached (encrypted or
plaintext) and also provides the link to the aforementioned Python
script in case 

Re: Unable to commit code in SVN repo

[Nathan Hartman]

On Thu, Jul 13, 2023 at 10:09 AM Pothkanoori, Praveen Kumar(HCL) via
users  wrote:
> [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--
> --\nCOMMIT VIOLATION:\nCommit comment must have at
> least 10 characters after the colon\nRevision property "svn:log"
> did not match regex ":.{10,}"\nMore info at
> http://svn/repos/wc/onestore/admin/rules.html\n  [409, #165001]


Hi,

Your site has what is called a pre-commit hook, which verifies that
certain aspects of your commit match what the administrator has
configured. You can read more about pre-commit hooks at [1].

In this case, according to the error message, your site's pre-commit
hook is looking for a Jira issue ID in the log message. If you believe
that you have included the needed Jira issue ID, then you should
consult your site's administrator to find out why it is not being
accepted by the pre-commit hook.

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

Hope this helps,

Nathan

Re: Maintaining a SVN 1.7 mirror without network access

[Nathan Hartman]

On Sat, Jun 3, 2023 at 2:41 PM Andreas Stieger 
wrote:

> Hello,
>
> On 2023-06-03 00:25, Colcord, Scott via users wrote:
> >
> > [...] Subversion 1.7 [...] periodically mirror it to a location that
> > does not have direct net access
> > [...]
> >
> > the mirror needs to be able to receive one divergent commit after the
> > load (this commit alters svn:externals locations to be appropriate for
> > the mirror’s network).
> > [...]
> >
> > Is there a way to replace the mirror repo with the contents of the
> > dump, without needing to manually delete it first – and ideally
> > without needing local rights (perhaps using svnrdump)?  Essentially, I
> > want the revisions from the dump file to replace the same-number
> > revisions in the repo, rather than appending.
> >
> > Is this possible?
> >
>
> No you cannot do it in the way you described, and your approach is
> incorrect. Not for svn, but IT.
>
> For subversion: If you alter the history of the repository in any way,
> all working copies will be invalidated. So even if you repeat the steps
> described, you will need to get new working copies.
>
> Please separate immutable history from the location-specific
> configuration. Either have the network configuration represented in a
> location-specific source, such as local DNS or other
> network-discoverable data. Or simply do not version location-specific
> data that creates a need to change it. Or make the code discover it's
> own location and pick one of the versioned configurations. This isn't
> even working around a limitation of svn, but good system design.
>
> If you proceed like that, you can use the incremental dump feature which
> should make administration faster and more straightforward.



I'd like to add that since Subversion 1.5 you can use relative locations
for svn:externals properties as documented at [1], in case that's helpful.

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

Cheers
Nathan

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

[Nathan Hartman]

On Thu, Mar 30, 2023 at 11:13 PM Maxim Cournoyer
 wrote:
>
> Hello,
>
> This has been the case for the last 3 years, so I thought it'd be nice
> to report it, toward having it fixed!  It seems to affect only the
> i686-linux machine, and not x86_64-linux.

Interesting. So, it fails on 32-bit, passes on 64-bit.

Continuing inline below...

> The test suite in run in parallel via the -j option of Make, e.g.
>
> 'make -j24 check'
>
> The PARALLEL environment variable is also set to the same value (e.g.:
> 24) before the test suite runs.

I noticed this from near the end of your output:

> Test suite failed, dumping logs.
> error: in phase 'check': uncaught exception:
> %exception #< program: "make" arguments: ("check" "-j" "16") 
> exit-status: 2 term-signal: #f stop-signal: #f>
> phase `check' failed after 193.9 seconds
> command "make" "check" "-j" "16" failed with status 2

Notice the "check" "-j" "16" -- but you requested -j24. Is it possible
that a mismatch here is contributing to the failures? Could you try
'make -j16 check' and see if the results are any different?

>From earlier in your output:

> At least one test FAILED, checking 
> /tmp/guix-build-subversion-1.14.2.drv-0/subversion-1.14.2/tests.log
> FAIL:  client-test: Unknown test failure (-6); see tests.log.
> FAIL:  diff-diff3-test: Unknown test failure (-6); see tests.log.
> FAIL:  fs-fs-pack-test: Unknown test failure (-6); see tests.log.
> FAIL:  fs-fs-private-test: Unknown test failure (-6); see tests.log.
> FAIL:  fs-test: Unknown test failure (-6); see tests.log.
> FAIL:  io-test: Unknown test failure (-6); see tests.log.
> FAIL:  mtcc-test: Unknown test failure (-6); see tests.log.
> FAIL:  op-depth-test: Unknown test failure (-6); see tests.log.
> FAIL:  ra-test: Unknown test failure (-6); see tests.log.
> FAIL:  repos-test: Unknown test failure (-6); see tests.log.
> Summary of test results:
>   2237 tests PASSED
>   165 tests SKIPPED
>   65 tests XFAILED (16 WORK-IN-PROGRESS)
>   10 tests FAILED
> Python version: 3.9.9.
> SUMMARY: Some tests failed

Do you happen to have the tests.log file mentioned above? It might
contain more details about the failures (or it might just tell us
about the same uncaught exception).

Finally, do the same tests fail on each parallel run or are there
variations?

Thanks for the report,
Nathan

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

[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:
>
>
> (svn, version 1.14.2 (r1899510))
> [[[
> > svn co http://server/testrepo/project/trunk
> Redirecting to URL 'https://server/testrepo/project/trunk':
>  U   trunk
> Redirecting to URL 
> 'https://server/testrepo/testproject/trunk/doc/file_external.txt':
>
> Fetching external item into 'trunk\my_file_external.txt':
> svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed: 
> EXTERNALS.def_repos_relpath
>
> Checked out revision 34.
> svn: E205011: Failure occurred processing one or more externals definitions
> ]]]
>
>
> The file external is not checked out.
> In my case, the redirection points from http://server/ to https://server/.
>
> The file external refers to the full http URL:
>
>
> (externals property of project/trunk)
> [[[
> >svn pg svn:externals trunk
> http://server/testrepo/testproject/trunk/doc/file_external.txt@30 
> my_file_external.txt
> ]]]
>
>
> The output of svn --version is:
>
> [[[
> svn, version 1.14.2 (r1899510)
>compiled Sep 24 2022, 10:21:16 on x86-microsoft-windows
>
> 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/
>
> The following repository access (RA) modules are available:
>
> * ra_svn : Module for accessing a repository using the svn network protocol.
>   - with Cyrus SASL authentication
>   - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
>   - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV protocol using serf.
>   - using serf 1.3.9 (compiled with 1.3.9)
>   - handles 'http' scheme
>   - handles 'https' scheme
>
> (...)
> ]]]
>
>
> The server version is 1.10.4 (r1850624).
> Can anyone confirm this issue?
>
> Best Regards
> Christoph


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

Re: redirection error with file externals - possible bug

[Nathan Hartman]

On Sat, Mar 11, 2023 at 4:29 PM Daniel Sahlberg 
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
>>
>> 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
>


I have filed this issue as SVN-4911:
https://issues.apache.org/jira/browse/SVN-4911

Nathan

Re: How to accept ~ (obstructed by item of a different kind) status files?

[Nathan Hartman]

On Tue, Feb 21, 2023 at 3:42 PM Jon Daley via users
 wrote:
>
> Yeah, I do:
>
> mv file d
> svn remove file
> mv d !$
> svn add !$

$ svn remove --keep-local file
$ svn add file

should accomplish the same thing with fewer commands. Afterwards, 'svn
status' should show 'R' for Replaced.

This should work even if 'file' was originally a symlink that was
"manually" replaced by a regular file.

Cheers,
Nathan

Re: Subversion assertion upon commit

[Nathan Hartman]

On Thu, Dec 15, 2022 at 7:48 AM Don Newbold (GSC)
 wrote:
>
> Nathan,
>
> Understood. If and when I see the assertion again I'll retain a copy of
> the file and send that along with the reporting email.
>
> Don

Hi Don,

Please note that submitting a file here would make it public, so
please take that into consideration!!

(If a file needs to remain proprietary, we can work with you to find a
way to get just the information needed without exposing the file's
contents...)

Thanks!
Nathan

Re: Subversion assertion upon commit

[Nathan Hartman]

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.


Ah, I see. Thanks for the clarification.

There are two separate items here.

(1) Subversion complains when you try to commit a file that (a) has the
svn:eol-style property and (b) contains a mixture of newline styles.
This is actually *correct* behavior: Since Subversion is going to
modify the file as it passes from your working copy to the repository,
to normalize all line endings to LF style, it must first make sure that
the file does not contain a mixture, since that may indicate a user
error. Consider, for example, the possibility of accidentally setting
this property on a binary file. In such a file, the CR and LF
characters (decimal 13 and 10 respectively) could be not line endings
at all, but rather part of the binary data. Changing these during a
commit operation could irrecoverably corrupt the data. As a safety
measure, Subversion won't do it unless all lines have the same line
ending style.

(2) The assertion failure. This definitely indicates a bug somewhere.
The tricky part, of course, is to find the cause, which is made much
more difficult when there isn't a reproduction script that can expose
the issue for single-step debugging, or at least a stack trace. What I
do know is that the function in question, translate_newline(), which is
part of the logic that handles line ending and keyword translation and
de-translation, both of which the file in question has, is somehow
receiving 'newline_buf' contents that do not match one of the allowed
values "\n", "\r", or "\r\n". The data in this 2-character buffer is
coming from the file being (de-)translated, so it seems that somehow,
some sequence of '\n', '\r', and/or '$' (for keywords) that was present
in the file before you ran dos2unix confused things. It seems that
whatever happened is extremely rare, since this is the only report of
this assertion failure that I can find anywhere, except for one that
occurred in testing with an intermediate version of this logic during
its development a really long time ago [1]. I could go ahead and file
this as a bug in the issue tracker in case others encounter this
assertion failure. That could help to gather more data about it if
other users encounter it.

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

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

Thanks,
Nathan

Re: Subversion assertion upon commit

[Nathan Hartman]

On Tue, Dec 13, 2022 at 6:11 PM Don Newbold (GSC)
 wrote:
>
> I've received notice of an assertion upon committing some files.
>
> The assertion was via a dialog box, which is shown in the attached
> image. The text of the dialog box is as follows - the Ctrl-C
>
>
>
> ---
> 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.0\ext\subversion\subversion\libsvn_subr\subst.c'
>   line 724: assertion failed (STRING_IS_EOL(newline_buf, newline_len))
> ---
> OK
> ---
>
>
>
> WHAT I WAS DOING:
>
> I was committing several files spread across several directories. This
> included .doc files, .docx files and a .txt files. The dialog box
> appeared while the .txt file was being processed (based on commit
> failure status text). I have many, many times over the years seen
> similar commit request fail because of newline inconsistencies with the
> .txt file. Upon using dos2unix on the .txt file, the commit normally
> goes through to successful completion. I applied dos2unix this time and
> the commit completed successfully.
>
>
>
> CLIENT HOST:
>
> Edition Windows 10 Pro (64-bit)
> Version 21H2
> Installed on‎8/‎2/‎2021
> OS build19044.1889
> Experience  Windows Feature Experience Pack 120.2212.4180.0
>
>
>
> CLIENT SOFTWARE
>
> TortoiseSVN 1.14.0, Build 28885 - 64 Bit , 2020/05/24 13:32:45
> ipv6 enabled
> Subversion 1.14.0, -release
> apr 1.6.5
> apr-util 1.6.1
> serf 1.3.9
> OpenSSL 1.1.1g  21 Apr 2020
> zlib 1.2.11
> SQLite 3.29.0
>
>
>
> SERVER HOST:
>
> Edition Windows 10 Pro (64-bit)
> Version 21H2
> Installed on‎8/16/‎2022
> OS build19044.2251
> Experience  Windows Feature Experience Pack 120.2212.4180.0
>
>
>
> SERVER SOFTWARE:
>
> VisualSVN Server Version 5.0.2
> Subversion 1.14.2
> Apache 2.4.53
>
>
>
>
> --
> Don Newbold
> 256-880-8787, x110
> General Standards


Hi Don,

Thank you for the detailed error report.

Since you've experienced this error before with .TXT files and the
issue appears somehow related to line endings, do you by chance have
any svn properties set on the file? In particular, does it have
"svn:eol-style", "svn:mime-type", or "svn:keywords" properties? If so,
what are these property values? Do you have any other properties set
which may seem significant to this issue?

To check for property values:

If you are using TortoiseSVN, you should be able to right-click the
file in Explorer to get the context menu and then TortoiseSVN ->
Properties.

Alternatively if you have the command line "svn" client, you could
check whether the file has properties with:

svn proplist FILENAME.TXT

and if that shows anything, show the property values with:

svn propget svn:eol-style FILENAME.TXT
svn propget svn:mime-type FILENAME.TXT

etc.

Cheers,
Nathan

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

[Nathan Hartman]

On Thu, Sep 22, 2022 at 3:59 PM Sean McBride  wrote:
>
> 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

It occurs to me that we don't have a FAQ or other easy-to-find
documentation on maximums, such as the maximum file size, etc.

The largest publicly-accessible SVN repository of which I am aware is
the Apache.org one in which Subversion's own sources (as well as those
of numerous other projects) are housed. This repository contains
approximately 1.9 million revisions. According to [1] the dump of this
repository expands to over 65 gigabytes.

But that seems to be a drop in the ocean when Aleksa writes:

On Fri, Sep 23, 2022 at 3:45 AM Aleksa Todorović  wrote:
> I can confirm that Subversion can handle repositories with 100,000+ 
> revisions, size of committed files ranging from few bytes to several GBs, and 
> total repo size of up to 20TB.

It is possible that others here are aware of even larger repositories.

My biggest concern mirrors what Mark said about administrative burden:
the size of backups and the time it takes to make them. Mark addressed
that point quite well. Whatever you do, you must have good backups!
(My $dayjob does backups 3 different ways: the filesystem on which the
repository is stored is backed up regularly. In addition we take
periodic 'hotcopy' backups, and periodic full 'dump' backups.
Obviously as a repository grows, this takes longer and requires more
storage.

[1] http://svn-dump.apache.org

Cheers,
Nathan

Re: Invalid cross-link error when have a mounted subdirectory

[Nathan Hartman]

On Sun, Aug 7, 2022 at 12:13 PM Nico Kadel-Garcia  wrote:

> On Sun, Aug 7, 2022 at 8:40 AM Jon Daley via users
>  wrote:
> >
> > I'm not sure what version this change happened in, but I used to be able
> > to have my /home directory mounted and use subversion commands in my home
> > directory, even though the .svn directory exists at /.svn
>
> Which version are you using, and on which operating system?



Also important: Which was the old version that worked as expected?

Do you have both versions available and can you run "svn version --verbose"
and share the output?

Knowing both versions makes it possible to bisect (provided the issue can
be reproduced).

Bisecting is probably the first avenue I would explore in any given "it
used to work but now it's broken" situation.

Cheers,
Nathan

Re: line 10866: assertion failed (svn_dirent_is_absolute(local_abspath))

[Nathan Hartman]

On Wed, Jul 6, 2022 at 10:56 AM Klaey Matthias LCPF-CH
 wrote:
> I encounter the same exception as 
> https://lists.apache.org/thread/cxtl57o416ctbbzb315yh6x11kqyn7k3, though 
> likely with a different cause. In my case:

(snip)

> 'D:\Development\SVN\Releases\TortoiseSVN-1.14.3\ext\subversion\subversion\libsvn_wc\wc_db.c'
>
> line 10866: assertion failed (svn_dirent_is_absolute(local_abspath))

We've seen various reports of this exact error on that exact line over
the years and it would be nice to finally track down the cause(s).
(One thing that could help is to make SVN report the path in question
together with the error.)

> Environment:
>
> Windows 10 Enterprise 20H2 19042.1706
> TortoiseSVN 1.14.3, Build 29387 - 64 Bit , 2022/04/08 19:31:22
> SVN repo on some enterprise server
> SVN working copy on a network drive (I know this may sound strange but it’s 
> where the issue happens)
>
>
>
> Repro steps:
>
> [TortoiseSVN > Commit] on a large folder of the working copy, i.e. the 
> operation takes several minutes.
> Undock of the laptop where the operation is taking place, i.e. the connection 
> to the network drive temporarily gets lost è exception.

Not sure if I understand correctly, but is the laptop being undocked
while the commit is in progress? If so, I wouldn't expect anything to
work correctly due to the disconnection. If it's being undocked after
the commit is complete, what (if any) other steps do you take that
lead to the error?

> PS: I didn’t find out how to get an apache user ID in order to respond to the 
> above referred thread. Neither did I subscribe to this mailing list. So 
> please cc: me for requesting more information.

You don't need an apache user ID (though I can see why the
lists.apache.org interface is confusing on that point). You can reply
to any email as long as you can get the email's Message-ID value from
the raw message. This was explained on the #svn-dev channel on IRC on
18 July 2021 at [1]. I'll copy that text here -- note that we no
longer have mail-archives.apache.org. It has been superseded by
lists.apache.org. To get the raw message, and hence the Message-ID,
from lists.apache.org, hover over the lower right corner of the
message in question until 3 icons appear and then click the "View raw
source" (paper-with-folded-corner icon). Other than that substitution,
the rest is the same:

07:52 [Arfrever] Songro: If you want that your e-mail appear in
archives as reply to another e-mail, you can:
07:53 [Arfrever] 1. In mail-archives.apache.org, use "View raw
message" and get Message-ID value.
07:54 [Arfrever] 2. In your e-mail, add "In-Reply-To: ${message_id}".
07:55 [Arfrever] (This must be in headers, not in content)
08:07 [Arfrever] You can search in internet for how to do it in your
e-mail software.
08:07 [Arfrever] E.g. about Thunderbird:
https://superuser.com/questions/1177870/how-to-manually-set-the-in-reply-to-header-in-thunderbird

Since this is already a new mail thread and it links to the old one,
it's not necessary to do this now, so just for future reference... :-)

Hope this helps!

References:
[1] https://colabti.org/irclogger/irclogger_log/svn-dev?date=2021-07-18

Cheers,
Nathan

Re: Unable to Check Out SVN Folders

[Nathan Hartman]

On Tue, May 17, 2022 at 7:52 PM Cameron Hagen  wrote:

> Hello there,
>
> I'd like to check out a number of SVN folders, but with each one I run
> into an error where after checking out a few documents, it stalls, and then
> gives me this error:
>
> *Checkout Failed!*
>
> *Error: Error running context: An existing connection was forcibly closed
> by the remote host*
>
> When I delete the folder and give it another try, sometimes it will get
> through more documents, sometimes it gets through less, but it never
> actually finishes. I have tried using different internet connections, but
> get consistent errors.
>
> Very new to Subversion Edge and would really appreciate any feedback.
> Thanks,
> Cam
>
> NOTICE: This message {including attachments} is covered by the Electronic
> Communication Privacy Act, 18 U.S.C. sections 2510-2521, is CONFIDENTIAL
> and may also be protected by ATTORNEY-CLIENT OR OTHER PRIVILEGE. If you
> believe that it has been sent to you in error, do not read it. If you are
> not the intended recipient, you are hereby notified that any retention,
> dissemination, distribution, or copying of this communication is strictly
> prohibited. Please reply to the sender that you have received the message
> in error and then delete it.
>

Hello,

We've had various reports with this error message over the years. The cause
is usually a server side or network issue, but there doesn't seem to be a
common theme of one particular cause. Causes have ranged from anything from
antivirus software to network configurations to firewalls to old versions
of SVN on the server. If you search for the exact text of the error message
in our mailing list archives (see [1], you'll find  discussions and
(hopefully) what fixed it for different people. There's also the
StackOverflow question at [2].

You mentioned that you are using Subversion Edge. Do you know whether the
version of  Subversion Edge on the repository server is the latest
available?

>From your screenshot it appears you are using TortoiseSVN on the client
(your computer). What version of TortoiseSVN are you using?

Also do you know whether you're going through a proxy?

Is the repository server on the same LAN as your client computer, or across
a VPN, or...?

When you say it stalls, is there a noticeable delay? Approximately how long
(seconds? minutes?)

Cheers,
Nathan

[1] SVN mailing list archives:
https://subversion.apache.org/mailing-lists.html -- see under Archives for
users@

[2] StackOverflow question about this error:
https://stackoverflow.com/questions/22965847/svn-error-running-context-an-existing-connection-was-forcibly-closed-by-the-rem

Re: merging into a read only file succeeds

[Nathan Hartman]

On Thu, Feb 24, 2022 at 2:33 PM Mark Phippard  wrote:
>
> On Thu, Feb 24, 2022 at 10:51 AM Lorenz  wrote:
>
> > just discovered, that merging into a RO file succeeds.
> > I my case the file is RO because of a needs-lock property.
> > So when I try to commit I can't.
> >
> > This effect ist at least annoying.
> > There is a reason why the file is read only.
>
> It is interesting both that it was able to do this and also that this
> has never come up before. I am not sure I can wrap my head around what
> I think should even happen here. There is no way you could be expected
> to obtain locks on these files before merging. I guess ideally merge
> would obtain locks but I just do not know what merge should do if it
> cannot obtain the lock. I guess it should behave the same way it would
> if the file was not present due to it being a sparse working copy.

Hopefully there would be a visible warning if that happened!

> Maybe merge should just refuse to run at all if it detects any
> svn:needs-lock properties in the WC?

Then it would never be able to run; I think you meant: refuse to run
if we don't hold the lock on a file that has the svn:needs-lock
property. However, it would be rather irritating if the refusal to run
were caused by files unaffected by the merge. Whether that is more or
less annoying than merging to the read-only file is up to
interpretation.

> It is a hard problem to solve.

I suggest to file an issue for now.

Also, perhaps a workaround exists, or at least a way for users to
check whether they should obtain locks before running a merge,
preferably one that uses existing SVN commands. Some combination of
'svn merge --dry-run' and 'svn status -u', or something along those
lines?

Nathan

Re: Cygwin Subversion Packages Available

[Nathan Hartman]

On Tue, Jan 18, 2022 at 4:34 AM Brian Inglis
 wrote:
>
> You may wish to consider listing the Subversion packages available under
> Cygwin on your Apache Subversion Binary Packages web page at
>
> https://subversion.apache.org/packages.html

Done in r1897773 (merged to publish).

Cheers,
Nathan

Re: Cygwin Subversion Packages Available

[Nathan Hartman]

On Fri, Feb 4, 2022 at 10:24 AM Daniel Sahlberg
 wrote:
> One small thing, the command for 64-bit is 'setup-x86_64' while the command 
> for 32-bit is 'setup-x86.exe'. I think we should have it the same way for 
> both. Since the file extension is not need on Windows, I'd suggest remove 
> .exe from 32-bit.

Ah good catch! Fixed in 1897772.

Cheers,
Nathan

Re: Cygwin Subversion Packages Available

[Nathan Hartman]

On Fri, Jan 21, 2022 at 12:00 PM Brian Inglis
 wrote:
>
> [Please CC/Reply All as I am not subscribed]
>
> On 2022-01-21 08:04, Nathan Hartman wrote:
> > On Tue, Jan 18, 2022 at 1:10 PM Brian Inglis
> >  wrote:
> >> On 2022-01-18 09:00, Nathan Hartman wrote:
> >>> I think it makes sense to list it under the Windows heading to keep it
> >>> near the other Windows-based options.
>
> >> Curl lists it under but separate "Windows - Cygwin" which is similar to
> >> their Linux distro listings and is probably clearer:
> >>  https://curl.se/download.html
>
> > Ah, thanks for this!
> > What is the canonical way to install Subversion in the Cygwin
> > environment? I ask because our Binary Packages page at
> > https://subversion.apache.org/packages.html gives the command (e.g.,
> > apt-get, pkg_add, brew, etc.) to install SVN on various Unices, so I'd
> > like to do the same here.
>
>  From OP:
> "binary (also source) packages available for installation using the
> Cygwin Setup program available from cygwin.com".
>
> Cygwin offers users only a native Windows GUI executable Cygwin Setup
> program (built using Cygwin autotools and Mingw tools) available for
> x86_64 (and x86) arches downloadable from Cygwin [https://cygwin.com/]:
>
> "...
> Installing Cygwin
>
> Install Cygwin by running setup-x86_64.exe
> [https://cygwin.com/setup-x86_64.exe]
>
> Use the setup program to perform a fresh install or to update an
> existing installation. [https://cygwin.com/install.html];
> ...
> 32 bit Cygwin
> ...
> You have been warned. If you're still sure you really need a 32 bit
> Cygwin, and there's absolutely no way around it, you may run the
> setup-x86.exe installer. [https://cygwin.com/setup-x86_64.exe]
> The signature can be used to verify the validity of this binary.
> [https://cygwin.com/setup-x86_64.exe.sig];
>
> The Cygwin Setup program is manually downloaded (from home page via
> browser, curl, wget/2, etc.) wherever the user decides and also supports
> a command line interface which may involve GUI dialogs and windows
> appearing, depending on how many of the many options you provide e.g.
>
> -g, --upgrade-also   Upgrade installed packages also
> -n, --no-shortcuts   Disable creation of desktop and start shortcuts
> -P, --packages PKG,...   Specify packages to install
> -q, --quiet-mode Unattended setup mode
> -r, --no-replaceonreboot Disable replacing in-use files on next reboot
> -v, --verboseVerbose output
>
> : basic commands
>  > .../setup-x86_64 -gnqrv -P subversion,subversion-tools
> : X GUIs
>  > .../setup-x86_64 -gnqrv -P subversion-gnome,kdesvn
> : file import utilities
>  > .../setup-x86_64 -gnqrv -P svn-load,svn_load_dirs
> : repo conversion utilities
>  > .../setup-x86_64 -gnqrv -P git-svn,cvs2svn
> : language interpreter bindings
>  > .../setup-x86_64 -gnqrv -P subversion-perl,subversion-python,^
> subversion-ruby
> : Apache module
>  > .../setup-x86_64 -gnqrv -P subversion-httpd
> : developer/maintainer headers, import libraries, and debug info
>  > .../setup-x86_64 -gnqrv -P subversion-devel,subversion-debuginfo,^
> kdesvn-debuginfo

Added to our staging site:

https://subversion-staging.apache.org/packages.html#windows-cygwin

(Done in r1897742 and r1897743)

Feedback and corrections welcome!

Cheers,
Nathan

Re: Subversion environmental variables

[Nathan Hartman]

On Thu, Feb 3, 2022 at 1:31 PM Jeffrey Walton  wrote:
> I checked the man pages and could not find an answer... What
> environmental variables does a subversion client use?
>
> The problem I am trying to solve is, I am being prompted for a
> password in a script about 15 times. I want to know which variable to
> use for a password to avoid the prompts.

Hi Jeffrey,

Come to think of it, I don't think we have an exhaustive list of
environment variables that a Subversion client (or server, for that
matter) can use. That might be a useful thing to document. As far as I
know, there isn't an environment variable for providing credentials.

Regarding the password prompts for a scripted use case, there is an
ongoing and long discussion on our development list about this issue.
I assume you're on a Unix system (since you mentioned reading the man
pages). Whereas on Windows and macOS, Subversion always uses encrypted
credential caches (standard Windows API on Windows; Keychain on
macOS), the situation is more complicated on Linux/Un*x systems, which
do not have a single standardized solution for credential caching. So
on these systems, Subversion can be built with support for several
possible credential caches, including GNOME Keyring, KDE Kwallet,
GPG-Agent, or a plaintext cache. Due to security concerns, the
plaintext credential cache is disabled in the default build starting
with Subversion 1.12, unless enabled at compile-time. However, that
decision has made things more complicated for scripted/remote/headless
use cases, which we have been hearing about. We're trying to find a
solution that balances everyone's needs as well as possible.

Meanwhile, back to the immediate issue:

You can check which credential caches your SVN client was built with by running:

$ svn --version

and looking for "The following authentication credential caches are
available:" in the output.

KWallet and GNOME Keyring will probably prompt for a password once and
then cache it in memory, probably until some timeout elapses.

I looked into GPG Agent in the past and I think it is possible to make
it never prompt for a password interactively, but when I tried to set
this up to test it, I could not get it to work. Maybe others have more
input on this.

If you are in a trusted environment, you can pass --username and
--password arguments to svn on the command line; I say "trusted
environment" because this is not secure: the password becomes
viewable, e.g., in ps.

A slightly better solution could be to cache a plaintext password;
earlier I mentioned that the plaintext cache is disabled by default
since 1.12, but note that SVN clients will still use a cached
plaintext password if it is already saved. (They just won't cache new
passwords by that method.) There exists somewhere in our mail archives
a script for zsh (which I can try to find if you want it) to manually
cache a plaintext password, if you feel this is an acceptable
solution. (There might also be a python script; I don't remember.)

This FAQ entry (which is yet a work-in-progress) may offer something helpful:

https://subversion.apache.org/faq.html#plaintext-passwords

If the repository access is through svn+ssh, this FAQ might be helpful:

https://subversion.apache.org/faq.html#plaintext-passwords

Perhaps other users will chime in with ideas. It might be helpful if
you can tell us the SVN client version, OS on which you're using it,
and the method by which the repository is accessed (http, https, svn,
svn+ssh, file, etc).

Hope this helps...

Nathan

Re: Cygwin Subversion Packages Available

[Nathan Hartman]

On Tue, Jan 18, 2022 at 1:10 PM Brian Inglis
 wrote:
> On 2022-01-18 09:00, Nathan Hartman wrote:
> > I think it makes sense to list it under the Windows heading to keep it
> > near the other Windows-based options.
>
> [Please CC/Reply All as I am not subscribed: forgot to mention that!]
>
> Curl lists it under but separate "Windows - Cygwin" which is similar to
> their Linux distro listings and is probably clearer:
>
> https://curl.se/download.html

Ah, thanks for this!

What is the canonical way to install Subversion in the Cygwin
environment? I ask because our Binary Packages page at
https://subversion.apache.org/packages.html gives the command (e.g.,
apt-get, pkg_add, brew, etc.) to install SVN on various Unices, so I'd
like to do the same here.

Thanks,
Nathan

Re: Cygwin Subversion Packages Available

[Nathan Hartman]

On Tue, Jan 18, 2022 at 4:50 AM Daniel Sahlberg
 wrote:
>
> Hi Brian,
>
> Thanks for your request. This sounds reasonable to me.
>
> One question to consider is if this should be under the Windows headline 
> (which is reasonable since it is running under Windows) or a separate 
> headline. In some ways Cygwin behaves more like a virtual machine running 
> Linux (directory structure, line-endings) than a normal Windows application.
>
> I'm out of time for the moment but I'll circle back to the mail in next week 
> unless someone has a different opinion.
>
> Kind regards,
> Daniel Sahlberg
>
> Den tis 18 jan. 2022 kl 10:34 skrev Brian Inglis 
> :
>>
>> You may wish to consider listing the Subversion packages available under
>> Cygwin on your Apache Subversion Binary Packages web page at
>>
>> https://subversion.apache.org/packages.html


I think it makes sense to list it under the Windows heading to keep it
near the other Windows-based options.

Cheers,
Nathan

Re: FW: SVN error

[Nathan Hartman]

On Wed, Jan 12, 2022 at 10:45 AM Gavli, Gangaram 
wrote:

> Thank you.
>
>
>
> We tried upgrading Client to 1.14 but still same issue.
>


The issue you are experiencing appears to be server side.

There are, of course, many variables involved in any client/server
software, and so it is possible that the issue could be caused by any
number of other components.

A google search for the error message brings up this Stack Overflow
question as the first result:

https://stackoverflow.com/questions/22965847/svn-error-running-context-an-existing-connection-was-forcibly-closed-by-the-rem

If you look through those answers, there doesn't seem to be a common theme
as to the cause or fix.

The bottom line is that we can't say with certainty what is causing this
issue, but we do know that the 1.6 version running on your server is quite
old and many, many bugs have been fixed, not to mention security issues, in
subsequent releases, and I doubt if anyone could offer any meaningful help
for such an old version. Therefore, it might be that the best path forward
is to consider upgrading the server to Subversion 1.14.1. That might fix
the problem, but whether it does or not, it will eliminate
old already-fixed bugs and security issues.

It does not escape me that upgrading the server could be a non-trivial
undertaking. You might, for example, consider setting up an entirely new
server in parallel and making a clean switchover to minimize service
interruption.

Hope this helps,
Nathan

Re: FW: SVN error

[Nathan Hartman]

On Tue, Jan 11, 2022 at 11:52 PM Gavli, Gangaram 
wrote:

> File size is in not more than 20 mb
>
> I also suggest to look into updating SVN on the server to a newer version.
> Currently 1.10 and 1.14 are supported. As compared to 1.6, which was
> released in 2009 and last updated in 2013, these newer releases contain
> many, many bug fixes, including security fixes.
>
> We Are currently using 1.6 what is the latest version now?
>


The latest release currently is 1.14.1.

Release notes for this release as well as all prior ones are available here:

https://subversion.apache.org/docs/release-notes/#release-notes

Nathan

Re: FW: SVN error

[Nathan Hartman]

On Tue, Jan 11, 2022 at 1:24 PM Gavli, Gangaram 
wrote:

> I need help on below mentioned error attached is httpd.conf file.
>
>
>
>
>
>- What TortoiseSVN version do you use to reproduce the error? 1.14
>- What VisualSVN Server version do you use? svn, version 1.6.11
>(r934486)
>- What OS version do you use? Linux
>
>
>-
>- Is there any third-party antivirus on your server and clients? Trend
>Micro
>- Do you use VPN to connect to the server? Do you use any proxy or
>active firewall services? Yes Sophos VPN
>
>
Could be a timeout problem. Is the file being sent (in "Sending content"
above the Error lines) very large?

I also suggest to look into updating SVN on the server to a newer version.
Currently 1.10 and 1.14 are supported. As compared to 1.6, which was
released in 2009 and last updated in 2013, these newer releases contain
many, many bug fixes, including security fixes.

Nathan

Re: Compression Question

[Nathan Hartman]

On Mon, Dec 13, 2021 at 2:31 PM Luke Mauldin  wrote:
>
> From reading the documentation, I can see that Subversion 1.14 supports both 
> zlib and lz4 compression.  I am running Subversion on FreeBSD 13.X on ZFS 
> which supports native zstd compression.  Some of the repos I host are 
> relatively large (60K revisions and 60GB+) and I am wondering what 
> combination will give me the best performance?  Currently, I have Subversion 
> compression disabled and ZFS with zstd compression enabled.  In this setup, 
> ZFS reports a compression ratio of 1.69X.  I would think if Subversion 
> natively supported ZSTD compression that would be best but since it does not, 
> I just wanted to see if anyone had recommendations?


As I understand it, the motivation for adding LZ4 compression (added
in 1.10) was speed. From vague memory (I haven't looked into
compression algorithms recently), I think zlib achieves a better
compression ratio in terms of disk space saved, but LZ4 is faster. I
haven't had experience with zstd yet.

It is difficult to say which compression format would give the "best"
performance for a particular application without some experimentation
because things like hardware I/O speeds and the nature of the data
being compressed affect the outcome.

Are you looking for the best speed, the best compression ratio, a good
tradeoff between the two?

If you want to conserve disk space, I would suggest (if it's feasible
and on a separate machine, not in production), to produce a dumpfile
and load it twice, once with zlib and once with LZ4, and then compare
the resulting on-disk sizes to that of the volumes on zstd. Note
Subversion's data deduplication feature: if this was turned off in the
past or is off now, some or all of your repo might contain duplicated
data; to make the experiment "fair" you would need to take this into
account.

If you are looking for best performance in terms of speed, I don't
have a simple answer for this because it depends on a great many
variables in which Subversion's compression is but one. I would assume
that networking I/O probably plays a bigger role than compression
here.

Hope this helps,
Nathan

Re: ASF Subversion version

[Nathan Hartman]

On Mon, Dec 13, 2021 at 10:37 AM Stefan Sperling  wrote:
>
> On Mon, Dec 13, 2021 at 07:14:46AM -0600, Luke Mauldin wrote:
> > It looks like the stashing functionality is still experimental. Do you 
> > think there will be more funding in the future to complete it or do you 
> > think it may remain unfinished for a long period of time?
> >
>
> I do not know any specifics about the funding arragements that were
> made for the staging feature. What I do know is what anyone can tell
> from public records such as our mailing list archives and in our commit
> history. Julian, like many others, is working in other jobs nowadays and
> has not actively contributed much to SVN during the last year or so.
>
> I suspect there are still some developers who would be open to the idea
> of returning to continue working on in-progress features if they could
> put food on the table in return. A simple fact is that any altruism
> these people have spent over years in order to provide this tool to
> communities and companies has largely run dry by now. While SVN grew
> up because many of its developers were on paid time since 2000, many
> were also willing to invest some of their free time to help out because
> this was a fun and challenging project to work on.
>
> But not many can afford to do such work in their free time forever, given
> the complexity of the subject matter, the expectations of quality that
> need to be met, and the fact that most users are now businesses which
> simply use SVN because it does not cost them a cent compared to similar
> proprietary offerings which are usually very expensive. I know this
> because over the course of about a decade I have helped many such
> companies move over to SVN from such platforms, and SVN works so well
> for many of them that most do not even see a need for a paid support
> contract to get help in case things go wrong. I have seen people in
> companies who wanted to pitch such things to their bosses but found
> themselves in a difficult spot when trying to justify a budget for
> SVN tooling ("wait, did we not just got rid of ClearCase in order
> to save such costs...?")
>
> And naturally, the longer people have moved on with their lives,
> the less interest they will have in returning to past projects.


That leaves us as a community-driven project, and while I agree that
the codebase is complex and quality matters (hey, we all keep crucial
information in this thing!) that should not be a deterrent to anyone
interested in getting involved.

We have a gigantic pool of users worldwide who depend on Subversion
and for whom other software isn't the right fit, and we need help with
many different skill areas besides coding, including translations,
documentation, testing, improving the website, bug triaging, etc.,
etc. Every little bit of help from each person counts and benefits
everyone, and if each person did just a little bit, it would make a
huge difference. It's like everyone putting a flower pot on their
windowsill. Soon the whole city looks nicer.

Cheers,
Nathan

Re: Compare revisions on different devices, why different?

[Nathan Hartman]

On Fri, Dec 10, 2021 at 10:13 AM Bo Berglund  wrote:
>
> I have several devices on which I have checked out the same project.
> One is connected to a debugging external system and the others are not.
> Now I have been working on the debugging system and committed my changes from
> that.
> Then I have updated the project on the non-debug system expecting to get the
> same code on both.
> But this is what svn info gets me:
>
> Debug system where I just committed:
> 
> $ svn info
> Path: .
> Working Copy Root Path: /home/pi/projects/SSRemoteServer
> URL: https://mysvnserver/svn/pc/SSRemoteServer/trunk/source
> Relative URL: ^/SSRemoteServer/trunk/source
> Repository Root: https://mysvnserver/svn/pc
> Repository UUID: 1e489663-c639-2248-90da-e976bc628839
> Revision: 4470
> Node Kind: directory
> Schedule: normal
> Last Changed Author: bosse
> Last Changed Rev: 4470
> Last Changed Date: 2021-09-23 02:55:51 -0500 (Thu, 23 Sep 2021)
>
> Code writing system where I just updated:
> -
> $ svn info
> Path: .
> Working Copy Root Path: /home/pi/projects/SSRemoteServer
> URL: https://mysvnserver/svn/pc/SSRemoteServer/trunk/source
> Relative URL: ^/SSRemoteServer/trunk/source
> Repository Root: https://mysvnserver/svn/pc
> Repository UUID: 1e489663-c639-2248-90da-e976bc628839
> Revision: 4474
> Node Kind: directory
> Schedule: normal
> Last Changed Author: bosse
> Last Changed Rev: 4474
> Last Changed Date: 2021-12-10 14:13:39 +0100 (Fri, 10 Dec 2021)
>
> I note that these items differ:
> ---
> Revision: 4470 vs 4474
> Last Changed Rev: 4470 vs 4474
> Last Changed Date: 2021-09-23 vs 2021-12-10
>
> Why are they not at the samerevision and date?
>
>
> --
> Bo Berglund
> Developer in Sweden
>


On the debug system, immediately after committing,  did you do 'svn update'?

Nathan

Re: Can't create temporary file from template ... No such file or directory

[Nathan Hartman]

On Thu, Dec 2, 2021 at 3:29 PM Rolf Campbell  wrote:
>
> Hello Nathan,
>
> Thank you for the reply.
>
> I assure you that it was not related to disk space.  I tried it on 3 
> different computers using 2 different versions of SVN.
>
> I tried to create a reproduction script and instead I caused the svn client 
> to crash.
>
> Here is my script:
>
> svnadmin create test
> svn checkout file://$PWD/test test.1
> cd test.1
> svn mkdir ^/trunk -m ""
> svn mkdir ^/branches -m ""
> touch a
> svn add a
> svn commit -m ""
> svn cp ^/trunk ^/branches/b -m ""
> svn mkdir ^/trunk/c -m ""
> svn mkdir ^/trunk/c/d -m ""
> svn mkdir ^/branches/b/c -m ""
> svn mkdir ^/branches/b/c/e -m ""
> cd ..
> svn co file://$PWD/test/branches/b
> cd b
> svn merge ^/trunk .
>
> And here is the output when I try it (multiple times):
> --- Merging r4 through r8 into '.':
>C c
>A c/d
> --- Recording mergeinfo for merge of r4 through r8 into '.':
>  U   .
> Summary of conflicts:
>   Tree conflicts: 1
> Searching tree conflict details for 'c' in repository:
> Checking r5... done
> Tree conflict on 'c':
> A new directory appeared during merge of
> '^/trunk/c:4-8'.
> It was added by rcampbell in r5.
> A directory which already occupies this path was found in the working copy.
> Select: (p) Postpone, (r) Mark as resolved, (i) Ignore incoming addition,
> (m) Merge the directories,
> (R) Delete my directory and replace it with incoming directory,
> (M) Replace and merge, (h) Help, (q) Quit resolution: m
> svn: E235000: In file 'subversion/libsvn_wc/adm_ops.c' line 384: assertion 
> failed (!copyfrom_url || (svn_uri_is_canonical(copyfrom_url, scratch_pool) && 
> SVN_IS_VALID_REVNUM(copyfrom_rev)))
> Aborted (core dumped)

Thank you for this reproduction script. This is extremely helpful! I
can confirm this reproduces the above error for me exactly. I tested
with 1.10.6, 1.14.1, and an unreleased build of trunk. In all three,
the assertion failure occurs on the same line 384. I'll try to figure
out where the code is taking a wrong turn. In the meantime, if you do
succeed in reproducing the original issue, please do let us know!

Thanks,
Nathan

Re: Can't create temporary file from template ... No such file or directory

[Nathan Hartman]

On Wed, Dec 1, 2021 at 7:31 PM Rolf Campbell  wrote:
>
> I'm an svn administrator for my company and I end up doing a lot of merges.
>
> Today, I ran into this failure (reproducable).
>
> svn: warning: W02: Can't create temporary file from template 
> '/opt/sbox/rcampbell/auto-merge/solcbr/dataplane/sw/assuredDelivery/messageSpool/defrag/svn-XX':
>  No such file or directory
> svn: E155027: Failure occurred resolving one or more conflicts
>
> This happens after I run two commands:
>
> svn merge ^/trunk@184967 ^/trunk@185348 .  --accept postpone
>
> and then
>
> svn resolve solcbr/dataplane/sw/assuredDelivery/messageSpool
>
> and then it gives me output:
>
> $ svn resolve solcbr/dataplane/sw/assuredDelivery/messageSpool
> Searching tree conflict details for 
> 'solcbr/dataplane/sw/assuredDelivery/messageSpool' in repository:
> Checking r184967... done
> Tree conflict on 'solcbr/dataplane/sw/assuredDelivery/messageSpool':
> A new directory appeared during merge of
> '^/trunk/solcbr/dataplane/sw/assuredDelivery/messageSpool:184968-185348'.
> It was added by solbuild in r184967.
> A directory which already occupies this path was found in the working copy.
> Select: (p) Postpone, (r) Mark as resolved, (i) Ignore incoming addition,
> (m) Merge the directories,
> (R) Delete my directory and replace it with incoming directory,
> (M) Replace and merge, (h) Help, (q) Quit resolution: m
> Csolcbr/dataplane/sw/assuredDelivery/messageSpool/Rules.mk
> svn: warning: W02: Can't create temporary file from template 
> '/opt/sbox/rcampbell/auto-merge/solcbr/dataplane/sw/assuredDelivery/messageSpool/defrag/svn-XX':
>  No such file or directory
> svn: E155027: Failure occurred resolving one or more conflicts
>
>
> $ svn --version
> svn, version 1.14.1 (r1886195)
>compiled Oct  1 2021, 11:42:52 on x86_64-unknown-linux-gnu
>
> The directory 
> "/opt/sbox/rcampbell/auto-merge/solcbr/dataplane/sw/assuredDelivery/messageSpool/defrag"
>  does not exist because it is a subdirectory that was added in trunk but NOT 
> added in the working branch.
>
> We have already managed to get this merge to complete by renaming the 
> directories so they don't collide, but this happens to us more than you might 
> imagine and it would be nice if someone could take a look at this.  Am I 
> doing something wrong or is this a bug in subversion?

Hi Rolf,

The first thing to find out is whether there is a bug in Subversion or
the cause is elsewhere.

The best way to track down the cause is with a reproduction script
that constructs a minimal repository that exposes the issue. Without
that, it is very difficult to know the cause. A reproduction script
would allow us to run the same steps on different machines with
different builds and versions of Subversion; if there is a bug, that
will help fix it and translated into a regression test to prevent it
from returning in the future.

For now, we can try to narrow it down:

When you say that this happens often, do you mean failure to create
temporary files? Has that started recently (e.g., with this install of
SVN 1.14.1)? Temporary file creation is done by APR. What version of
APR is used in this build? The output of 'svn --version --verbose'
gives the version of APR. What OS is used?

A potentially dumb question, but is it possible the volume where the
working copy is located is low of space?

If this happens again, could you try to run the same merge + resolve
(or whatever steps cause the issue to resurface) on a different
machine to see if the same failure occurs?

Thanks,
Nathan

Re: Subversion 1.14.1 build problem

[Nathan Hartman]

On Tue, Nov 30, 2021 at 10:33 AM Nathan Hartman
 wrote:
> I can confirm:
>
> Building 1.14.1:
> - with sqlite-amalgamation 3.36 fails with ld error: undefined
> reference to `unixFcntlExternalReader'.
> - with sqlite-amalgamation 3.37 succeeds.

I've documented it in the 1.14 release notes in case others run into
it in the future:

https://subversion.apache.org/docs/release-notes/1.14.html#issues-other-sqlite-3-36

It also affects 1.13 but that release is EOL.

Cheers,
Nathan

Re: Subversion 1.14.1 build problem

[Nathan Hartman]

On Mon, Nov 29, 2021 at 10:19 AM Daniel Sahlberg
 wrote:
>
> Den tis 2 nov. 2021 kl 09:33 skrev Daniel Sahlberg 
> :
>>
>> Den mån 1 nov. 2021 kl 09:32 skrev Gretton, Liam 
>> :
(snip)
>> > .libs/sqlite3wrapper.o: In function `unixFileControl':
>> >
>> > /home/liam/downloads/subversion-1.14.1/sqlite-amalgamation/sqlite3.c:38131:
>> >  undefined reference to `unixFcntlExternalReader'
>> >
>> > /usr/bin/ld: .libs/sqlite3wrapper.o: relocation R_X86_64_PC32 against 
>> > undefined symbol `unixFcntlExternalReader' can not be used when making a 
>> > shared object; recompile with -fPIC
(snip)
>> As far as I can tell this is a bug in SQLite. The offending function
>> was added 2021-04-02 [1] and it seems to be hidden by #ifdef
>> SQLITE_OMIT_WAL. There is a reference to the same error in the SQLite
>> forums [2] with a suggestion to leave out SQLITE_OMIT_WAL on
>> compilation.
(snip)
> SQLite 3.37.0 was relased today.
>
> According to a post in the SQLite forums [1], a fix was committed 2021-11-02. 
> When checking the source of 3.37.0 it seems to be included but I'm out of 
> time to verify. Maybe you can try a new build?
>
> Kind regards,
> Daniel
>
>
> [1] 
> https://sqlite.org/forum/forumpost/8066af6dcd79e78490694a324ed655fe6b6588bf5f02db09becb60ea233e5b1a

I can confirm:

Building 1.14.1:
- with sqlite-amalgamation 3.36 fails with ld error: undefined
reference to `unixFcntlExternalReader'.
- with sqlite-amalgamation 3.37 succeeds.

$ ./svn  --version --verbose
svn, version 1.14.1 (r1886195)
   compiled Nov 30 2021, 10:24:06 on x86_64-unknown-linux-gnu

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

The following repository access (RA) modules are available:

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

The following authentication credential caches are available:

* Gnome Keyring
* GPG-Agent

System information:

* running on x86_64-unknown-linux-gnu
  - Debian GNU/Linux 10 (buster) (buster) [Linux 4.19.0-18-rt-amd64]
* linked dependencies:
  - APR 1.6.5 (compiled with 1.6.5)
  - APR-Util 1.6.1 (compiled with 1.6.1)
  - Expat 2.2.6 (compiled with 2.2.6)
  - SQLite 3.37.0 (static)
  - Utf8proc 2.3.0 (compiled with 2.3.0)
  - ZLib 1.2.11 (compiled with 1.2.11)
  - LZ4 1.8.3 (compiled with 1.8.3)
* loaded shared libraries:
  - /lib/x86_64-linux-gnu/libz.so.1.2.11

Cheers,
Nathan

Re: Full text search

[Nathan Hartman]

On Mon, Nov 29, 2021 at 10:10 AM Luke Mauldin 
wrote:

> Is there a recommended way to do a full text search of commits that
> include changed text. For example if I wanted “svn log” to show me all of
> that commits that have an added or deleted line that contains “foo”, is
> that possible? Git has similar functionality in “git log -S foo”
> Using “svn diff -r:HEAD | grep foo” gets me close but that just gives me
> the lines that changed and not the commit that they changed.


'svn log' has a --diff option. Together with a revision range, that will
output commit log together with the changes in that commit (though be aware
if server access is slow and you request a large range it could be slow).

Perhaps 'svn blame' will be helpful in addition or instead?

Nathan

Re: A project I've been working on

[Nathan Hartman]

On Mon, Nov 15, 2021 at 9:48 AM Daniel Sahlberg
 wrote:
>
> Den mån 15 nov. 2021 kl 15:41 skrev Justin MASSIOT | Zentek
> :
> >
> > Hi Robert,
> >
> > Interesting initiative.
> > What is the "two copies of everything in a checkout" problem you are 
> > talking about?
>
> I would have presumed it is the "pristine" files. A solution was
> proposed and implemented in this thread in dev@
>
> http://mail-archives.apache.org/mod_mbox/subversion-dev/202107.mbox/%3C874kcf6xin.fsf%40red-bean.com%3E

This implementation is in the 'pristines-on-demand' branch.

More below...

> > On Sat, 13 Nov 2021 at 01:54, Robert Hickman 
> >  wrote:
> >> I've been working on a 'subversion replacement' for the last 5 ish
> >> years called 'simple http file sync' (shttpfs), a centralized version
> >> control system for binary files.
> >>
> >> SHTTPFS was created to manage changes to a lot of binary image and
> >> video files across multiple computers. The nature of my own data is it
> >> is primarily added to and very rarely changed. i.e. video is edited
> >> 'non destructively', and a new video is rendered. I created shttpfs to
> >> solve subversion's 'two copies of everything in a checkout' problem,
> >> which was causing data bloat to an extent that made it completely
> >> unusable. Nothing else worked reliably, or had the required features
> >> (simple design, atomic commits, arbitrary partial checkouts, good
> >> command line interface, stores version history on a central server).
> >>
> >> https://github.com/robehickman/simple-http-file-sync

Thanks for sharing. I know you began this work long before the
'pristines-on-demand' branch existed and even before the mail list
thread discussing it, but I'd very much like to know your thoughts on
it.

Cheers,
Nathan

Re: svn binary packages for macOS

[Nathan Hartman]

On Mon, Nov 8, 2021 at 1:42 PM Daniel Sahlberg
 wrote:
> There has been some discussion but I don't think there was an actual
> decision taken. So I'm throwing in a suggestion to add the following
> text to packages.html (just below the regarding "larger collections of
> software", and before the Centos Linux header):
>
> A condition to be listed is to provide "reasonably new" versions.
>This should be interpreted as the latest patch release of any of the
>supported versions (at the time of writing: either of 1.10.6 or 1.14.1).
>The rule will be implemented with a fair amount of flexibility to
>allow time to release new packages, as well as any considerations
>regarding the release process. Please discuss at the href="mailto:users@subversion.apache.org;>Subversion users mailing
>list.
>
> I believe it is reasonable to accept someone distributing only 1.10.6
> since there may be acceptable reasons not to distribute 1.14.1 (for
> example dependencies that are not possible to build on a certain
> platform).
>
> I added the "considerations regarding the release process" as a way to
> ignore Linux distributions since they might ship what was current at
> the time of their release and backport any important security fixes.

It could be included directly in the text itself. For example:

A condition to be listed is to keep current with security fixes by
   offering the latest supported patch release or by backporting
   security patches. The rule will be implemented with a fair amount
   of flexibility...

Cheers,
Nathan

Re: Svnadmin verify question

[Nathan Hartman]

On Tue, Nov 2, 2021 at 5:09 PM Luke Mauldin  wrote:
>
> Can anyone tell me the details of the svnadmin verify command?  Does 
> subversion store any internal hash of each commit to verify its correctness 
> and that it has not changed over time due to disk/memory errors or software 
> bugs?
>
> Luke Mauldin

Yes. The purpose of 'svnadmin verify' is to check for exactly those
kinds of errors.

By default it runs through each revision one-by-one and stops/reports
if it finds a problem. There's also a --keep-going option since SVN
1.9.

It is a good idea to run 'svnadmin verify' periodically on
repositories to ensure their integrity.

It is also crucial to have a good backup process in place, i.e., keep
multiple good up-to-date backups of repositories in different physical
locations and make sure you can restore from them before disaster
strikes. Obviously it's of no use to detect corruption if you don't
have backups to restore from.

Hope this helps,
Nathan

Re: Current project status

[Nathan Hartman]

On Thu, Oct 28, 2021 at 3:47 AM Justin MASSIOT | Zentek
 wrote:
>
> Luke,
>
> If the 3D models are "source" files, then I personally approve to put those 
> files into a Subversion repo. That's what I do everyday with Electronic 
> engineering CAD files.
> By the way, don't forget you may not be able to "diff" between two versions 
> of a file. If not, you lose one the main strength of a Version control 
> system: doing even a small rollback may become a pain... Plus if you can't 
> diff, you probably can't merge either! I encourage you to use locks to avoid 
> any form of conflicts. The "needs-lock" property can be useful.
>
> As for the project status, I don't know anything but I would be curious to 
> get the developers' point of view.


This sounds similar to our use case at $dayjob, where we have been
using SVN since 2007 to house various types of assets, not just
source code.

Yes, you can't diff and merge binary assets, but that would be true
whether you use a version control system or not. But you do benefit
from having older versions in case you need more than the "undo" of
whatever application creates those files, and you have a log of who
committed each file and when. If you can get your users to write
*helpful* log messages, that's even better.

Before we adopted SVN, we actually first looked at Git because it
seemed very popular even in those early days, but ultimately we
decided on SVN because it is much more suitable for us, partly
because non-software-developer users are able to understand it and
partly because it's better at housing non-source-code assets, like
CAD, EDA, artwork, documents, etc. Distributed systems like Git rely
upon being able to fork and merge, which you can't do with non-
source-code assets.

Regarding the project's viability going forward, my point of view is
that like all open source projects, it ultimately depends upon
whether those who benefit from it are willing to give back in some
way; not necessarily financially, but rather in terms of helping in
any way that one is willing and able to, whether it's documentation,
fixing bugs, developing features, testing, or whatever. I'm here
because Subversion is important to me both professionally and
personally.

Also, you do have access to the full source code, so your data isn't
being held in someone's undocumented silo. This was the biggest
reason why at my $dayjob the first requirement any version control
system had to meet before we would adopt it was to be open source.

That's my 2 cents... Hope that helps!
Nathan

Re: svn binary packages for macOS

[Nathan Hartman]

On Mon, Oct 18, 2021 at 2:55 AM Daniel Sahlberg
 wrote:
>> Would it make sense to give them a heads up before removing the links in 
>> case they would like to release newer packages and remain on the list?
>
>
> Yes, if we have any contact channels (I'm not sure about sending to an 
> anonymous info address) and as long as it doesn't violate ASF vendor 
> neutrality. It is about caring for the ecosystem. Nathan, can you do this 
> with the PMC chair hat?


Apologies for the delayed reply...

I'm also not too sure about sending to an anonymous info address. If
someone knows who is the proper contact, I'll be happy to send a
message.

Cheers,
Nathan

Re: Subversion 1.14.1 and serf 1.3.9

[Nathan Hartman]

On Thu, Oct 21, 2021 at 8:06 AM Johan Corveleyn  wrote:



> > Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski 
> > :
> >> Very strange problem with assembly code in zlib 1.2.11.



> Indeed, zlib's assembly code seems to be unreliable on Windows. When I
> build / test (for signing new releases) on Windows, I never use the
> assembly build of zlib anymore (ever since I ran into problems with it
> years ago).

I thought we had that documented somewhere but I can't seem to find it
now. I remember reading a recommendation not to use the assembly build
of zlib because of various issues. It may have been in the mailing
list archives.

Compilers these days have gotten so good that I think it's a waste of
time to write hand-coded assembly unless there's a very specific and
very special use case requiring exact control over something. Data
structure and algorithm design make a far bigger impact than trying to
save a few cycles. :-)

Hope you get better results now!

Cheers,
Nathan

Re: svn binary packages for macOS

[Nathan Hartman]

On Sun, Oct 17, 2021 at 12:38 PM Mark Phippard  wrote:

> On Sun, Oct 17, 2021 at 11:01 AM Nathan Hartman
>  wrote:
> >
> > On Sat, Oct 16, 2021 at 9:25 AM Mark Phippard 
> wrote:
> > >
> > > In terms of the policy, I think it should be that our latest LTS
> > > release must be available. If they have other packages available that
> > > is fine but the latest LTS must be one of them. In terms of the types
> > > of exceptions I could envision, perhaps we will discover it is really
> > > difficult to package the latest LTS for certain older distros and so
> > > they need to provide an older version. I would be OK with an exception
> > > like this but I would prefer to have the packagers raise it to us.
> > >
> > > Mark
> >
> >
> > I'm not opposed to this, but it might be a little tricky for OS
> > distros that freeze package versions. Debian for example. I haven't
> > checked what the current stable (bullseye) has, but I'm still on the
> > oldstable (buster) which supplies 1.10.x. I'm running a recent trunk
> > build though, heh heh :-)
> >
> > I'm not proposing an exception (and I'm not a packager); rather I'm
> > suggesting to consider a package compliant as long as it was a
> > supported LTS release at the time of the packager's version freeze
> > and security issues continue to be patched.
>
> My feeling is that our policy should focus on the situation where we
> are linking to an external website where the user downloads some
> package from them. For the Linux/BSD distros, and even Homebrew and
> MacPorts on MacOS, we are just telling the user that these package
> managers offer Subversion and maybe we list the commands to run in
> order to install the package. I do not think we need to police the
> version as heavily in this case. Especially with the Linux distros
> since they selectively backport patches so their version never
> perfectly matches ours and the distro provides support for their
> packages.


+1

That said, the only problematic links on our current page are the ones
> from CollabNet and WanDisco. I have not verified WanDisco I am just
> taking the word of the people in this thread. Given that both of these
> were vendors trying to sell support and requiring registration to even
> get the download, I think we should just remove all of those links. If
> either of them ask to be put back we can tell them the requirement is
> that they offer the latest LTS version.


Would it make sense to give them a heads up before removing the links in
case they would like to release newer packages and remain on the list?

Cheers,
Nathan

Re: svn binary packages for macOS

[Nathan Hartman]

On Sat, Oct 16, 2021 at 9:25 AM Mark Phippard  wrote:
>
> In terms of the policy, I think it should be that our latest LTS
> release must be available. If they have other packages available that
> is fine but the latest LTS must be one of them. In terms of the types
> of exceptions I could envision, perhaps we will discover it is really
> difficult to package the latest LTS for certain older distros and so
> they need to provide an older version. I would be OK with an exception
> like this but I would prefer to have the packagers raise it to us.
>
> Mark


I'm not opposed to this, but it might be a little tricky for OS
distros that freeze package versions. Debian for example. I haven't
checked what the current stable (bullseye) has, but I'm still on the
oldstable (buster) which supplies 1.10.x. I'm running a recent trunk
build though, heh heh :-)

I'm not proposing an exception (and I'm not a packager); rather I'm
suggesting to consider a package compliant as long as it was a
supported LTS release at the time of the packager's version freeze
and security issues continue to be patched.

Thoughts?

Nathan

Re: svn binary packages for macOS

[Nathan Hartman]

On Mon, Oct 4, 2021 at 11:44 AM Mark Phippard  wrote:
>
> On Mon, Oct 4, 2021 at 11:24 AM Daniel Sahlberg
>  wrote:
>
> > If "only providing outdated versions" is a reason for de-listing then sadly 
> > both CollabNet and WANdisco should go (at least when 1.10 is EOL). I can 
> > edit the website but I'd appreciate if anyone else in PMC would give their 
> > opinion on policy.
>
> My recommendation is we discuss and create a policy, add it to the
> page and then we can enforce it. I would expect the policy would be
> related to providing our LTS version and the only question is whether
> we want to require the latest LTS version be made available or just
> that one of our still supported LTS versions is available. Perhaps the
> latter could be an exception if there is some OS that cannot support a
> newer LTS for some reason.

Some websites have a link to "older releases" which are listed on a
separate page. Instead of removing mention of binaries, we could move
them to a separate page (called "older 3rd party binaries" rather than
"older releases" since they're not our binaries). That page could have
a prominent note about the disadvantages of running older unsupported
releases, but leave the choice in the user's hands. Thoughts?

Cheers,
Nathan

Re: svn update issue?

[Nathan Hartman]

On Fri, Sep 10, 2021 at 4:45 AM Mikael Stålhammar <
mikael_stalham...@hotmail.com> wrote:

> I'm wondering if the behavior of "svn update" is correct in this below
> case:
>
> I have a file in my local working copy containing a change on one line in
> the file.
> Meanwhile the file is modified and committed by someone else, with a
> change to another line in that file.
> It turns out that that change made by the other person was wrong, so I
> want to stick with the contents of the file I have, so I do a:
>
> svn update  --accept mf
>


This would have an effect only if SVN detects conflicts it can't resolve
automatically when merging the repository's changes with your working
copy's changes. For example, that would happen if your colleague and you
both changed the same lines of the file (with non-identical changes).

In your case it sounds like there was no conflict as two different parts of
the file were edited.

One way to achieve what you want is to reverse cherry pick merge the bad
commit. (If it contains other changes you do want to keep, you can
selectively revert them using your favorite diff tool.)

See:
https://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo

Depending on the situation and whether your colleague's changes and yours
are related or not, it might be better to commit the "revert" commit
separately from your other changes so that it will be clear why it's being
reverted and can be explained in the log. You could do that either before
or after committing your own changes, or just in one combined commit,
depending on what is best in your circumstances.


(i.e. mf=mine-full)
> to mark my version as being merged with HEAD, but keeping my source as it
> is. However, what really happens is that the changes from that other
> revision still gets merged into my local source, while I expected the
> contents of my version to remain unchanged.
>


Note that your colleague's committed changes will not show up in a 'svn
diff' now since you are comparing your working copy with what's in the
repository (at the time of 'svn update') but reverse cherry picking that
commit will make those lines as they were before, and will make them show
up in the diff as changed.

Hope this helps,
Nathan

Re: Please help to repair SVN repository.

[Nathan Hartman]

On Mon, Aug 30, 2021 at 11:15 AM Yakov Erlich  wrote:

> Hi,
>
> Please help to repair SVN repository.
>
>
>
> I use TortoiseSVN (1.14.1) and VisualSVN Server 4.3.4.
>


Were you upgrading a repository from an older SVN version? If so, which
version?

If not for an upgrade, what prompted to fix the repository?

More below...



> I try to repair "Altera" repository.
>
> Its size is 106 GB with 1844 revisions.
>
>
>
> Attached files
>
> - log-verifivation.txt keeps list of all bad revisions (17)
>
>
>
> - repo_dump_script.sh dumps Altera repository to several dump files,
>
>except the bad ones (found in log-verifivation.txt).
>


Note that later revisions may be based on data in earlier revisions; e.g.,
r752 may contain a diff against data in r730. Therefore it could be that,
say, a single bit error in the storage of r730 leads to all the other bad
revisions.

Is it possible there was a disk corruption? If so, do you have an older
backed up dump that includes r730 that could be used to load up to (and
including) that portion of the repository? (Alternately do you have an
older copy of the repository in backups, e.g., made with 'svnadmin hotcopy'
or similar?)



>  - repo_load_script.sh loads the dump files into new "AlteraFix"
>
>repository (see its log in).
>
>
>
>  -  log-repo_load.zip of log-repo_load.txt (44 MB) keeps output of load
> process (repo_load_script.sh)
>
>
>
> Note:
>
> All 'svnadmin' commands and scripts I ran in "Bash"
> command-line window,
>
> under Windows 10. The Bash window executes Linux commands.
>
> The Bash window I can open after installing GIT on my PC.
>
>
>
> Problem:
>
> All the dump and load finished without errors (IMHO), but there are
> following
>
> problems:
>
> - Resulting repository AlteraFix has 45 GB size in opposite to Altera (106
> GB)
>


If upgrading from a much older SVN (older than SVN 1.6), SVN 1.6 and newer
has a (optional) feature called representation sharing (rep sharing) which
could account for a big reduction in size: when adding duplicate files to
the repository, Subversion only stores one instance. However, I can't say
whether that's the case here, since I don't know whether you are upgrading
an older repository, nor the size of the revisions that are excluded from
the dump, nor the amount of duplicated data. It could be that ~61 GB of
data are accounted for by the revisions that were excluded from the dump,
and therefore are not in the "AlteraFix" repository.

Nathan

Re: svn: E160013: File not found: transaction '41-1j'

[Nathan Hartman]

On Thu, Jul 15, 2021 at 12:18 PM David Aldrich
 wrote:
>
> Hi Nathan
>
> Thanks for your answer. I didn't make this clear, but I do understand the 
> concept of Update and had updated the working copy before attempting the 
> rename.
>
> I have, just now, made a clean checkout and repeated the rename, but I get a 
> similar result.
>
> Another team member had attempted the rename earlier today but it failed with 
> a permissions error.
>
> Could there be some incomplete transaction lurking in the database that is 
> causing a tree conflict?
>
> Or some other problem, possibly associated with the use of spaces?
>
> Best regards
> David


Hello David,

The E155011 "Directory ... is out of date" error is Subversion trying
to be helpful by wrapping what could be an obscure commit error with a
more friendly one; however in this case it wasn't helpful.

The E160013 "File not found: transaction..." error is the important
one in this case.

I doubt that spaces in the path are causing the issue; my $employer's
repo contains filenames and directories with spaces and we have
renamed things many times without issues; however I won't completely
discount that possibility. There might be some edge case.

Let's try to narrow down the cause:

Do you know which version of Subversion is running on the server? Is
it a *nix or Windows based server? What type of server is it -- if
unsure you can tell by the URL you're using to access it: local
(file://), svnserve (svn://), or httpd-based (http:// or https://).

Is the item in question pulled in via svn:externals? Is it a symlink?

Can you see the file listed if you run 'svn ls' using the server-side
URL, e.g., if your server is svnserve, something like:

$ svn ls "svn:Feasibility Studies/Use Case
Analysis/TML/RIC_Initial_Use_Case_Analysis"

(Remember to enclose the path in quotes.)

If that's not found, gradually remove one item at a time from the end
of the path:

$ svn ls "svn:Feasibility Studies/Use Case Analysis/TML/"

You can also run 'svn info' with the same URLs, with spaces, and then
you should see the URL encoded with %20 in place of spaces.

Also, you might try using %20 in place of spaces and see if that makes
a difference. Perhaps by mistake one of those spaces is a different
codepoint, so looks like a regular space, but isn't.

Have you (or colleagues) attempted other commit operations in the
meantime and have they succeeded or failed?

If it's a httpd-based server, do httpd's logs show anything that seems
significant?

Dumb question: Could the server be low on disk space?

As a possible workaround: You could perhaps try the rename as a
server-side operation? i.e., 'svn mv' giving the old and new
server-side URL and a commit message.

Let us know...
Nathan

P.S., You asked if any stale transactions might be lurking. You can
check with the 'svnadmin' subcommand 'lstxns'. That would need to be
run on the server. It is described here:

https://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.deadtxns

(Search for "lxtxns" on that page; I suggest not to rush to delete any
you might find, in case they offer some helpful clues.)

Re: svn: E160013: File not found: transaction '41-1j'

[Nathan Hartman]

On Thu, Jul 15, 2021 at 10:54 AM David Aldrich
 wrote:
>
> I'm trying to rename a directory and I get this error on commit:
>
> Adding TML/RIC_Initial_Use_Case_Analysis
> svn: E155011: Commit failed (details follow):
> svn: E155011: Directory '//Feasibility Studies/Use Case 
> Analysis/TML/RIC_Initial_Use_Case_Analysis' is out of date
> svn: E160013: File not found: transaction '41-1j', path 
> '/Feasibility%20Studies/Use%20Case%20Analysis/TML/RIC_Initial_Use_Case_Analysis'
>
> I guess the problem is associated with the fact that the path contains spaces.
>
> Any advice on how to resolve this please?


Normally the "out of date" error means that the repository contains
newer changes that your working copy does not have yet, such as, for
example, modifications to files inside the directory you are trying to
rename. Normally your working copy must be up-to-date with the
repository before you commit, at least for all items that are touched
by any kind of modifications in your working copy.

Practically speaking, this means that you would need to 'update' your
working copy first; since you have renamed a directory, you may have
to resolve a tree conflict. Alternatively, if renaming the directory
is the only change you're making, it might just be simpler to 'revert'
that change in your working copy, then 'update', then rename the
directory, and then 'commit'.

There's better documentation in the SVN book:

https://svnbook.red-bean.com/en/1.7/svn.tour.treeconflicts.html

Search for "is out of date" on that page to jump straight to it.

Hope this helps,
Nathan

Re: svn log xml hangs and produces too many logentry closing tags

[Nathan Hartman]

On Tue, Jul 13, 2021 at 5:49 PM Attila  wrote:
>
> Hi
>
> I have a problem getting the svn log in a branch after sync-merging a commit 
> from trunk.
> This commit in trunk is a merge of an old and complex branch with many 
> commits.
>
> The client accessing the repository over svn:// url.
> (paths and text is redacted)
> The  head revision is: 10801
>
> When I run the following command on the client (in the working copy), it 
> prints a long partial xml-log output, then hangs.
> /usr/bin/svn log --xml -g -v -r 10701:HEAD /path/to/branch-wc
>
> When observing in "top", the command uses no visible CPU resources on hang. 
> (I waited ca. 2 minutes)
> The hanging command does mot exits on CTRL-c, it does not exits on "kill 
> -TERM pid", I have to send "kill -KILL pid" to terminate it.
>
> When I run the command with strace it hangs at read(4,
> ...SNIP...
> read(4, " ( ) ( 4:file true false ) ) ( 1"..., 16384) = 16384
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d83000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d81000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d7f000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d7d000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d7b000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d79000
> read(4, "***/-***_redacted_*_"..., 16384) = 14773
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d77000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d75000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d73000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d71000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d6f000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d6d000
> read(4,
>
> When I observe the server, there is a CPU activity at the begin, but when the 
> client hangs, the server seems to be in idle.
> Just a corresponding svnserve process is there with no visible cpu usage.
> In svnserve.log is nothing relevant to see.
>
> The svnserve command is:
> svnserve -d -r /path/to/repositories \
> --log-file=/var/log/svnserve.log \
> --memory-cache-size 1024 \
> --cache-txdeltas yes \
> --cache-fulltexts yes
>
> When I try to get the xml-log on the server with the corresponding file:// 
> repository URL:
> /usr/bin/svn log --xml -g -v -r 10701:HEAD 
> file://path/to/local/repositories/project/branch
> The command finishes in ca 5-10 seconds and I get the xml output, but the 
> output has a way too many  lines.
>
> There are 1217 occurrences of the string “ the string "" in the output xml.
> There are several thousand lines of  in a row in many places in 
> repeated blocks.
>
> Details:
> Client and Server OS:
> Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27) x86_64 
> GNU/Linux
>
> The repository is ca. 4 GB.
> Running "svnadmin verify" on the server founds no errors.
> I have no other problems with the server, checkout and commit works normal.
>
> svn --version
> svn, version 1.10.4 (r1850624)
>compiled Feb 10 2021, 20:15:45 on x86_64-pc-linux-gnu
>
> Copyright (C) 2019 The Apache Software Foundation.
> This software consists of contributions made by many people;
> see the NOTICE file for more information.
> Subversion is open source software, see http://subversion.apache.org/
>
> The following repository access (RA) modules are available:
>
> * ra_svn : Module for accessing a repository using the svn network protocol.
>   - with Cyrus SASL authentication
>   - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
>   - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV protocol using serf.
>   - using serf 1.3.9 (compiled with 1.3.9)
>   - handles 'http' scheme
>   - handles 'https' scheme
>
> The following authentication credential caches are available:
>
> * Plaintext cache in /home/username/.subversion
> * Gnome Keyring
> * GPG-Agent
> * KWallet (KDE)


Hello Attila,

Thanks for this detailed explanation. There are quite a few important
clues here.

To help narrow down the search for the culprit: Are you able to run
the same 'svn log' command against the same working copy, but without
the '--xml', and get a correct output in a reasonable amount of time?

If log without '--xml' works and log with '--xml' gets stuck, is it
feasible to try to bisect the revision range, e.g., run log on the
range r10701:10751, and in a separate invocation on r10751:10801, and
try to see if there's a revision in particular where SVN is getting
confused? If so, then perhaps knowing a little more about that

Re: message "disk I/O error" when TurtoiseMerge is open (after update) and another updating by script/batch is done

[Nathan Hartman]

On Mon, Jul 12, 2021 at 6:44 AM Arbeiter Ansgar 
wrote:

> after update an repository, i normally check actual changes (with
> TurtoiseMerge) so this tool and the update window are open.
>
> when i then update again (by batch file) then i very often get this
> message:
>
>
>
> svn: E200030: sqlite[S10]: disk I/O error
>
>
>
> when i close TurtoiseMerge (and update window) before update again, then i
> never noticed it.
>
> (i also checked for actually disk problems, but there are none)
>
>
>
> batch file:
>
> @echo off
>
> svn --version > nul
>
> if %ErrorLevel% gtr 0 (
>
>   echo Sources can't be updated because the SVN-client not found. Please
> install the console tools TortoiseSVN.
>
> ) else (
>
>   svn up ..\..\Axxx
>
>   svn up ..\..\Cxxx
>
>   svn up ..\..\Dxxx
>
>   svn up ..
>
> )
>
>
>
> used versions:
>
>
>
> TortoiseMerge 1.14.1, Build 29085 - 64 Bit , 2021/02/09 16:17:02
>
> libsvn_diff 1.14.1,
>
> apr 1.6.5
>
> apr-util 1.6.1
>
>
>
>
>
> TortoiseSVN 1.14.1, Build 29085 - 64 Bit , 2021/02/09 16:17:02
>
> ipv6 enabled
>
> Subversion 1.14.1, -release
>
> apr 1.6.5
>
> apr-util 1.6.1
>
> serf 1.3.9
>
> OpenSSL 1.1.1i  8 Dec 2020
>
> zlib 1.2.11
>
> SQLite 3.29.0
>
> Mit freundlichen Grüßen / With kind regards
>
> i.A. Ansgar Arbeiter
> Graduate Engineer - Development
>

Hello,

It sounds like one of the tools may be holding the working copy
database open and/or locked in some way against access by other
programs (e.g., a file system based locking, a SQLite EXCLUSIVE_LOCK,
etc).

The error message "disk I/O error" may be misleading in this case;
i.e., it may not be an actual *disk* error, but rather inability to
open or operate on the database file for other reasons. (This error is
reported when the working copy's SQLite database reports SQLITE_IOERR.
The [S10] means the same thing as SQLITE_IOERR; it doesn't give any
more information. That is a generic code for a multitude of different
conditions.)

It's probably just best to close the Tortoise windows when you want to
use the command line client; however maybe someone else on this list
will know a better answer. You could also try asking at the
TortoiseSVN mailing list (see [1] below) whether the Tortoise client
is expected to prevent simultaneous access by other clients, and if
so, whether there is a way to avoid that.

[1] https://groups.google.com/g/tortoisesvn

Hope this helps,
Nathan

Re: Off-topic about the List itself: Does it handle posts from DMARC-enabled senders well?

[Nathan Hartman]

On Wed, Jun 9, 2021 at 4:12 PM James H. H. Lampert
 wrote:
>
> I'm in the process of setting up DMARC for my company's domain.
>
> Does this List either rewrite headers on posts from DMARC-enabled
> senders, or otherwise do something to ensure that posts from
> DMARC-enabled senders are not mis-identified by recipients as spoofed?
>
> --
> James H. H. Lampert
> Touchtone Corporation

Hello James,

The mailing list service itself is managed by the Foundation's
Infrastructure team ("Infra"). You could try asking them. See
https://infra.apache.org/contact.html

Nathan

Re: Getting error E205009 upon doing SVN copy using URL

[Nathan Hartman]

On Wed, Jun 9, 2021 at 1:17 PM Ranajit Ghosh 
wrote:

> Hi..it's https:// for both urls.
>
> Thanks!
>


Is it possible that locale settings are interfering with the «://»
characters between https and the rest of the path?

Have you tried to enclose each entire URL in quotes?

Nathan

Re: Getting error E205009 upon doing SVN copy using URL

[Nathan Hartman]

On Wed, Jun 9, 2021 at 10:08 AM Ranajit Ghosh
 wrote:
>
> It is Bash shell with the following version.
>
> GNU bash, version 4.3.30(1)-release  (powerpc-ibm-aix6.1.0.0)


What is the URL scheme used with the  and  URLs?

(Are they http://, https://, svn://, svn+ssh://, file://, ...)

Nathan

Re: Unexpected behavior of svn log -r BASE:HEAD

[Nathan Hartman]

On Wed, Jun 2, 2021 at 8:47 AM Guillaume Brunerie
 wrote:
> Is there another way to get what is described in the help message? To show 
> the log messages for any incoming changes to foo.c during the next 'svn 
> update'. This is exactly what I was trying to do.

Not exactly what you're asking for, but:

svn status --show-updates

(or the shorthand 'svn st -u')

might be helpful.

Nathan

Re: Commit succeeded, E000030: Can't change perms

[Nathan Hartman]

On Mon, May 24, 2021 at 5:04 AM Pingu  wrote:
>
> Hello,
>
> I was adding some files to a repository and encountered error "E30:
> Can't change perms". The commit was successful but I don't understand
> the error.
>
> The files I added were from a read-only source, so I understand the
> nature of the error. What I don't understand is, why is SVN trying to
> change permissions?
>
> I assume this doesn't affect the commit but I would like to understand.
>
> -Kenneth
>
> Example of error:
>
> svn: E20: Commit succeeded, but other errors follow:
> svn: E155009: Error bumping revisions post-commit (details follow):
> svn: E155009: Failed to run the WC DB work queue associated with
> 'somerepository', work item 17 (file-commit 12 somefile)
> svn: E30: Can't change perms of file 'somefile': Read-only file system


During post-commit processing, Subversion ensures that the file is as
it should be in the working copy [1], meaning that its contents and
permissions match its properties and lock status. This includes
adjusting (if necessary) line ending style, keyword translation, and
read/write/execute permissions. In other words, this may alter not
only the file's permissions, but also its contents.

You can see other examples of this post-commit processing in action.
For example, create a test repository, add and commit a text file with
CRLF line endings. Then, add a svn:eol-style property of "LF" to the
file and commit again. Then, without running 'svn update' or any other
commands that might make changes, check the contents of the file and
you'll see that its line endings have changed to LF.

Hope this helps!

[1] See install_committed_file() in libsvn_wc/workqueue.c.

Cheers,
Nathan

Re: subversion 1.7 - Internal server error (HTTP 500) - user account gets locked out

[Nathan Hartman]

On Fri, May 21, 2021 at 8:48 AM jackson  wrote:
> Hi Team,
>
> We are using subversion 1.7 version and we are facing issues very often when 
> the users trying to commit or checkout they are getting HTTP 500 error and 
> the user is getting locked out.  The users are authenticated via LDAP.
>
> At first we thought it was a server resource crunch issue and we increased 
> the server resources but still we are getting the same problem


Hello,

Is this an issue that has begun recently or has this been an ongoing
problem for a long time?

I would like to point out that the 1.7 release line is somewhat old
and has not been updated since late 2015. That by itself doesn't mean
it is the cause of these issues, but if feasible it is probably a good
idea to update to one of the currently supported release lines; the
latest releases are 1.10.7 and 1.14.1.

Thanks,
Nathan

Re: Need help in Subversion migration

[Nathan Hartman]

On Mon, May 17, 2021 at 8:26 PM Daniel Shahaf 
wrote:

> Mark Phippard wrote on Mon, 17 May 2021 12:24 +00:00:
> >
> > > On May 17, 2021, at 8:21 AM, jackson  wrote:
> > >
> > > 
> > > Hello Everyone
> > >
> > >  We are using subversion 1.7 running in LInux 6.9.
> > > we are working on subversion migration along with OS upgrade
> > >
> > > Currently we have built RHEL 8.3 OS with subversion 1.10 and did all
> the configuration , the 1.10 setup is up and working as expected .
> > >
> > > We need help in migrating the repo from current setup (v1.7 to the new
> setup
> > >
> > > The current setup (v1.7) has the repo size of 500GB. we are using svn
> load and svn dump method to migrate the repos from current setup (v1.7) to
> new setup(v1.10) , but it takes a lot of time due to the size of the repo
> (500GB) , Also the current setup (v1.7 is being currently used by the
> customer ,soo even after taking the dump of one particular repo and loading
> it in new setup , a newer revision is being made in the  current setup
> (v1.7 by the customer  , thus making us to do the svn dump and lsvn load
> again.
> > >
> > > now we need your help in identifying an efficient way in migrating the
> repo from the current setup (v1.7  to the ew setup(v1.10) , Need your
> expert advise on this please
> > >
> > >
> > > Also let us know we can do rsync for this?
> > >
> > > Thanks & Regards,
> > > Jackson J
> >
> > You do not have to do anything. Just point the new server at the
> > existing repositories or move them to new location.
>
> That's not necessarily correct for BDB repositories.
>
> > You can use rsync, tar or whatever method you prefer.
>
> That's not correct for live repositories.
>
> Bo and David covered the svnsync and «svnadmin hotcopy» approaches; all
> I have to add is that for «svnadmin dump», the --deltas, --incremental,
> and -r options should be used as necessary.



I'll add that several subsections of "Repository Maintenance" of Chapter 5
of the Subversion book are relevant, especially [1] and [2].

[1] Migrating Repository Data Elsewhere:
http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate

[2] Repository Replication:
http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.replication

(In this case I think [1] is the more relevant of these.)

Cheers,
Nathan

Re: Re[2]: How to install Subversion JavaHL library with homebrew in 2021?

[Nathan Hartman]

On Sun, May 9, 2021 at 7:21 AM Reto Hoehener  wrote:
> - sudo ln -s /opt/local/lib/lib svnjavahl-1.dylib

Regarding the line above, it seems something got cut off there?

Thanks for circling back. It will undoubtedly help others.

Cheers,
Nathan

Re: Consequences of reintegrating without first doing a sync-merge?

[Nathan Hartman]

On Fri, Apr 23, 2021 at 1:24 PM Mun Johl  wrote:
> I had to do a rush reintegration and in my haste I forgot to do the 
> sync-merge first.  What kind of fallout is possible under these 
> circumstances?  That is, what are the ramifications of me skipping the 
> sync-merge step.

I've done it a few times. :-)

If the reintegration merge completes without any conflicts, then it
shouldn't really make a difference. (Caveat: It might have made a
difference in older versions of Subversion. But since around 1.10,
merging has gotten vastly better.)

Yes, it is best practice to do the sync merge first, so that if there
are conflicts, it is better that their resolution should be part of
the branch. That way, the reintegration merge can be made and
committed without containing any extra (manual) changes for conflict
resolution. It results in a cleaner (more easily traceable) history.
Also syncing first means that (unless further changes are made) the
branch and trunk are identical except for the changes introduced on
the branch.

Cheers,
Nathan

Re: cannot find libsvn_fs_x-1.so.0, 1.10.7, CentOS 7

[Nathan Hartman]

On Mon, Mar 1, 2021 at 6:36 PM Zube  wrote:
>
> Trying to build 1.10.7 on CentOS 7 and failing.  1.10.6 builds fine.
>
> /usr/bin/ld: cannot find libsvn_fs_x-1.so.0: No such file or directory
> collect2: error: ld returned 1 exit status
> make: *** [build-outputs.mk:478: subversion/libsvn_fs_x/libsvn_fs_x-1.la] 
> Error 1
>
> One difference between .6 and .7 is from the created (from config.log)
> subversion/libsvn_fs_x/libsvn_fs_x.pc:
>
> 8,12c8,12
> < Version: 1.10.7
> < Requires: apr-util-1, apr-1
> < Requires.private: libsvn_delta, libsvn_subr, libsvn_fs_util
> < Libs: -L${libdir}  -lsvn_fs_x-1
> < Cflags: -I${includedir}/subversion-1
> ---
> > Version: 1.10.6
> > Requires:  apr-util-1 apr-1
> > Requires.private:  libsvn_delta libsvn_subr libsvn_fs_util
> > Libs: -L${libdir}  -lsvn_fs_x
> > Cflags: -I${includedir}
>
> In the .libs directory in .6, the libraries are built:
>
> libsvn_fs_x-1.a
> libsvn_fs_x-1.la
> libsvn_fs_x-1.lai
> libsvn_fs_x-1.so
> libsvn_fs_x-1.so.0
> libsvn_fs_x-1.so.0.0.0
> libsvn_fs_x-1.so.0.0.0T
>
> But they are missing from the .7 build.  The .o files are in the
> .libs directory, though.
>
> Any help is greatly appreciated.

Hello,

I've traced this to r1863987 and r1863990 on trunk, which were merged
to the 1.10.x branch in r1866641.

Part of the change was to respect pkg-config(1)'s requirement of a
comma-separated list, so you can see the commas being introduced in
your diff above.

Another part of the change is in build/generator/gen_make.py, which is
now adding the "-1" to "-lsvn_fs_x" making it "-lsvn_fs_x-1."

I don't think there is an error in these changes; rather, I think that
an additional change is needed elsewhere to make the built libsvn_fs_x
compliant.

I haven't yet determined what/where that change should be, nor what
workaround to suggest, but I wanted to reply with what I know so far.

Nathan

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

[Nathan Hartman]

On Mon, Mar 1, 2021 at 2:25 AM Daniel Sahlberg 
wrote:

>
> I think we should put it in the staging website for a final review? This
> should go under General questions?
>


Yes, please commit it to staging for now. There is already a FAQ entry with
ID plaintext-passwords; this is the update/replacement of that question.
Keeping the ID the same means that any URLs out there will still work, and
direct visitors to the updated answer.

Thanks!
Nathan

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

[Nathan Hartman]

On Sun, Feb 28, 2021 at 10:51 AM Daniel Sahlberg
 wrote:
> When researching, I discovered that reading plain text passwords that are 
> "grandfathered in" works the same way on Windows as on Unix. If the password 
> is invalid it is switched to passtype==wincrypt when updated.

Thanks for documenting that!

> I have taken Nathan's suggestion and rearranged it slightly, trying to 
> incorporate Danielsh' feedback. I have made notes as HTML comments:  - these should be removed from the final commit.

Thanks also for improving the FAQ text. This is a big improvement over
the text I proposed earlier. I only have a few minor nits to pick,
mostly on things I wrote... I'll respond inline below, and below that
for convenience I'll give the text with my proposed minor changes
applied...

> [[[
> 
> How does Subversion cache credentials (plain text and encrypted)?
> 
>title="Link to this section">
> 
>
> To avoid having to type a password for each server operation, Subversion
> can cache credentials.
>
> Passwords may have been cached unencrypted by older versions of Subversion
> ("grandfathered in") and Subversion always supports reading these. Whether and
> how Subversion caches new credentials depends on several factors, including 
> the
> access method, operating system, compile-time options, and settings in the
> client's run-time config file.
> 
>
> 
>
> To show the credentials in your cache, use svn auth. Credentials
> are never removed automatically but Credentials may be removed manually using

In the above sentence, should the last mention of "Credentials" be
removed?

> svn auth --remove.
> 
>
> Windows
>
> On Windows, Subversion uses standard Windows APIs to encrypt the data, so
> only the user can decrypt the cached password. (Since Subversion
> 1.2.)
>
> macOS (formerly Mac OS X)
>
> On macOS, Subversion uses the system Keychain facility to encrypt/store
> the user's svn password. (Since Subversion 1.4.)
>
> UNIX/Linux
>
> On UNIX/Linux, Subversion supports up to four credential caches:
>
> 
> GNOME Keyring
> KWallet
> GPG-Agent
> Plaintext cache in ~/.subversion

I think we should write "Plaintext cache in ~/.subversion/auth/".
This is a preexisting issue from the original FAQ and I meant to
change it before, but I forgot.

> 
>
> To determine which credential caches your Subversion client supports, run
> the svn --version command and look for "The following authentication
> credential caches are available" toward the end of its output.
>
> GNOME Keyring and KWallet both facilitate storing passwords on disk
> encrypted. For Subversion to support these programs (since Subversion 1.6),
> they need to be available at compile-time and at run-time.
> 
> TODO: Discuss GPG-Agent.
>
> Depending on a compile-time option (--enable-plaintext-password-storage)
> and runtime configurations (see below) Subversion may fallback to 
> storing
> passwords in the Plaintext cache.
> 
>
> The default value of --enable-plaintext-password-storage was changed from
> True to False in Subversion 1.12, thus disabling the Plaintext cache unless
> explicitly enabled.
> 
>
> The directory which contains cached Plaintext passwords (usually
> ~/.subversion/auth/) has permissions of 700, meaning only the user
> (and root) can read them.
>
> "Subversion was compiled with support for Plaintext password cache but I
> want to prevent writing passwords to the Plaintext cache!"

I originally put the exclamation points in these titles, but now I
think it would be better to replace them with periods.

> The following options are available in your run-time config file
> (per user ~/.subversion/config and ~/.subversion/servers,
> systemwide /etc/subversion/config and /etc/subversion/servers):
>
> 
> To allow encrypted stores like GNOME Keyring and KWallet, but not the
> Plaintext cache, set store-plaintext-passwords = no.
> To allow caching server certs but not passwords (encrypted or not), set
> store-passwords = no.
> To disable storing any kind of credentials (encrypted or not) set
> store-auth-creds = no.
> 
>
> 
>
> "I want to use the Plaintext cache but it wasn't enabled at compile
> time!"

Same comment here about my exclamation point.

> 
>
> 
>
> In response to various questions and requests, the Subversion developers
> have written a Python script that can store a plain-text password to the
> cache. If you understand the security implications, have ruled out other
> alternatives, and still want to cache your password in plain-text on disk, you
> may find the script here:
>
> TODO: Link to the script.
>
> Additional Information
>
> More information on password caching is in Chapter 6 of the  href="http://svnbook.red-bean.com/en/1.7/index.html;>Subversion book,
> under  href="http://svnbook.red-bean.com/en/1.7/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache;
> >"Client Credentials Caching".
>
> 
> ]]]

Here's the full text with my above suggestions applied... I didn't
remove the HTML comments, 

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

[Nathan Hartman]

On Thu, Feb 25, 2021 at 2:00 AM Daniel Shahaf 
wrote:

> Daniel Sahlberg wrote on Wed, Feb 24, 2021 at 23:27:18 +0100:
> > Suggestion for new FAQ entry:
> > [[[
> > Ahhh! I just discovered that my Subversion client is NOT caching
> passwords
> > in plain-text on disk! AHHH!
>
> Having two entry titles that differ only by a "not" isn't a good idea.
>
> > Calm down, take a deep breath.
> >
> > This is the opposite of the previous question. After changing the compile
> > time default to not store passwords in plain-text there has been a number
> > of requests in the mailing lists to store the password.
>
> "A number of requests on the mailing lists" seems like too fine a level
> of abstraction.  I think the context basically needs to be "The default
> is X but you may want Y; here's how to do that".
>
> > If you understand the security implications, you have ruled out other
>
> s/, you/, /
>
> > alternatives and still want to cache your password in plain-text on disk
>
> s/ and/, and/
>
> > you can use the script
> >
> https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/store-plaintext-password-py
> > to store the password in the directory which contains the cached
> passwords
> > (usually ~/.subversion/auth/). The script can also be used to list any
> > existing passwords stored in plain-text.
>
> This should just point to `svn auth`, surely?
>
> Should this explicitly say to run the script with --help to get its
> usage message?
>
> > ]]]
> >
> > I'm also suggesting to change the existing FAQ entry (Ahhh! I just
> > discovered that my Subversion client is caching passwords in plain-text
> on
> > disk! AHHH!) to mention the changed compile time default since 1.12 to
> not
> > store plain-text passwords:
> >
> > [[[
> > s/Otherwise, the client will fall back/Otherwise, the client can fall
> back/
> >
> > Since svn 1.12 the compile time default has been to disable storing new
> > passwords in plain-text, but old passwords can still be used. Certain
> > distributions may also have selected to use the compile time option to
> > enable plain-text password storage.
>
> Spell out that "old" passwords means passwords already cached on disk
> ("grandfathered") — as opposed to, say, passwords that had been changed.
>
> The wording "Certain distributions may…" sounds like indirect
> finger-pointing.  Why not s/speculation/fact/: a compile-time option to
> enable plaintext passwords storage is provided and may have been
> selected by whoever built the binaries you're using (the term "distro"
> doesn't capture VisualSVN and TortoiseSVN).
>
> > s/However .*/In case Subversion is compiled with support for storing
> > plain-text passwords, you can disable it in your run-time config file by
> > setting 'store-plaintext-passwords = no' (so that encrypted stores like
> > GNOME Keyring and KWallet will still be used - this is already done in at
> > least one distribution which has selected to enable the plain-text
> password
> > storage in svn 1.12). If you want to disable storing any kind of
> > credentials you may instead set 'store-auth-creds = no', or you can use
> the
> > more narrowly-defined 'store-passwords = no' (so that server certs are
> > still cached). More information on password cacheing is in chapter 6 of
> the
> > "Nightly Build" Subversion book, under "Client Credentials Caching"./
>
> Is the information only available in the nightly build?  If not,
> s/"Nightly Build"//.
>
> > ]]]
> >
> > The "Since svn 1.12..." should probably go in the end of the first "On
> > UNIX/Linux" section, after "(Since svn 1.6.)"
>
> At this point, a «svn diff -x-U10» unidiff might be easier for everyone.
>
> By the way, how about changing "if you're really worried" in the
> preëxisting text.  This phrasing crosses the line from discussing the
> reader's risk assessment to discussing their mental state.
>


May I propose to have just one FAQ entry that simultaneously would answer:
* "what alternatives to plaintext caching are there?"
* "plaintext caching is supported but I want to *prevent* it"
* "plaintext caching is not supported but I want to use it anyway"

I took the FAQ entry we have right now, expanded it, fixed a few
mistakes, updated a few out-of-date things, incorporated some of
dsahlberg's text, incorporated some of danielsh's feedback, added new
information, and now the following bears little resemblance
to any of the above...

But I've introduced some flaws, but I'm out of time for the day to fix
them. Please feel free to edit/reorganize/spindle/mutilate!!

Notes: INSTALL doesn't seem to document what is needed for Subversion
to support GPG-Agent on disk.

[[[


Password caching in plain-text on disk
  


To avoid having to type a password for each server operation, Subversion
can cache credentials.

Whether and how Subversion caches credentials depends on several factors,
including the operating system, compile-time options, and settings in the
client's run-time config file.

On some operating 

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

[Nathan Hartman]

On Tue, Feb 23, 2021 at 8:35 AM Daniel Shahaf 
wrote:

> Nathan Hartman wrote on Mon, Feb 22, 2021 at 14:36:58 -0500:
> > In a recent discussion on our dev mailing list, there is an example
> > shell script (for zsh) that saves a password file. See [2] and note
> > that there were a few corrections to the script so be sure to use the
> > latest version in that mail list thread.
> >
> > [1]
> https://subversion.apache.org/docs/release-notes/1.12.html#client-server-improvements
> >
> > [2]
> https://lists.apache.org/thread.html/r0eef40236aeddd1db18bc7882454dd3b18bcd721d8fd8c9e21aca52a%40%3Cdev.subversion.apache.org%3E
> >
> > I hope the above is helpful; feel free to ask as many questions as you
> > need to, or propose improvements to the above-mentioned script or
> > Subversion itself. We have gotten quite a few questions about this and
>
> I'm starting to wonder if that script deserves a home more permanent
> than the end of a random dev@ thread whose subject line contains "WTF"
> and "?!"; e.g., perhaps that script should be linked from the FAQ or
> the release notes.



I agree we need a better place for the script, especially as the above
mail thread contains more than one version of it.

I think it's a good candidate for contrib (though it might be better
to port it to portable Bourne shell first).

Would a Python version be useful?

Regarding the FAQ, currently we have [1] "Ahhh! I just discovered that
my Subversion client is caching passwords in plain-text on disk!
AHHH!" That is still applicable to 1.10, but now we need an entry to
answer the opposite question: how to cache the password for svn use
with cron jobs and non-X environments where Kwallet and GNOME-Keyring
aren't applicable, and the particularly annoying case in which the
machine itself has a GUI but the user is logged in via ssh; in this
case the svn client will "freeze" while waiting for password entry in
an inaccessible GUI window; I think this would occur with Kwallet,
GNOME-Keyring, and macOS's Keychain.)

But, as there doesn't seem to be one well-established way to handle
this, other than just storing the password on disk, would the new FAQ
entry say just that? Do we have any other concrete suggestions?

[1] https://subversion.apache.org/faq.html#plaintext-passwords

Nathan

Re: using svn cli with --non-interactive (in scripts) securely, without exposing password

[Nathan Hartman]

On Mon, Feb 22, 2021 at 1:17 PM CoolCold  wrote:
>
> Good day!
> (please CC me, I'm not subscribed to the list)
>
> A bit of context:
> I was using subversion to store my serves' configs versioned for
> almost a decade, with bash wrapping around it. Simplified, it had repo
> per server name, wrapper called by cron to checkout, rsync over,
> commit changes back, sending email on diffs (
> https://github.com/coolcold/svnbackup ). Had no issue with it, when
> password store was enabled. It's runned under root user and saved
> credentials are not exposed to non-admin users on the system.
>
> Issue: with recent changes hitting packages in distributions (
> https://marc.info/?l=subversion-commits=154101482302608=2 ), that
> seems to be not possible anymore.
> I did adjust my script to use command line switch --password, but this
> makes it visible for anyone who does simple commands like ps aux.
> I've tried to look around for possible support of environment
> variables / password file support, but couldn't find any except some
> old proposals like
> http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html
>
> Rebuilding  subversion from source is not an option for many reasons.
>
> Seeking for your help on this, what is the proper way of doing this
> with recent versions?
> Thanks in advance.

Hello,

Recent versions (1.12.x and newer [1]) by default don't _save_
passwords to disk in plaintext (unless configured to do so at
build-time).

However, Subversion will _use_ the password, if it is already stored
on disk.

So, as a workaround, you could use some out-of-band method to save the
password to disk either by using an older SVN client or by generating
a file with the right bits in it:

In a recent discussion on our dev mailing list, there is an example
shell script (for zsh) that saves a password file. See [2] and note
that there were a few corrections to the script so be sure to use the
latest version in that mail list thread.

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

[2] 
https://lists.apache.org/thread.html/r0eef40236aeddd1db18bc7882454dd3b18bcd721d8fd8c9e21aca52a%40%3Cdev.subversion.apache.org%3E

I hope the above is helpful; feel free to ask as many questions as you
need to, or propose improvements to the above-mentioned script or
Subversion itself. We have gotten quite a few questions about this and
it has been frustrating for anyone who uses svn as part of cron jobs
in non-X environments, where the available encrypted password stores,
Kwallet and Gnome-keyring, aren't much help, and GPG-Agent doesn't
persist the passwords indefinitely. We would be really grateful if
someone could propose a solution that works well in these scenarios
while alleviating people's concerns about storing passwords on disk in
plaintext.

Cheers,
Nathan

Re: internal malfunction libsvn_wc\wc_db.c line 10189

[Nathan Hartman]

On Tue, Feb 16, 2021 at 5:48 PM James G. Bunger 
wrote:

> Hi,
>
>
>
> I was trying to commit a set of changes that included copying an existing
> set of folders to two new sets.  Basically creating two new projects from
> an existing one.  I had gotten a series of failures to commit due to
> “Non-recursive commit of moved/renamed folder” messages.
>
> This is with Windows 10 64 bit over a VPN connection and using TortoiseSVN.
>
>
Hi,

Thanks for reporting this.

Did the series of "non-recursive commit" failures you mentioned occur
within the same commit that failed, or during earlier work?

Also, in the commit that failed, were there also some moves, renames, or
deletes, either in the folders you were copying or in other parts of the
working copy?

To work around the issue:

Is it feasible to checkout a fresh working copy and retry the copy and
commit?

Alternatively, would it be acceptable to make the copies as server-side
copies?

Please let us know if you need help with any of the above.

Thanks again,
Nathan

Re: subversion 1.14.1: could not build python bindings (1.41.0 is Ok)

[Nathan Hartman]

On Tue, Feb 16, 2021 at 12:32 PM Lev Serebryakov  
wrote:
>   I found cause, but as I'm not python programmer, I don't understand it.
>
> Old "import _XXX" (like "import _core" in 
> subversion/bindings/swig/python/core.py) works, new "from . import XXX" 
> doesn't.
>
>I've patched these lines in 8 files (all in 
> subversion/bindings/swig/python/) and it helps. But I don't know why :)
>
>Please note, that I've changed only these lines, I didn't revert whole 
> changes (which is much larger) around these lines.


Thank you! That is immensely helpful. Now we can check when and why
that change was introduced.

Nathan

Re: subversion 1.14.1: could not build python bindings (1.41.0 is Ok)

[Nathan Hartman]

On Tue, Feb 16, 2021 at 10:05 AM Lev Serebryakov  
wrote:
>
>
>Update to 1.14.1 break out-of-tree build of python bindings (with python 
> 3.7).


Are you building from a distribution tarball? (As opposed to a
checkout or export of the 1.14.1 tag in our repository...) If so, did
you run autogen.sh? I noticed some changes in
subversion/bindings/swig/INSTALL on trunk that haven't been backported
to 1.14.x. It's possible they (or some of them) should be backported.
You can generate a diff to view the changes with:

$ svn diff \
https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/swig/INSTALL
\
https://svn.apache.org/repos/asf/subversion/tags/1.14.1/subversion/bindings/swig/INSTALL

Since your system shows the issue and Yasuhito couldn't reproduce it,
would you be able to run a bisect on the 1.14.x branch, between
r1877950 and r1886195 to identify which backport commit introduces the
problem? That would be an immense help.

Thanks,
Nathan

Re: svn info tree conflicts bug using svn 1.10.6?

[Nathan Hartman]

On Tue, Jan 19, 2021 at 12:45 PM Matthews, David <
david.matth...@metoffice.gov.uk> wrote:

> I appear to be getting incorrect results reported by "svn info --xml" for
> a file which has tree conflicts.
>
> I'm testing with svn 1.10.6 (and 1.9.12 which doesn't have this problem).
>

Hello,

Just following up to let you know that the above bug is fixed in svn 1.10.7
and 1.14.1, both of which were released last week.

Cheers,
Nathan

Re: storing password on a server

[Nathan Hartman]

On Wed, Feb 10, 2021 at 7:31 PM HONTVÁRI Levente  wrote:
>
> I understand that 1.14 disables storing a password at compile time.
>
> How am I supposed to run a subversion command in non-interactive scripts
> like a cron job on a headless server?
>
> Of course I can supply the password on the command line but that is
> definitely a step backwards compared to the old way, which stored the
> password in a file which was only readable by the current user.

Yes, since 1.12 (see [1]), or more specifically, there is a
compile-time setting that prevents Subversion from writing passwords
to disk in plaintext. However, if the passwords are already present on
disk, Subversion will use them, regardless of this compile-time
setting.

There are various ways to solve your issue:

As a workaround, you could save the password to disk yourself, and
then Subversion will use it. To do this, you could use an older
version of Subversion, or any reasonably recent version that has been
built with the feature enabled, or, if that's not a viable option:

Another way to get the password onto disk is discussed toward the end
of the following email thread on our dev@ list, see [2] below. In that
email thread, there is a (somewhat of a prototype) shell script (for
zsh) to save passwords. If you want to use it, please note that there
were a few corrections, so be sure to use the latest version. Make
sure you understand what it does before you run it; there is an
explanation in that email thread of what the script does. (If you feel
like porting it to plain portable sh or have any other improvements
for it, feel free to respond to that email thread, or start a new
one...)

Besides getting the password onto disk, there are other possibilities,
such as finding a way to inject a secret into a script; this is
mentioned in [3].

This issue is frustrating and we do get questions about it; what
prevents us from returning to the old way is that there's another side
of the community that will come at us with pitchforks and torches if
we store passwords to disk in plaintext, so the current situation is a
compromise. Feel free to email dev@ with any suggestions you might
have on how this could be improved.

References:

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

[2] 
https://lists.apache.org/thread.html/r0eef40236aeddd1db18bc7882454dd3b18bcd721d8fd8c9e21aca52a%40%3Cdev.subversion.apache.org%3E

[3] 
https://lists.apache.org/thread.html/r223e0833b1c75005fdb01a9c117039765addb32232e5327ea3a5b5dc%40%3Cusers.subversion.apache.org%3E

Nathan

Re: Migrate from StarTeam to Subversion

[Nathan Hartman]

On Mon, Feb 1, 2021 at 2:21 PM Mark Rutz 
wrote:

> Hello,
>
>
>
> Does anyone have procedures or tools for converting Micro Focus StarTeam
> repositories to Subversion?  We would like to convert the main branch with
> history for each repository.  The team is small enough there is no need to
> port the existing permissions scheme, etc.  The branches can be left for
> cold storage, as I don’t expect them to be needed by any of the developers
> going forward.  We have a few perpetual licenses for StarTeam to keep it in
> the attic just in case.
>
>
>
> I’m aware of the svn-importer tool from Polarion (
> https://polarion.plm.automation.siemens.com/products/svn/svn_importer),
> but as far as I know that hasn’t been updated since 2011.  I was hoping to
> find something more current.  Recently StarTeam added interfaces to work
> with Git, but I have yet to see a way to use that angle for the conversion
> either.
>
>
>
> Thanks in advance for any recommended strategies and tools
>

Hi Mark,

With the caveat that I haven't worked with StarTeam nor the above
svn-importer tool:

Since the svn-importer tool is no-cost and claims to do the trick,
that is the first avenue I would investigate, even though the tool
appears not to have been updated in a while. If it can migrate the
data to Subversion successfully, even if it generates an older
Subversion format, you should be able to then use Subversion to update
the data format to the latest.

If that avenue doesn't get the job done for whatever reason, I would
then check whether StarTeam can export a dumpstream that Subversion
can import directly (though I think this is unlikely).

If not, then StarTeam's interfaces to Git that you mentioned may be
useful as an intermediate step. Occasionally we get questions about
how to migrate from Git to Subversion. You may want to search the list
archives, see [1], for such questions. We just recently had a question
about Git to Subversion migration, see [2]. I'll mention here that Git
has a git-svn bridge that can push a linear sequence of git commits to
Subversion. Note that you may have to do some manipulation of the
intermediate git repository's history to get it into a state that will
push cleanly to a Subversion repository. This might take a little
experimentation, or it might just work. The git-svn bridge is part of
Git; see [3] and [4].

It's possible others will chime in with more thoughts/experiences.

Feel free to ask more questions if you need to, and it would be great
if you could circle back later and tell us what ultimately did the
trick. That will help others who have the same question in the future.

[1] https://subversion.apache.org/mailing-lists.html

[2]
https://lists.apache.org/thread.html/ref1c000c9d34869f6785cddd38d1e054c8007c0bc56905476e288b3d%40%3Cusers.subversion.apache.org%3E

[3] https://git-scm.com/book/en/v2/Git-and-Other-Systems-Git-as-a-Client

[4] https://git-scm.com/docs/git-svn

Cheers,
Nathan

Re: GITLAB to Subversion

[Nathan Hartman]

On Sat, Jan 23, 2021 at 8:43 PM Ronny Machado 
wrote:

>
> Hi guys,
>
> I found this e-mail address in the "Version control with Subversion".
>
> I've got a question, which may seem weird due to its nature...I've found a
> hole bunch of docs and videos about how to migrate from Subversion to
> Gitlab, but nothing addressing the other way round...Some devs wanted me to
> implement Gitlab, which I did...but after a few months it has become a
> nightmare, gitlab is a resource consuming beast, the admin tasks aren't  so
> "natural", lots of security holes and so on...So, for me the natural thing
> to do is come back to he good old tried and true,  Subversion
>
> Any recommendation? Any doc to read? Any guide?
>
> Thanks in advance.
> *--*
> *Ronny Machado C.*
> *IT Consultant*
> *+56 9 75199262*
> https://sospyme.tech/
>

If I understand your question correctly, you'd like to migrate content from
git to svn.

I don't know of a tool specifically setup to do this in a turn-key manner
but a few possibilities come to mind, depending on what you'd like to
achieve and how much you'd like to preserve.

For example, you could just checkout the latest content from git and import
that into svn, but that would not preserve any history. If you take this
approach, you'll probably want to keep a copy of the git repository around
for reference if you ever need to use the history.

If you'd like to preserve history, is it enough to just preserve the linear
history of the master branch? Git's and Subversion's branching/tagging
models are quite different and don't necessarily translate 1:1 when
converting a repository. If your master branch is not a linear sequence of
commits, you might need to first manipulate/rewrite git history to get it
into that state, before being able to convert it.

I'll list some avenues you may wish to explore.

CAVEAT: I have *not* used these personally. I'm only listing possibilities
I would investigate if I needed to migrate from git to svn:

(1) Reposurgeon:

This tool is setup to migrate from Subversion to Git, which is the opposite
of your question, but as it supports numerous version control systems and
can perform all sorts of manipulations and translations, it might be
possible to migrate in the other direction:

http://www.catb.org/~esr/reposurgeon/
https://gitlab.com/esr/reposurgeon

(2) git-svn bridge:

Git has a git-svn bridge that allows using git locally and then pushing a
linear sequence of commits to a Subversion repository. This could allow you
to preserve the linear history of a branch (e.g., the master branch) but
probably will not preserve other branches or tags automatically. As
mentioned above, it might take some up-front manipulation to get a git
branch into the form of a linear sequence that can be pushed to a
Subversion repository. The git-svn bridge is included in git and some
information on it can be found here:

https://git-scm.com/book/en/v2/Git-and-Other-Systems-Git-as-a-Client

https://git-scm.com/docs/git-svn

A quick search brings up the following interesting finds as well:

https://github.com/mrts/git-svn-bridge

https://stackoverflow.com/questions/13188135/using-git-as-bridge-between-git-and-svn-repos

Maybe others will have more input on this...

Hope this helps,
Nathan


>

Re: svn info tree conflicts bug using svn 1.10.6?

[Nathan Hartman]

On Tue, Jan 19, 2021 at 12:45 PM Matthews, David
 wrote:
>
> I appear to be getting incorrect results reported by "svn info --xml" for a 
> file which has tree conflicts.
>
> I'm testing with svn 1.10.6 (and 1.9.12 which doesn't have this problem).

Without digging deeper yet, I see it with 1.13.0 as well: 'svn info'
output is correct, but with '--xml' it shows the wrong right side of
conflict.

Thanks for the reproduction script and version numbers. This
information is extremely helpful. I'll let you know what I find...

Nathan

Re: Switching to a specific revision

[Nathan Hartman]

On Wed, Jan 13, 2021 at 10:59 AM Anton Shepelev  wrote:
> I want to `switch' to a location that existsed in a previous
> revision, but has since been moved.  I invoke:
>
>svn switch -r 1431 ^^/Client/B1/Addons/AddCost/ --ignore-ancestry
>
> and receive:
>
>svn: E160013: '/svn/Sources/!svn/rvr/6932/Client/B1/Addons/AddCost' path 
> not found
>
> This path is indeed not present in r6932, but it exists in
> r1431. Why does SVN try to access the later revision in
> spite of being told to use 1431?

Because '-r' tells SVN to look for that path in the HEAD revision and
then follow it back to the specified revision.

Try using a peg revision instead:

svn switch ^^/Client/B1/Addons/AddCost/@1431 --ignore-ancestry

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

("Version Control With Subversion," chapter 3 "Advanced Topics,"
section "Peg and Operative Revisions")

Cheers,
Nathan

Re: Why is svn not saving my password in Pi-OS?

[Nathan Hartman]

On Tue, Dec 29, 2020 at 1:00 PM Bo Berglund  wrote:

> Well I had a look and it does not seem like there is much of this on
> the RPi4...
>  .gnupg/ is empty including its subdir private-keys-v1.d/
>  /etc/pam.d/login has a lot of settings but the referenced so files do
> not exist (on path at least)
>
> I read your links and I did not understand a lot of it.
>
> But in the "Gray's answer" part I could follow 1.1 and 1.2 (edit the
> config file).
>
> But for item 2 I drew a blank...
> The Collabnet keyring_tool does not exist on my system:
> $ which keyring_tool
> (no output)
>
> So the instruction to "Create a keyring for your password."
> by the operations below cannot be executed:
>
> keyring_tool --create=svn
> or
> keyring_tool --setdef=svn
>
> And apt is no help either:
>
> $ sudo apt install keyring_tool
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package keyring_tool
>
> Seems such a pity that a tool like Subversion can be so broken by some
> "upgrade" that it becomes unusable...


I don't think it's Subversion that's broken in this case. It's an issue of
configuration. The problem of the GUI dialog while accessing a machine via
SSH is a known complication that affects other software too. It will happen
with any software that tries to use these credential caches. I don't have a
RPi that I could experiment with but maybe I can setup something reasonably
similar to try to reproduce this...

Nathan

Re: Why is svn not saving my password in Pi-OS?

[Nathan Hartman]

On Mon, Dec 28, 2020 at 3:16 PM Bo Berglund  wrote:

> On Sun, 20 Dec 2020 11:59:11 +0100, Bo Berglund
> >5) Then the commit worked!
> >
> >So it seems like the svn config file must be modified and then it
> >starts working again.
> >
>
> Except now it has reverted to popping up the GUI login dialog when I
> am checking in via a PuTTY session.
> In PuTTY it just sits there doing nothing, if I then open the VNC
> window into the RPi then I see the login dialog there. :(
>
> How should the setting in subversions config file look like?
> Right now it is as follows (uncommented the existing line)
>
> password-stores = gpg-agent,gnome-keyring,kwallet
>
> Should something be taken out or something else added to make it stop
> this behaviour and always demand login on the terminal that issues the
> svn operation?
>
> It seems so strange that svn would use a completely different window
> to get the credentials from than the one where svn itself runs.


Hi Bo,

The order of the 'password-stores' setting is significant. Based on what
you wrote the last time, that means gpg-agent is tried first, followed by
gnome-keyring, followed by kwallet.

It sounds to me like one of these is putting up the GUI password dialog
that you want to avoid.

It is probably enough to choose just one of these password caches and set
it up properly, to ensure that you'll only use that one.

Here is some information about getting gpg-agent and gnome-keyring to
prompt for password in the console, not in the GUI. I'm also including a
link about KWallet, though that one doesn't look as encouraging to me as
the other two... you might want to remove that one from password-stores
(and you might want to remove one of the other two, leaving just one).


gpg-agent
=

To get gpg-agent to prompt for password in the console, see the following
two questions and answers:

https://superuser.com/questions/520980/how-to-force-gpg-to-use-console-mode-pinentry-to-prompt-for-passwords

https://stackoverflow.com/questions/17769831/how-to-make-gpg-prompt-for-passphrase-on-cli

Namely, these explain how to setup gpg-agent to use a console-based
pinentry program, either pinentry-tty or pinentry-curses.

gnome-keyring
=

Regarding gnome-keyring, see this question:

https://superuser.com/questions/141036/use-of-gnome-keyring-daemon-without-x

and in particular see Stephen Gray's answer (currently the 2nd from the
top). It includes a link to "source material" which is a WANdisco article
but that link is broken; the updated link is:

https://community.wandisco.com/s/article/How-to-set-up-encrypted-svn-password-storage-using-gnome-keyring-in-an-ssh-session

In particular, see the part about setting up a dbus session to interface
with the GNOME Keyring; I think that's the key step that allows it to work
without X (without a GUI).

kwallet
===

Less encouraging than the other two, but:

https://bbs.archlinux.org/viewtopic.php?id=253391

Hope one of these helps...
Nathan

Re: Why is svn not saving my password in Pi-OS?

[Nathan Hartman]

On Fri, Aug 14, 2020 at 7:35 AM Bo Berglund  wrote:
> How can I configure (?) svn such that it caches the password in the
> same way as it has done on all of my other RPi units before.
>
> I need to be able to work on this device BOTH via SSH login using
> PuTTY and inside the GUI when connecting via VNC.

I don't think you want to enable plaintext password storage. Also I
don't think that's part of the problem here.

The first thing you should do is run "svn --version" on the machine in
question and look for the list of available authentication credential
caches toward the end. On my Debian box, that looks like this:

[[[
The following authentication credential caches are available:

* Gnome Keyring
* GPG-Agent
* KWallet (KDE)
]]]

Those are much better than plaintext storage because the password
caches are stored encrypted.

If you don't have any credential caches listed, you'll need to either
request from the package maintainer(s) to do something about it, or
ensure you have the right dependencies installed and build the SVN
client from sources.

If you do get a list of credential caches that the SVN client
recognizes, then you should pick one and ensure it is setup correctly.

For example, if your SVN client supports gnome-keyring and you want to
use that, you'll need to ensure you have whatever required packages
installed on the RPi and may need to do some configuration so that the
keyring will be "unlocked" when you login via ssh (with PuTTY). That
should make the stored passwords available automatically and (at least
after the first time to initially enter the password) eliminate the
(GUI) password prompt.

Hope this helps,
Nathan

Re: svn diff -c does not accept HEAD

[Nathan Hartman]

On Tue, Dec 8, 2020 at 7:44 AM Anton Shepelev  wrote:

> Nathan Hartman:
>
> > A possible rationale is that the HEAD revision could
> > change without your knowledge (e.g., another user commits
> > something in the meantime) and you wouldn't get the
> > revision you were expecting.
> >
> > When I want to see the diff of the most recent revision I
> > use 'svn log -l 1 --diff'. (Note, though, that will be
> > from the BASE revision, not HEAD.)
>
> Thanks for the explanation, Nathan and Daniel, but svn diff
> -c does not support `BASE' either. Futhermore, from the
> viewpoint of consistency, it would be natural for -c and -r
> to accept exactly the same set of values, whose parsing
> would be implemented in the same piece of code.



Hi Anton,

Yes, 'svn diff -c' does not accept BASE or HEAD, only numeric arguments.

You could file it as a bug report / feature request, but since that has
been the case for a very long time, perhaps the most effective way to get
it changed is to submit a patch for review to the dev@ list.

Cheers,
Nathan

Re: svn diff -c does not accept HEAD

[Nathan Hartman]

On Mon, Dec 7, 2020 at 1:47 PM Yasuhito FUTATSUKI 
wrote:

>
> As the error message says, '-c' option accepts only numeric revision.
> It seems it is a kind of bug that the help text is not kind enough.


A possible rationale is that the HEAD revision could change without your
knowledge (e.g., another user commits something in the meantime) and you
wouldn't get the revision you were expecting.

When I want to see the diff of the most recent revision I use 'svn log -l 1
--diff'. (Note, though, that will be from the BASE revision, not HEAD.)

Hope that helps,
Nathan

Re: svn.haxx.se is going away

[Nathan Hartman]

On Tue, Nov 24, 2020 at 8:04 PM Daniel Shahaf 
wrote:

> Nathan Hartman wrote on Tue, 24 Nov 2020 21:27 +00:00:
> > On Tue, Nov 24, 2020 at 2:56 AM Daniel Sahlberg
> >  wrote:
> > > Den tors 12 nov. 2020 kl 17:46 skrev Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com>:
> > >> Could ASF provide this server space (basically a VirtualHost)? The
> archive is about 6.5 GB so it is not a huge amount.
> > >
> > > Any thoughts on this?
> >
> > I am looking into this; waiting for a reply...
>
> In the circumstances — it's Nov 25 and the site says it'll be taken down
> "in November 2020", not specifying a date — I'd say, better ask
> forgiveness than permission.

Let's go ahead and grab all the data we
> need to stand up the site (we have the mboxes, but not the mapping of
> *.shtml files to message-id's, nor any of the HTML/CSS/images), and if
> possible, also set it up (on svn-qavm.a.o or wherever) to ensure we've
> got everything and to prepare for a DNS repointing, if Daniel agrees.
> We can figure out the "paperwork", Puppet PRs, etc., later.


Just FYI it looks like yes, we will get the server space, but I don't know
details yet. The 1st order of business is to save the data...

@Daniel Sahlberg since you've previously reached out to the operator of
svn.haxx.se about saving the site, could you perhaps ask for a way to
download the data efficiently?

Nathan

Re: svn.haxx.se is going away

[Nathan Hartman]

On Tue, Nov 24, 2020 at 2:56 AM Daniel Sahlberg 
wrote:

> Den tors 12 nov. 2020 kl 17:46 skrev Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com>:
>
>> Could ASF provide this server space (basically a VirtualHost)? The
>> archive is about 6.5 GB so it is not a huge amount.
>>
>
> Any thoughts on this?
>

I am looking into this; waiting for a reply...

Thanks for the nudge.

Nathan

Re: svn.haxx.se is going away

[Nathan Hartman]

On Thu, Nov 5, 2020 at 5:16 AM Daniel Sahlberg 
wrote:

>
> Would it be considered a good thing if we manage to keep svn.haxx.se
> around?
>

Yes, I would consider that a good thing.

Even if Infra would get the old lists imported (I don't know what's holding
> them back), there are a bunch of references to the archives in the source
> (63 if I'm counting correctly), and in the website (87).
>

There are many more links in emails, in log messages, etc.

IIRC Infra said there's some software-related reason that holds them back
from importing the old material.

I have reached out to Daniel Stenberg and he seems willing to discuss to
> point the domain name to another server. I could probably volunteer to keep
> the site alive, provided there is an agreement within @Dev this is a good
> thing. Or is it better to just do the job and update the sources and
> website?
>

Thank you for reaching out.

It would be ideal if 3 things happen:

* keep svn.haxx.se alive to prevent breaking the myriad links that exist
out there

* getting the early years' SVN dev & users archives (2000-2009) onto ASF
hardware one way or another; if it can't/won't be backfilled to
lists.apache.org for whatever reasons, maybe it can be put on Subversion's
website

* updating the 63+87 links in the site and source to point to links hosted
on ASF hardware

svn.haxx.se also has archives for TSVN and Subclipse dev and users, which
is another reason to keep that site alive if possible.

Nathan

Re: svn.haxx.se is going away

[Nathan Hartman]

On Wed, Nov 4, 2020 at 3:32 PM Mark Phippard  wrote:
>
> Just a general fyi ... I went to https://svn.haxx.se/ today to search the 
> lists and noticed there is a banner on the site saying it is going offline 
> forever soon.
>
> I am not sure what the ramifications will be as I know there are a lot of 
> historical links in the docs and site but I guess it is what it is.

Daniel (danielsh) has been trying to get Infra to import the material
from pre-2009 (pre-migration to ASF) into lists.apache.org to avoid
losing the archives from the earliest period of development, which
arguably contain some of the most important development information.

See the discussion here:
https://lists.apache.org/thread.html/r97c9c5208af706b067fd8e67a7cbe79b37255958bb087bf699b722f8%40%3Cdev.subversion.apache.org%3E

Possibly it's still mirrored at home.apache.org but I can't check at the moment.

Nathan

Re: How to revert trunk to an earlier revision?

[Nathan Hartman]

On Thu, Oct 22, 2020 at 10:25 AM Bo Berglund  wrote:
> If I update my wc to that rev I get the state I want but now I cann
> not commit anymore...
>
> So how is this done? (I assume it is possible and if done via svn it
> should also be reversible).

It is reversible in the sense that no information is ever lost or
removed from the repository.

Suppose you're at revision 515 and to use Thorsten's example you want
to "go back" to revision 497, after running:

svn merge -r HEAD:497 .

(followed by commit)

revisions 498 through 515 are still in the repository and you can
always access them later.

See "Undoing Changes" in Chapter 4 of the Subversion Book:

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo

Nathan

Re: forcing update of keyword expansions in a working copy

[Nathan Hartman]

On Wed, Sep 30, 2020 at 6:50 PM Vincent Lefevre  wrote:
> Is there a way to force the update of keyword expansions to their
> correct values in a working copy?
>
> "svn up" will not change anything if the file hasn't changed, but
> the file may have obsolete keyword values, probably due to some bug
> in Subversion. I noticed the issue while checking data integrity by
> comparing an up-to-date working copy with the result of "svn export"
> (some keyword expansions were different, and it appears that the
> expansions of the Id keyword were not updated after a commit that
> only changed the svn:keywords property from "Id Date" to "Id").

Hi Vincent,

Searching through the issues database, I came across issue #4585 [1]
which you filed previously and this sounds related to the same issue.

Are you still using svn 1.8.x? If not, which version are you using now?

A few svn:keywords bugs were fixed in 1.9.x, including issue #1975
[2], where svn:keywords were not being re-expanded after 'svn switch';
perhaps that fix is common to this case as well. Note that 1.9.x went
end-of-life earlier this year, so if you could try with 1.10.x or
1.14.x, that would be preferred. (And 1.8.x went end-of-life more than
2 years ago.)

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

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

Thanks,
Nathan

[1] https://issues.apache.org/jira/browse/SVN-4585

[2] https://issues.apache.org/jira/browse/SVN-1975

Re: Svn revert and file permissions bug

[Nathan Hartman]

On Thu, Aug 13, 2020 at 9:32 AM Captain Hypertext
 wrote:
> I'm running Debian 9 with svn 1.8.17, but I also tried with svn 1.9.5, which 
> I guess is the latest version supported by our OS. Basically, I'm tasked with 
> updating the permission structure of our application servers because we've 
> been using root for years to do everything. We have an svn repo where all the 
> files are owned by the root user.
>
>
> If I change the file ownership (I'm talking about the working copy files) to 
> apache:devops, so owned by user apache and group devops, and I run "svn 
> revert -R .", it lists out every single file. Nothing changes, it just says 
> "Reverted xxx.php" for every file, every time I run it.  Run "svn revert -R 
> ." again, same thing happens. None of the files have changed at all, and root 
> has write permissions. If there are local changes in the working copy, they 
> will be reverted along with all this.
>
>
> This appears to be happening when svn thinks that my user doesn't have write 
> permissions to the file. It looks like svn is trying to calculate the 
> permissions of the files by itself, and isn't factoring in root powers, ACL 
> (setfacl), or supplemental user groups. So if I set a file's permissions to 
> 666 instead of 664, it doesn't get spit out as reverted. Also, if my user 
> owns the file (this applies to root too) or my primary group owns the file, 
> it doesn't spit that file out. But being that a second group I’m a member of 
> owns the file, it gets spit out.
>
>
> Can anyone speak to this? Any help is appreciated.

Hi,

This looks a lot like: https://issues.apache.org/jira/browse/SVN-4622

However, there is no need to involve the root user. I arrived at a
similar result on my Debian box with SVN 1.10.4. The reproduction
steps are very simple: Just check out a working copy as your normal
user and then change the ownership of a file:

$ svn co https://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts
Ahook-scripts/mailer
Ahook-scripts/mailer/tests
Ahook-scripts/validate-files.py
Ahook-scripts/mailer/mailer.conf.example
Ahook-scripts/mailer/mailer.py
Ahook-scripts/mailer/tests/mailer-init.sh
Ahook-scripts/mailer/tests/mailer-t1.output
Ahook-scripts/mailer/tests/mailer.conf
Ahook-scripts/mailer/tests/mailer-t1.sh
Ahook-scripts/mailer/tests/mailer-tweak.py
Ahook-scripts/CVE-2017-9800-pre-commit.py
Ahook-scripts/reject-detected-sha1-collisions.sh
Ahook-scripts/reject-known-sha1-collisions.sh
Ahook-scripts/svn2feed.py
Ahook-scripts/svnperms.py
Ahook-scripts/control-chars.py
Ahook-scripts/validate-files.conf.example
Ahook-scripts/persist-ephemeral-txnprops.py
Ahook-scripts/validate-extensions.py
Ahook-scripts/commit-email.rb
Ahook-scripts/svnperms.conf.example
Ahook-scripts/log-police.py
Ahook-scripts/verify-po.py
Ahook-scripts/commit-access-control.pl.in
Ahook-scripts/commit-access-control.cfg.example
 U   hook-scripts
Checked out revision 1880841.
$ cd hook-scripts/
$ sudo chown nobody svnperms.conf.example
$ ls -al
total 128
drwxr-xr-x 4 nate   nate  4096 Aug 13 23:32 .
drwxr-xr-x 4 nate   nate  4096 Aug 13 23:32 ..
-rw-r--r-- 1 nate   nate  2984 Aug 13 23:32 commit-access-control.cfg.example
-rwxr-xr-x 1 nate   nate 11766 Aug 13 23:32 commit-access-control.pl.in
-rwxr-xr-x 1 nate   nate  3102 Aug 13 23:32 commit-email.rb
-rwxr-xr-x 1 nate   nate  4355 Aug 13 23:32 control-chars.py
-rwxr-xr-x 1 nate   nate  2841 Aug 13 23:32 CVE-2017-9800-pre-commit.py
-rwxr-xr-x 1 nate   nate  5192 Aug 13 23:32 log-police.py
drwxr-xr-x 3 nate   nate  4096 Aug 13 23:32 mailer
-rwxr-xr-x 1 nate   nate  2352 Aug 13 23:32 persist-ephemeral-txnprops.py
-rwxr-xr-x 1 nate   nate  1750 Aug 13 23:32 reject-detected-sha1-collisions.sh
-rwxr-xr-x 1 nate   nate  1797 Aug 13 23:32 reject-known-sha1-collisions.sh
drwxr-xr-x 4 nate   nate  4096 Aug 13 23:32 .svn
-rwxr-xr-x 1 nate   nate 16726 Aug 13 23:32 svn2feed.py
-rw-r--r-- 1 nobody nate  3147 Aug 13 23:32 svnperms.conf.example
-rwxr-xr-x 1 nate   nate 13243 Aug 13 23:32 svnperms.py
-rwxr-xr-x 1 nate   nate  3516 Aug 13 23:32 validate-extensions.py
-rw-r--r-- 1 nate   nate  3409 Aug 13 23:32 validate-files.conf.example
-rwxr-xr-x 1 nate   nate  6669 Aug 13 23:32 validate-files.py
-rwxr-xr-x 1 nate   nate  3954 Aug 13 23:32 verify-po.py
$ svn revert -R .
Reverted 'svnperms.conf.example'
$ svn revert -R .
Reverted 'svnperms.conf.example'
$ svn revert -R .
Reverted 'svnperms.conf.example'

When reverting, nothing seems to change about the file or its
metadata. It remains owned by user 'nobody' after reverting (which is
as I'd expect).

Permissions do play a big role. Change the file's permissions to 664
and we no longer see output from 'svn revert':

$ sudo chmod 664 svnperms.conf.example
$ ls -l svnperms.conf.example
-rw-rw-r-- 1 nobody nate 3147 Aug 13 23:32 svnperms.conf.example
$ svn revert -R .

(no output here)

But change it back to 644, 

Re: How to recover from a failed update/merge?

[Nathan Hartman]

On Thu, Aug 13, 2020 at 5:47 PM Bo Berglund  wrote:

> On Mon, 10 Aug 2020 09:52:51 -0400, Nathan Hartman
>  wrote:
>
> >Again, since a revert cannot be undone, always be careful with "svn
> revert"
> >especially with "-R" (recursive)!!
>
> Thanks!
> I used TortoiseSVN to revert the 7 changed files and then I did an
> update and got the latest revision without the conflicts popping up!
>
> I did not need the recursion because it was only files from a single
> dir that were compromised.


Glad it helped. Thanks for confirming it solved the problem.

Cheers,
Nathan

Re: Building SVN from Source Code?

[Nathan Hartman]

On Wed, Aug 12, 2020 at 2:04 PM A Fry  wrote:

> After being unsuccessful in finding the person who maintains the SVN build
> for Synology, I wanted to give that a try myself.
>
> Is there a maintainers email list where I might be able to get some
> questions answered?  I'm a software developer, but... all windows, and the
> Synology build needs to be linux (from what I read).
>
> Thanks in advance.
>

The dev@ list is probably the best fit.

See
https://subversion.apache.org/mailing-lists.html

Fortunately (in your case), building on Linux (or any *nix OS) tends to be
far easier than on Windows.

Nathan

P.S.,
Any Windows devs out there: We'd appreciate help making the Windows build
more straightforward. :-)

Re: How to recover from a failed update/merge?

[Nathan Hartman]

On Mon, Aug 10, 2020 at 2:30 AM Bo Berglund  wrote:

> I have this multi-platform app in SVN thet I started in Windows but
> lately have worked on in Linux.
> The correct latest version is from Linux and I wanted to verify it on
> Windows.
>
> Everything is committed from Linux and the revision there is the
> current one.
>
> Now I made a mistake in Windows and don't know how to get out of it...
> I had started the IDE and when checking the code I realized it was not
> current, but the fact that I checked modified local files.
>
> Next mistake, I went to the command line and did an svn up to get the
> latest versions forgetting the IDE was still running, so it now
> intervened and tried to be clever about the changing files.
>
> Meanwhile svn started to offer some merge suggestions which I had
> never done before and after a while I had this mess
>
>
> So now I need to get a clean slate on the source dir in Windows, i.e I
> want to get the *repository revision* of all files in the source dir
> and not bother with bogus changes made in the messup.
>
> How should I proceed to get the wc in a state like after the last
> successful update so it can now be updated to the repository head
> revision?


So, if I understand correctly, you want to throw away *all* modifications
in your working copy. In a situation like this, I would shut down the IDE
so that it won't interfere, and from the topmost directory of the working
copy, do:

$ svn revert -R .

That will recursively revert *all* local changes to versioned files and
directories, including any changes you might want to keep, so always think
very carefully before you use it!!

After reverting all changes, "svn status" should show no versioned files
modified. You might still have unversioned local files. You'll need to
decide whether to keep them or not.

Now, you should be able to "svn update" to get the latest repository
revision.

Again, since a revert cannot be undone, always be careful with "svn revert"
especially with "-R" (recursive)!!

Nathan

Re: Getting strange error when updating on Linux

[Nathan Hartman]

On Fri, Aug 7, 2020 at 2:22 PM Bo Berglund  wrote:

>
> Thanks!
> I did this:
> sudo apt install gnome-keyring
>
> and now when I used svn up again it did show a password dialog where I
> could select to save the password too.
> And no more error messages!
> Thanks again!


Glad to help! Thanks for confirming the fix.

Cheers,
Nathan

Re: Getting strange error when updating on Linux

[Nathan Hartman]

On Fri, Aug 7, 2020 at 8:58 AM Bo Berglund  wrote:

> ** Message: 14:45:45.612: Remote error from secret service:
> org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.freedesktop.secrets was not provided by any .service files


I think it is trying to cache/lookup your password in gnome-keyring, but
for some reason that package is not installed.

Nathan