Re: Migrate from Git to SVN on Fedora server

[Nico Kadel-Garcia]

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.

Why? What do you expect to get from Nginx that is not built into
Subversion's httpd integration?

Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Nico Kadel-Garcia]

How did you upgrade your server from RHEL 6 to RHEL 8? Did you run
"svnadmin upgrade" on the repo?  And just how *big* is the repo? Does
your client setup work with a notably smaller repo? And do the
problems happen if you use svn:// rather than https:// ? Because I've
been dealing with Subversion for a long time, and I have up on the
httpd integration years ago, The complex integration with an
overmuscled and constantly evolving, feature evolving webserver was
not something I bother with anymore, and it has big problems with big
repos, including its own repo over at http://svn.apache.org/repos/asf,
which can't be reliably synced anymore because it's gotten so large.

On Fri, May 10, 2024 at 4:17 PM Williams, James P. {Jim} (JSC-CD4)[KBR
Wyle Services, LLC] via users  wrote:
>
> I'm upgrading an Apache HTTP server of our SVN repos on RedHat Enterprise 
> Linux 8.  Using Subversion 1.14.1, svn checkout of even a small, simple repo 
> with about 150 files hangs about 90% of the time, crashes 5%, and succeeds 
> 5%.  Given enough time, the hangs eventually time out after checking out much 
> of the repo.  A debugger shows the following stack during the hang.
>
>
>
>   #0  epoll_wait   /usr/lib64/libc.so.6
>
>   #1  impl_pollset_poll/usr/lib64/libapr-1.so.0
>
>   #2  serf_context_run /usr/lib64/libserf-1.so.0
>
>   #3  svn_ra_serf.context_run  /usr/lib64/libsvn_ra_serf-1.so.0
>
>   #4  finish_report/usr/lib64/libsvn_ra_serf-1.so.0
>
>   #5  svn_wc_crawl_revisions5  /usr/lib64/libsvn_wc-1.so.0
>
>   #6  update_internal.isra /usr/lib64/libsvn_client-1.so.0
>
>   #7  svn_client.update_internal   /usr/lib64/libsvn_client-1.so.0
>
>   #8  svn_client.checkout_internal /usr/lib64/libsvn_client-1.so.0
>
>   #9  svn_client_checkout3 /usr/lib64/libsvn_client-1.so.0
>
>   #10 svn_cl.checkout
>
>   #11 sub_main
>
>   #12 main
>
>
>
> strace shows repeated calls to epoll_wait about 1 sec apart.
>
>
>
> When the checkout crashes, it's a SIGSEGV with this stack,
>
>
>
>   #0  apr_pool_create_ex(libapr-1.so.0)
>
>   #1  svn_pool_create_ex(libsvn_subr-1.so.0)
>
>   #2  update_opened (libsvn_ra_serf-1.so.0)
>
>   #3  expat_start   (libsvn_ra_serf-1.so.0)
>
>   #4  expat_start_handler   (libsvn_subr-1.so.0)
>
>   #5  doContent (libexpat.so.1)
>
>   #6  contentProcessor  (libexpat.so.1)
>
>   #7  XML_ParseBuffer   (libexpat.so.1)
>
>   #8  svn_xml_parse (libsvn_subr-1.so.0)
>
>  #9  expat_response_handler(libsvn_ra_serf-1.so.0)
>
>   #10 process_buffer.isra.9 (libsvn_ra_serf-1.so.0)
>
>   #11 finish_report (libsvn_ra_serf-1.so.0)
>
>   #12 svn_wc_crawl_revisions5   (libsvn_wc-1.so.0)
>
>   #13 update_internal.isra.0(libsvn_client-1.so.0)
>
>   #14 svn_client__update_internal   (libsvn_client-1.so.0)
>
>   #15 svn_client__checkout_internal (libsvn_client-1.so.0)
>
>   #16 svn_client_checkout3  (libsvn_client-1.so.0)
>
>   #17 svn_cl__checkout  (svn)
>
>   #18 sub_main  (svn)
>
>   #19 main  (svn)
>
>   #20 __libc_start_main (libc.so.6)
>
>   #21 _start(svn)
>
>
>
> or this one,
>
>
>
>   #0  apr_allocator_alloc  (libapr-1.so.0)
>
>   #1  serf_bucket_mem_alloc(libserf-1.so.0)
>
>   #2  serf_bucket_response_create  (libserf-1.so.0)
>
>   #3  serf.process_connection  (libserf-1.so.0)
>
>   #4  serf_event_trigger   (libserf-1.so.0)
>
>   #5  serf_context_run (libserf-1.so.0)
>
>   #6  svn_ra_serf.context_run  (libsvn_ra_serf-1.so.0)
>
>   #7  finish_report(libsvn_ra_serf-1.so.0)
>
>   #8  svn_wc_crawl_revisions5  (libsvn_wc-1.so.0)
>
>   #9  update_internal.isra (libsvn_client-1.so.0)
>
>   #10 svn_client.update_internal   (libsvn_client-1.so.0)
>
>   #11 svn_client.checkout_internal (libsvn_client-1.so.0)
>
>   #12 svn_client_checkout3 (libsvn_client-1.so.0)
>
>   #13 svn_cl.checkout  (svn)
>
>   #14 sub_main (svn)
>
>   #15 main (svn)
>
>
>
> After a failure, I'm left with a half-checked out working copy with many 
> locks.  I can complete it with svn cleanup and another svn checkout, but 
> that's not realistic for our CI/CD or general use.  Server logs show no 
> indication of a problem; the server appears healthy.
>
>
>
> I've tried a million things before submitting this bug report, read half a 
> million posts and searches, but haven't been able to get past this.  I'd sure 
> appreciate any ideas you have on the way forward.  Here's a bit more about my 

Re: Moved file resolution fails

[Nico Kadel-Garcia]

On Wed, Feb 14, 2024 at 4:59 PM Sands, Daniel N. via users
 wrote:

> So lesson learned:  Always make a pristine copy of the trunk before
> making ANY changes, so that there is a revision to fall back on where
> the two branches exactly match.

That's what tags are for!

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

[Nico Kadel-Garcia]

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

Merging distinct branches is... one of the things that Subversion is
not best with. I'd suggest using "git-svn" locally to play with, to
see if you can resolve the differences by first merging from the
trunk, then pull in the branches, and *then* push to the upstream
branch.


> Daniel Sahlberg
>

Re: Can't connect to github anymore

[Nico Kadel-Garcia]

On Fri, Jan 19, 2024 at 3:03 AM Olivier Sannier  wrote:

> Partial checkouts are somewhat possible with GIT but what is preventing me 
> from migrating our repository is the lack of svn:external mechanism.
> I don't want multirepos, and even then submodules are to be updated manually 
> everytime where svn:external are automatically up to date.
> And ideally, I would also need file externals support even if I could settle 
> for folder external if that's all there is.
> I looked a various solutions but none where as easy to use for developers 
> than externals when doing a "svn update" at the root of the checkout.
>
> That being said, I'd be quite happy to be proven wrong.

It's not a built-in. There are tools that have wrapped in
automatically updating subdirectories with git repos, such as
Terraform submodules. Terraform was written more to do one-time
checkouts in a CI/CD environment. It avoids the git submodule problem
of submodules being hooked to a particular commit, rather than an
easily updated branch by name, which requires a distinct update
procedure.  That is something that svn:externals handle a bit more
easily.

Re: Can't connect to github anymore

[Nico Kadel-Garcia]

On Mon, Jan 15, 2024 at 8:05 AM Branko Čibej  wrote:
>
> On 14.01.2024 20:52, Nico Kadel-Garcia wrote:
>
> On Sun, Jan 14, 2024 at 2:27 PM sean  wrote:
>
> On 2024-01-13 16:11, Nico Kadel-Garcia wrote:
>
> There are not many compelling reasons
> to use Subversion anymore, except the ability to check out only
> subdirectories from a branch and the insistence that a single central
> repository is the only source of truth.
>
> The ability to `svn lock` files is very useful if your repo has a lot of
> non-mergeable files, like say MS Office documents.

That's what a git tag is for, or a distinct and locked down repo in a submodule.

> I have never once found that feature to be useful since I first used
> Subversion back around 2001.  Mind you, I'd treat Word documents as
> binaries objects and not consider them suitable for incremental
> changes in a source control system.
>
>
> X: There's this useful feature that  has but  doesn't.
> Y: I've never used that feature so it's useless.
>
> You gotta love that kind of reasoning.

Not quite. The lack of any requirement for it in more than 20 years of
professional support of environments which used it, all of which have
now migrated to git, indicates that it's not a popular feature. It's
also a practice that can be duplicated by other means.

Re: [ANNOUNCE] Apache Subversion 1.14.3 released

[Nico Kadel-Garcia]

On Tue, Jan 16, 2024 at 4:08 PM Daniel Sahlberg
 wrote:
>
> Den mån 15 jan. 2024 kl 20:44 skrev Dunnill, Robert :
>>
>> Is a document available on how to update Apache under Subversion Edge?
>
>
> I think that Subversion Edge is no longer supported (we removed the download 
> links a while back) so you should probably update to another Subversion 
> server solution or even switching to a hosting provider. But it is probably 
> better to ask this question directly to CollabNet (now digital.ai), at least 
> if you have a commercial license.
>
> Kind regards,
> Daniel

Hosting providers such as github, are abandoning Subversion support.
It is really on its last legs:

Re: Can't connect to github anymore

[Nico Kadel-Garcia]

On Sun, Jan 14, 2024 at 2:27 PM sean  wrote:
>
> On 2024-01-13 16:11, Nico Kadel-Garcia wrote:
>
> > There are not many compelling reasons
> > to use Subversion anymore, except the ability to check out only
> > subdirectories from a branch and the insistence that a single central
> > repository is the only source of truth.
>
> The ability to `svn lock` files is very useful if your repo has a lot of
> non-mergeable files, like say MS Office documents.

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

Re: Can't connect to github anymore

[Nico Kadel-Garcia]

On Sat, Jan 13, 2024 at 4:02 PM Johan Corveleyn  wrote:
>
> On Sat, Jan 13, 2024 at 8:28 PM roger21  wrote:
> >
> > hey there
> >
> > suddenly i can't connect to github anymore (svn update or svn checkout)
> >
> > i get the following error:
> >
> > svn checkout https://github.com/roger21/fract.git
> > svn: E170013: Unable to connect to a repository at URL
> > 'https://github.com/roger21/fract.git'
> > svn: E160013: '/roger21/fract.git' path not found
>
> Apparently, GitHub has removed its support for the Subversion protocol:
>
> https://github.blog/changelog/2024-01-08-subversion-has-been-sunset/
>
> --
> Johan

The "git-svn" module has been my go-to tool for accessing legacy
Subversion repos for some time. There are not many compelling reasons
to use Subversion anymore, except the ability to check out only
subdirectories from a branch and the insistence that a single central
repository is the only source of truth.

Re: Pricing for SVN

[Nico Kadel-Garcia]

en tors 11 jan. 2024 kl 10:58 skrev :
>>
>> Hello Andreas,
>>
>>Thank you for the reply. Could you please share the pricing 
>> details for Tortoise SVN as well.


Subversion *clients*, and servers, are available in most Linux
distributions as well. Actually running the server, helping your
company set up robust failover and backup services, and helping train
your personnel to use it effectively and efficiently. that's what
skilled consultants are for. I'd also discourage you from hosting it
internally, rather than using a cloud hosted external service, unless
you can afford the time to maintain it.

If you're starting from scratch you should also look at "git" as
well, at https://github.com/ or other repositories. Even
https://sourceforge.com, which was once the go-to public Subversion
service, has been encouraging its users to migrate to git. Subversion
works well for environments with a "single source of truth" and a "no
one is allowed to work on their own without witnesses" approach to
source control, which I know a few old clients prefer. Unfortunately,
those mandatory commits are trivially staged locally with the
"git-svn" plugin, so it's become quite difficult to enforce.

Re: Queries on SVN

[Nico Kadel-Garcia]

On Mon, Jan 8, 2024 at 4:14 AM Andreas Stieger  wrote:
>
> Hello,
>
> On 2024-01-08 07:12, kiran.sm...@siliconbrains.co.in wrote:
> >
> >   o *Does Subversion support Version control for LabVIEW,
> > test-stand, AutoCAD, SolidWorks?*
> >
>
> Yes. However note that these files are not suitable for text-base
> merging as they are not code. Meaning that any version control system,
> including svn, should be configured to required locking prior to
> editing, in order to enforce a sequence in editing.

That does not match the concept of "editing the copy in the
working repository. Simultaneous work on CAD documents are always an
issue. which is why most systems encourage individual contributors to
work in distinct branches, and merge to master or create tags  from
those if and as needed. It's an adventure.


> https://svnbook.red-bean.com/nightly/en/svn.basic.version-control-basics.html#svn.basic.vsn-models.copy-merge
>
> https://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
>
>
> >   o Does Subversion automatically update revision when someone
> > makes any changes in the documents?
> >
>
> Auto-versioning is supported with WebDAV
>
> https://svnbook.red-bean.com/nightly/en/svn.webdav.html
>
> https://svnbook.red-bean.com/nightly/en/svn.webdav.autoversioning.html
>
> Andreas

It can also create issues with checksums for individual documents,
which may may have no change in content but have changes in the header
lines of the document. Auto-versioning, much like automatic
end-of-line settings, should be used cautiously.

Re: svnadmin hotcopy E150002 Destination already exists

[Nico Kadel-Garcia]

On Sat, Oct 21, 2023 at 4:53 AM Daniel Sahlberg
 wrote:
>
> Hi,
>
> A user reported the above error in the TortoiseSVN user group [1]. I advised 
> them to send it here but for some reason that doesn’t work (I’ve checked that 
> it isn’t waiting for moderation). I’m taking the liberty to copy the original 
> question below:
>
> ——
> Hey there, we do hotcopies of our repos every night. Occasionally, for some 
> time now, hotcopy fails with the following error:
>
>   svnadmin: E150002: Destination 'K:\repo01\db\locks\2ca' already exists
>
> Mostly, a second run finishes without any errors.
>
> It does not happen to the same repos every day. So the next day it could be:
>   svnadmin: E150002: Destination 'K:\repo05\db\locks\02c' already exists
> or
>   svnadmin: E150002: Destination 'K:\repo13\db\locks\039' already exists
>
> The affected locks-folders are always different.
>
> It happens to old repos that were not touched in a long time, as well as 
> currently used ones.
>
> Destination is a SMB file share on a Synology NAS (HDDs). As I see, svnadmin 
> hotcopy clears the locks-folders in the destination every time. Can it be 
> that the NAS is just too slow and cannot keep up with this process?
>
> Thanks!
> ——
> Kind regards,
> Daniel Sahlberg
>
> 1 https://groups.google.com/g/tortoisesvn/c/YxC51xgZn_8

"Old repos" hints at a lot of issues. Failing hard drives on the NAS
is one. timeouts if you're doing this on a CIFS mounted drive is
another. Why aren't you doing svnsync or an rsync based tool, rather
than svnadmin hotcopy, to reduce the burden of copying the entire
repo?

Re: Adjust revision in new repository

[Nico Kadel-Garcia]

On Mon, Sep 4, 2023 at 8:36 AM Magnus Lyrberg
 wrote:
>
> On Fri, Sep 1, 2023 at 3:15 PM Johan Corveleyn  wrote:
>>
>> On Fri, Sep 1, 2023 at 2:47 PM Magnus Lyrberg
>>  wrote:
>> > Thank you. This is very similar to our current solution. It would
>> > however be nice to avoid a lot of empty commits, hence my
>> > engagement in this list asking for alternative solutions.
>> >
>> > But perhaps there are none.
>>
>> I'm not sure, but it sounds like that would be quite a hack, and I
>> don't think it will be possible.
>>
>> The repository still has to give a sane reply if a user asks for "svn
>> update -r 2" or "svn ls https://server/svn@1;. If those revisions
>> really don't exist, what should the server answer? So I don't think
>> you can avoid creating those revisions, but you can leave them empty,
>> as suggested.
>>
>> What is the problem in having those empty revisions anyway? I assume
>> they hardly take up any diskspace. If that's the only price you have
>> to pay for having this "old cruft removed but still original
>> rev-numbers repository", it sounds like a good deal to me (and it's
>> still a correctly working repository that behaves as designed).
>
>
> Theoretically you could get the same answer from the server as when you
> ask for a revision that does not yet exist. I see your point though.
>
> There is some concern that having 18 empty commits might impact
> the performance of the repository. I assume each commit still has an entry
> in the database etc, even if it does not use a lot of disk.

Then it's time to revisit your basic architecture to point to a new
repo with a wildly reduced history, and *use tags*. Subversion was
written to preserve history and treat it as immutable. Replacing
10,000 commits with empty commits just to preserve the numbering for a
later commit is. very much against its design goals, and likely to
be much more expensive than switching to tag bsed references ASAP. I
sympathize with the desire to take what seems like a simple path, but
it sounds like you have to switch to a new repo *anyway* Take
advantage of the  opportunity to strip it for performance.

And oh, the fastest way to strip is probably to pull the repo into a
git clone, discard unwelcome branches, run "git gc ---aggressive" and
push it back to a new repo.. Subversion was not written to discard
unused history easily, git does a fair job and does pretty well
publishing back to another subversion repo.

Re: Adjust revision in new repository

[Nico Kadel-Garcia]

On Thu, Aug 31, 2023 at 8:21 AM Magnus Lyrberg
 wrote:
>
> Hello.
>
> I'm not subscribed so please CC me in any response.
>
> We have, most unfortunately and for historical reasons,
> a very hard dependency on the revision number in subversion.
>
> Our current repository has become large and unwieldy, and we
> want to move to a fresh repository. The history is not very important,
> we are ok to start from scratch, but loosing the revision number
> would be incredibly costly.

Stop. Do not pass go, do not collect $200. "Incredibly costly" is
unlikely to be as expensive as supporting a jury-rig like this. Go
back and rewrite your base software to use tags  If you can't rewrite
it, make a copy of the repo somewhere else to play with it,. And slap
the wrist of the silly person who originally decided to use revision
numbers.

And that said, you may actually be able to strip down the repo by a
large factor and set a tag to match that old revision number, skipping
right past the size issue.

Re: Use of ssh for authentication?

[Nico Kadel-Garcia]

On Mon, Jul 10, 2023 at 7:41 AM David Aldrich
 wrote:
>
> Hi
>
>
>
> We currently have around 100 svn users, all of whom are authenticated by 
> password.
>
>
>
> Password authentication is fine when using a GUI client, but at the command 
> line it becomes tedious. I have tried using Gnome keyring but it seems hard 
> to configure.

What you're encountering is a client workflow issue. And yeah, svn+ssh
based access is one way to deal.

Re: calling svnsync synchronize

[Nico Kadel-Garcia]

On Mon, Jun 26, 2023 at 6:13 AM Daniel Sahlberg
 wrote:
>
> Den fre 23 juni 2023 kl 14:55 skrev Steudel, Philipp 
> :
>>
>> Hi support,
>>
>>
>>
>> calling svnsync synchronize now ends in attached dump.
>>
>> First I got a message like “Failed to load module for FS type 'bdb' 
>> tortoise” or like
>>
>>
>>
>> svnsync: E170013: Unable to connect to a repository at URL 'file:///…'
>>
>> svnsync: E180001: Unable to open repository 'file:///…'
>>
>> svnsync: E160043: Expected FS format between '1' and '7'; found format '8'
>>
>>
>>
>> although in the file format there was a 5.
>>
>>
>>
>> I tried different numbers, but got the message above or to use 5 or 7, but 
>> after some trials now I get this hard error.
>>
>>
>>
>> How can I synchronize my repo successfully?
>
>
> Did you change anything in any of the repository files? That is not supported 
> and you have a high risk of ruining things. Please restore any changes and 
> check the original error message.
>
> You mention "bdb" and "tortoise" leading me to believe you have installed 
> TortoiseSVN and trying to access a repository in the bdb format. I don't 
> think TortoiseSVN is capable of accessing a BDB repository (since the 
> required modules are not included in the default compilation settings - maybe 
> you can get lucky if you find a really old version). Some more information on 
> the bdb format: https://subversion.apache.org/faq.html#bdb-fsfs-convert
>
> Kind regards,
> Daniel Sahlberg

TortoiseSVN uses whichever Subversion was contemporary at the time it
was built, and may include bdb support. I believe contemporary
versions include BDB support for backwards compatibility. But it
sounds like your setup is due for some updates.

Re: Maintaining a SVN 1.7 mirror without network access

[Nico Kadel-Garcia]

On Sat, Jun 3, 2023 at 2:33 AM Colcord, Scott via users
 wrote:
>
> I have a Subversion 1.7 repo.  I need to periodically mirror it to a location 
> that does not have direct net access (I can transfer a .dump file to it).
>
>
>
> One catch is that 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).  I’m fine with manually reapplying this commit 
> after each load.

Then you are always going to have split brain. *Always*, and
frequently you will have phase lag.Do you gain anything from running
these distinct repos, instead of a primary repo,a backup mirror, and a
DNS or proxy managed name for the URL or hostname mentioned in the
svn:externals ? Rather than pointing so directly to one or the other
repo?


>
> Currently, when I want to refresh the mirror, I have a sysadmin log in to the 
> mirror SVN server, delete and recreate the repo from scratch, and then load 
> the dump into it and apply the single manual commit.  This works, but is 
> pretty cumbersome, and requires an admin.
>
>
>
> 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?
>
>
>
>Thanks!
>
>
>
>
> This electronic communication and any attachments may contain confidential 
> and proprietary information of Maxar, Inc. If you are not the intended 
> recipient, or an agent or employee responsible for delivering this 
> communication to the intended recipient, or if you have received this 
> communication in error, please do not print, copy, retransmit, disseminate or 
> otherwise use the information. Please indicate to the sender that you have 
> received this communication in error, and delete the copy you received.
>
> Maxar reserves the right to monitor any electronic communication sent or 
> received by its employees, agents or representatives.

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

[Nico Kadel-Garcia]

On Thu, May 25, 2023 at 3:15 PM Daniel Sahlberg
 wrote:
>
> Den tors 25 maj 2023 kl 19:41 skrev Rahr, Jeffrey A (US) 
> :
>>
>> I am trying to build the perl swig links in Subversion 1.14.2.
>>
>> Unfortunately this is on a non internet connected system with no ability to 
>> export build logs.
>>
>>
>> Environment:
>>
>> Centos 7
>>
>> Perl 5.36.1
>>
>> Swig 4.1.1
>>
>> gcc 4.8.5

Stop there. Don't build this by hand. Get the latest working SRPM, in
order get the dependencies straightened out, and update the .spec file
from that. RHEL 7, in particular, as an incompatible sqlite library.
And RHEL is being peculiar about publishing the "libserf-devel"
package for the serf libraries.


>> make swig-pl-lib
>>
>> generates a message of "PL_current_context" undeclared on the line - # 
>> define PERL-GET-CONTEXTPL_current_context
>>
>> in the file perl/5.36.1/lib/5.36.1/x86_64-linux-thread-multi/CORE/thread.h
>>
>>
>> Anyone have any idea where PL_current_context is defined? Guessing this is 
>> more of a subversion/perl integration issue as opposed to a subversion issue 
>> and possibly a problem with the perl build and a libc (v2.17) that is no 
>> longer being updated on Centos 7.
>
>
> I'm by no means a Perl expert, but I just downloaded 5.36.1 from perl.org and 
> in this archive, the file thread.h contains the following (lines 386-388):
> [[[
> extern PERL_THREAD_LOCAL void *PL_current_context;
>
> #  define PERL_GET_CONTEXTPL_current_context
> ]]]
> (I assume the "-" in your message was mistyped.). Is it the same in your 
> thread.h? The paths you mention doesn't quite match up so maybe there is 
> something with your perl source.
>
> Kind regards,
> Daniel Sahlberg

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

[Nico Kadel-Garcia]

On Mon, Apr 17, 2023 at 9:44 PM 김성민 [넷마블에프앤씨/R빌드파트]
 wrote:
>
> 답변 감사합니다.
>
> 2023년 4월 18일 (화) 오전 5:14, Daniel Sahlberg 님이 작성:
>>
>> Den mån 17 apr. 2023 kl 17:44 skrev 김성민 [넷마블에프앤씨/R빌드파트] 
>> :
>>>
>>> hello. I am sending an e-mail because I have a question during the svn 
>>> backup process.
>>>
>>> When backing up svn, you are backing up using svnsync or dump.
>>>
>>> However, if you try to move and use the copy command or move command 
>>> provided by linux os
>>>
>>> to change only the location on the same computer (server), normal operation 
>>> is impossible.
>>>
>>> Could you please explain the reason for this?
>>
>>
>> Do I understand it correctly that you have moved the repository using mv(1)?
>>
>> In that case it depens on how you access your repository. If you are using 
>> HTTP/mod_dav_svn then you need to update your httpd configuration to point 
>> to the new location of the repository. If you are using plain svnserve you 
>> should update your service configuration. If you are accessing the 
>> repository via the file:// protocol, you can use the svn relocate command to 
>> point your working copy to the new location.
>>
>> Kind regards,
>> Daniel

*Never* just do an "mv". If the Subversion service is in the midst of
an atomic operation, especially if  you have anything exotic in
your pre and post scripts, it can be especially traumatic.

Re: Problem using svnsync on one of 10 repositories

[Nico Kadel-Garcia]

On Sat, Feb 11, 2023 at 2:46 PM Bo Berglund  wrote:

> Follow-up:
>
> 1) I did a manual run with the command including --steal-lock and it showed
> there was a stale lock that it could take over and perform the update.
> So this seems to be the way to do it.

Stealing locks should *not* be done by default.

> 2) I have now added this into the scheduled task script on the server which 
> will
> run about 12 hours from now, hopefully there will not be any problems then.
> I made a dummy change and committed it.

It should now work with the scheduled svnsync, unless you've something
quite odd breaking your lock setups.

> So tomorrow morning I will see if the backup is synced to reflect this.
>
>
> --
> Bo Berglund
> Developer in Sweden
>

Re: Revision too big to dump?

[Nico Kadel-Garcia]

On Wed, Dec 28, 2022 at 4:56 PM Ash Rubigo  wrote:
>
> This seems to be solved. Well past the troublesome revision after about
> 10 hours and 70GB of virtual memory.

Son of a... Somebody committed disk images or a suite of DVD images?
The inability to split and discard such revisions is an old issue for
a poorly handled Subversion repo.


> On 27/12/2022 22:02:53, Ash Rubigo wrote:
> > Thanks for the suggestion Jeff.
> >
> > Increased the amount of virtual memory on Windows. Previously it was
> > allocated by the system, so not sure why it didn't keep increasing as
> > needed. Anyway, the upper limit is set to 100GB now, so we'll see if
> > that is sufficient. Currently it's using 40GB after a few hours of
> > dumping this one revision with no end in sight.
> >
> > On 27/12/2022 18:13:12, Jeffrey Walton wrote:
> >> On Tue, Dec 27, 2022 at 1:05 PM Ash Rubigo  wrote:
> >>>
> >>> I'm trying to extract projects from a large repository into their own
> >>> separate repositories.
> >>>
> >>> I understand to use `svnadmin dump`, then `svndumpfilter`, and finally
> >>> `svnadmin load`.
> >>>
> >>> Trouble is during `svnadmin dump` one of the revisions results in an
> >>> 'out of memory' error. The revision in question is large, on the order
> >>> of 20GB and I only have 16GB of RAM.
> >>>
> >>> I have tried incrementally dumping, but had the same issue.
> >>>
> >>> Is it really the case that if a revision is larger than the available
> >>> RAM it cannot be dumped?
> >>
> >> Just a thought, but it does not answer the question...
> >>
> >> Use GParted, and increase the swap file to say, 64 GB. Then set
> >> swappiness to a low value, like 2. The low swappiness value will keep
> >> most stuff in RAM, and spill over to disk rarely. Most of the swap
> >> file will remain unused. But it should allow your dumps to proceed.
> >>
> >> Jeff
> >
>
> --
> Regards,
>
> Ash Rubigo

Re: filename encodings and conversion failure

[Nico Kadel-Garcia]

On Fri, Dec 23, 2022 at 4:35 PM Karl Berry  wrote:
>
> Perhaps «export LC_ALL=C.UTF-8», if your platform has that encoding?
>
> Yes, thanks, that is one of the workarounds. But that's not my
> question.
>
> My question is, why can't svn just treat the filenames as bytes? I
> remain baffled by the need to unconditionally convert to/from UTF-8 (or
> any other encoding). Nothing in my environment ("C" in all respects)
> says to do this, as far as I know.

Because filesystems don't, and Subversion is dealing with the
underlying filesystems. It's not a Subversion specific problem, git
and even rsync have some similar problems.

The most classic example is "FILE.TXT" versus "file.txt". According to
NTFS and CIFS, those are the same filename, since those case-ware but
case-insensitive filesystems. In NFS and ext4 an xfs, they're distinct
files, and committing them distinctly on Linux versions of Subversion
causes real issues on Windows based working copies.

There is no good solution for this set of problems except not to use
case-insensitive filesystems. The issues you're describing are very
similar, and are compelling reasons to avoid mixed case and, well,
anything but plain old alphanumeric ASCII in filenames. The populare
"_", "-" ,and "." are inevitable, though "." tends to cause problems
with regex expressions.

Re: filename encodings and conversion failure

[Nico Kadel-Garcia]

On Fri, Dec 23, 2022 at 3:58 AM Daniel Sahlberg
 wrote:
>
> Den tors 22 dec. 2022 kl 23:40 skrev Karl Berry :
>>
>> Clearly those UTF-8 code points cannot be "converted" by svn to the
>> 7-bit ASCII locale that is "C". Fine; I don't expect it to.  Is there a
>> way to force svn to complete the checkout anyway? That is, just check
>> out the file and let the name be whatever the bytes are. I don't
>> understand why any "conversion" by svn is necessary merely to operate on
>> files.
>
>
> Not at all related to this issue except it also concerns filenames: It is 
> possible to commit files with a filename that works on only one platform, 
> making a checkout/update fail on other platforms.
>
> Example: Commit a file with ? (questionmark) in the filename on Linux and 
> checkout the file on Windows.

Yes. The source code for HylaFAX had this exact problem, since it had
MixedCaseFileNames.c and Mixedcasefilenames.c . They can be checked
out in the same working copy on UNIX and Linux and MacOS easily, on
Windows it's not so easy due to the "case-insensitive" file systems.

Nico Kadel-Garcia



> [[[
> D:\temp>svn co https://svn.apache.org/repos/private/pmc/subversion/pr/ 
> private_wc
> [...]
> svn: E155009: Failed to run the WC DB work queue associated with 
> 'D:\temp\private_wc\YYY_folder', work item 54 (file-install XY?Z.html 1 0 1 1)
> svn: E720123: Can't move 'D:\temp\private_wc\.svn\tmp\svn-C3A15B21' to 
> 'D:\temp\private_wc\XY?Z.html': The filename, directory name, or volume label 
> syntax is incorrect.
> ]]]
>
> (The above example is from the Subversion private repository, I've masked the 
> actual folders/filenames but it should be reproducible for anyone with access 
> to the repository).
>
> This is a case where a conversion might /be/ necessary (although I don't have 
> a concrete idea of what the conversion should be). Or else these files should 
> just be ignored on checkout.
>
> I'm just mentioning this in case someone looks at the code and decides make 
> changes to the conversions.
>
> Kind regards,
> Daniel

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

[Nico Kadel-Garcia]

On Fri, Sep 23, 2022 at 7:43 AM Mark Phippard  wrote:
>
> 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?
>
> Assuming you have the disk space then there is no real upper limit.

There are practical limits. The number of file descriptors for years
or decades of irrelevant history accumulate. Bulky accidental commits,
such as large binary objects, accumulate and create burdens for backup
or high availability. And keeping around old tags that haven't been
used in years encourages re-introducing obsolete API's or errors, or
re-introduce security flaws.

> That said ... do not discount the administrative burden. Are you
> backing up your repository? Whether using dump/load, svnsync or
> hotcopy the bigger the repository the more of a burden it will be on
> these tools.
>
> If this is just about storing binary files why not consider solutions
> that were meant for that like an object storage platform like S3 or
> minio or a package manager like Maven, Nuget etc.
>
> A big negative of Subversion repositories is you cannot ever delete
> anything. Do you really need to keep all these binaries forever?
>
> Mark

Re: How to store passwords?

[Nico Kadel-Garcia]

On Sat, Aug 20, 2022 at 8:40 AM Olaf van der Spek  wrote:
>
> Op za 20 aug. 2022 om 12:39 schreef Daniel Sahlberg
> :
> >
> > Den lör 20 aug. 2022 kl 12:20 skrev Olaf van der Spek 
> > :
> > Check the available authentication credential caches:
> > [[[
> > $ svn --version
> > [...]
> > The following authentication credential caches are available:
> >
> > * Plaintext cache in /home/daniel/.subversion
> > * Gnome Keyring
> > * GPG-Agent
> > * KWallet (KDE)
> > ]]]
> >
> > If you are missing the Plaintext cache then your distribution compiled 
> > Subversion without the support for storing passwords in the plaintext 
> > cache. (The compile-time option changed in Subversion 1.12 to disable the 
> > plaintext cache unless explicitly enabled).
>
> Right, thanks!
> Does it really have to be this hard to store passwords? ;)
>
> I'm running a local svnserve, is there a better way to handle this?

Easy to use and access conflicts with secure from others, especially
the root user.

Have you considered using 'svn+ssh' based access, with ssh-agent
setups? I used those especially with tools like Jenkins, so I could
demand a pass-phrase when starting sensitive tasks.

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

[Nico Kadel-Garcia]

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?

Climbing up the directory tree past mountpoints is... well, it's a bit
dangerous.


> But, today, I installed a new server, and whenever I use subversion inside
> my home directory, I get:
>
> /home/mail#svn copy svn+ssh://svn@ASDASDASD .
> svn: E155009: Failed to run the WC DB work queue associated with 
> '/home/mail', work item 3470 (file-install home/mail/.no-spam-check 1 0 1 1)
> svn: E18: Can't move '/.svn/tmp/svn-U1XHuf' to 
> '/home/mail/.no-spam-check': Invalid cross-device link
>
> Is there a way to make subversion not assume its tmp directory is on the
> same disk as the working directory?
>
>

Re: "svn info" results in a timeout, but only when called from a specific server

[Nico Kadel-Garcia]

On Mon, Jul 18, 2022 at 8:51 AM René Ederer  wrote:
>
> Hello,
>
> I'm a little baffled by a timeout.
>
> The command I'm trying to execute is:
> svn.exe info --username U --password P --no-auth-cache 
> "http://192.168.48.249/svn/SENSO/trunk/wls_intern/wls_config_11.1/Middleware/user_projects/domains/ClassicDomain/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config/forms/registry/oracle/ab;

*Stop* using the HTTP or HTTPS based axis. The integration of it with
the various Apache or httpd renamed servers has always been error
fraught., especially when there are intervening proxies. If possible,
switch to svn+ssh based access.

That said, run some very simple commands like "curl
http://192.168.58.249; to ensure that you have correct routing that
internal, non-routable address, and you're not encountering locally
tuned firewalls or proxies.


> The repository http://192.168.48.249/svn/SENSO exists, the full path does not 
> exist.
>
> Executing this command gives me a timeout. Shortening the url by 1 character 
> changes the behaviour and I get the expected "does not exist" message.
>
>
> In detail:
> I'm trying to execute the command above on a Windows 19 Server. I'm 
> connecting to this server via RDP.
> Executing the command unexpectedly results in a timeout (apparently from a 
> proxy server) after 1 minute:
> svn: E730054: Error running context: An existing connection was forcibly 
> closed by the remote host.
>
>
> When I paste the same url into chrome (I'm opening chrome within the 
> RDP-window) , I immediately get a 404 message, as expected.
>
>
> When I shorten the URL by 1 character (from 207 to 206 characters), I 
> immediately get the expected message:
> svn: E29: Could not display info for all targets because some targets 
> don't exist
>
>
> Running the command with the unshortened url on my local computer also gives 
> me the "some targets don't exist" message (as expected).
>
>
> My svn version is "1.9.5", but the same behaviour also happened with the 
> latest version "1.14.2".
> I set the registry key 
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled
>  to 1. This had no effect.
>
> I'm out of ideas now. What could be the cause of the timeout on my server? 
> Thank you very much!
>
> Best regards,
>
>
> René

Re: What's the status of changing UUIDs of repos in working copies?

[Nico Kadel-Garcia]

On Thu, Jul 14, 2022 at 9:44 AM Daniel Shahaf  wrote:
>
> Ryan Schmidt wrote on Wed, 13 Jul 2022 21:45 +00:00:
> > [...] that way all your public users' working copies continue to work
> > as before, and you would just need to check out new working copies for
> > those hopefully fewer and more technically capable internal users who
> > were using the formerly private server with its old UUIDs.
>
> Or manually change the UUID in those working copies using sqlite3.

Or throw in the towel on trying to transform multiple simultaneous
upstream Subversion servers, and switch to git. Or switch to using a
git-svn setup to keep the upstream servers in sync

Re: Trying to install and configure Subversion on AIX

[Nico Kadel-Garcia]

On Fri, Jul 8, 2022 at 4:46 PM Werner L. Stolz  wrote:
>
> We are attempting to install and configure subversion on AIX 7.2

Stop there. AIX is... not a popular platform anymore. That said,
proceed directly to the "Red Book", at https://svnbook.red-bean.com/ .
It will walk you through the requirements for a Subversion server,
which typically has httpd or svn+xxh access to a back end service
running as a particular, non-root account.


> Unfortunately, we are not very familiar with how to configure this software.
>
> We were able to get the software installed, but we find we have the following 
> issue.
>
> Only the root user can create new repositories.  This is true no matter where 
> in the file system we attempt the operation.

Red Book. If I may suggest? Do not bother with Apache or httpd based
access, it's powerful but encourages the maintainers to waste
astonishing amounts of time doing lots and lots of other Apache
customization which is an astonishing waste of an admin's time.

> We would like to allow a set group of users to create repositories, or even 
> some single user other than root, but we
> don’t know which configuration file to edit, or what such an entry would look 
> like.
>
>  We have the following installed:
>
> subversion.ppc   1.10.8-1 @AIX_Toolbox
> git-subtree.ppc  2.35.1-1 AIX_Toolbox
> subversion-devel.ppc 1.10.8-1 AIX_Toolbox
> subversion-tools.ppc 1.10.8-1 AIX_Toolbox
> mod_dav_svn.ppc  1.10.8-1 @AIX_Toolbox
> git-svn.ppc  2.35.1-1 AIX_Toolbox

If you're able to host it offsite, I'd encourage you not to waste your
expensive engineer time and just pay for the service with the 24x7
support and consistent updates, etc.

Also, Subversion has lost a lot of its appeal with so many effective
git services available, and the ease of using them with decentralized
development. Just saying.

Nico Kadel-Garcia


> Werner Stolz
> InvestCloud, Inc.
> LOS ANGELES – NEW YORK – LONDON – GENEVA – SINGAPORE – SYDNEY – ZURICH – 
> VENICE – LUXEMBOURG – HONG KONG – TOKYO – BENGALURU – TORONTO – SAN FRANCISCO 
> – TAMPA – CARLSBAD – NEW JERSEY
> mobile: +1 331-238-3870 | office: +1 848-305-7158 | investcloud.com
>
>
>
> 
>
> Electronic Privacy Notice. This e-mail, and any attachments, contains 
> information that is, or may be, covered by electronic communications privacy 
> laws, and is also confidential and proprietary in nature. If you are not the 
> intended recipient, please be advised that you are legally prohibited from 
> retaining, using, copying, distributing, or otherwise disclosing this 
> information in any manner. Instead, please reply to the sender that you have 
> received this communication in error, and then immediately delete it. Thank 
> you in advance for your cooperation.
>
> 
>
>

Re: Moving the entire SVN instance to a newer Windows server

[Nico Kadel-Garcia]

On Mon, May 23, 2022 at 6:16 AM Morin, Michael  wrote:
>
> In my case, I have no choice in the matter of what server and OS to move to. 
> We don’t use VisualSVN. We just use Tortoise with Subversion. When we last 
> did a migration from one Windows server to another, it was a tedious process 
> of contacting the users of the repository, asking them if the repo should be 
> migrated or archived, setting a date for the migration, telling the users to 
> make any outstanding commits, locking down the repository, migrating the 
> repository, informing users of the new URL of the repository, and asking the 
> users to confirm their ability to access the repo and verifying everything 
> works as expected. This was done for each repository. This process took us 
> about 4 ½ months. I’d like to avoid taking that long this time around.

*Ouch*. Been there, done that. I'm assuming that each repo is, indeed,
an entirely distinct Subversion repo rather than all being distributed
under one master repo? That makes migration much, much safer.

> Mike Morin
>
> Senior Programmer Analyst
>
> MaineIT, Department of Administrative and Financial Services
>
> (207)592-6134
>
>

Re: Moving the entire SVN instance to a newer Windows server

[Nico Kadel-Garcia]

On Sun, May 22, 2022 at 12:02 PM Andreas Stieger  wrote:
>
>
> On 5/22/22 14:40, Nico Kadel-Garcia wrote:
> > Why would you want to move a Subversion server to a Windows system?
>
>
> Because that is what poster said they were migrating from. In existing
> deployments keeping the current authentication, logging and
> administration experience is probably more important than tweaks. So
> let's assume that this is on purpose.

>From a considerable amount of painful experience with multiple
platforms, I suggest that the Windows backups and scripting would be
better discarded and re-implemented for the Linux based environment.
Many of them may require no tweaking, depending on the Windows server
environment. System stability and security are likelier to be much
better, as is system performance. Been there, done that, have the scar
tissue.

> > Definitely activate an svnsync to allow the new service to run in
> > parallel for a while, and to avoid any split-brain issues.
>
> Only if they cannot deal with a short migration read-only or down time.

I've made that "this will be only for a moment" prediction before.
I'll leave out the rude metaphors, but the claim is usually about as
reliable as a debtor saying "the check is in the mail". Especially for
a bulky server, with bulky commits the "out of service" time can tke
hours. Never schedule a system upgrade to occur with backup and
transfer in a tight time window if you can avoid it gracefully, and
"svnsync" allows pre-synchronization with a top-up of the last few
commots at switchover time. It's normally much, much cleaner,
especially with repos that have bulky binaries among old commits.

>
> Andreas
>

Re: Moving the entire SVN instance to a newer Windows server

[Nico Kadel-Garcia]

On Sun, May 22, 2022 at 4:24 AM Andreas Stieger  wrote:
>
> Hi,
>
> On 5/18/22 16:54, Mark Phippard wrote:
> > If you can use the same DNS hostname for the new server there will be
> > no impact on your clients
>
>
> Except for possibly a change server-side certificate which may have
> changed (and not properly verified before). Can be addressed with
> testing, and it helps to use a service name instead of a host name.
>
> If you are looking to make this seamless, you can set up replication and
> write-through proxying as you move the configuration and scripts first.

Why would you want to move a Subversion server to a Windows system?
There are real performance tuning issues for either httpd or svn+ssh
based access which are more easily handled in a Linux or UNIX
environment, and high reliability and backup setups far more difficult
to resolve in a Windows environment.

Definitely activate an svnsync to allow the new service to run in
parallel for a while, and to avoid any split-brain issues.

Re: Unable to Check Out SVN Folders

[Nico Kadel-Garcia]

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

The gods only know. You've not stated what kind of server is involved,
nor any hint of whether the repo has huge commits nad may be timing
out, nor whether there is an intervening proxy. Such vagaries of
Apache bsed Subversions are one reason I prefer SSH based access. Can
you use svn+ssh?

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

Re: [EXTERNAL] Re: CollabNet Subversion devel packages

[Nico Kadel-Garcia]

On Tue, Dec 14, 2021 at 1:10 PM Grierson, David (Lead Engineer)
 wrote:
>
> Hi,
>
> (Firstly apologies for the top posting - Outlook is a PIA for that)
>
> Yes - you're correct we're running RHEL, specifically we're on RHEL7. When 
> the hosts were built they were replacing RHEL5 and RHEL7 was the latest 
> distro which was being supported internally. In order to get an up-to-date 
> installation of Subversion we looked to continue to use the CollabNet 
> Subversion RPMs which we'd previously been using.
>
> Unfortunately moving the Subversion service to RHEL8 would be a significant 
> chunk of work (and cost) so that seems unlikely. It also looks like the RHEL8 
> distribution is only at SVN 1.10, whereas the CollabNet RPMs we're on are 
> 1.11 (and in fact 1.12 is out).

This is a very old issue. RHEL releases lag, a *lot*, and Red Hat is
very hesitant to update them to avoid regression surprises. I used to
publish RPMs over at repoforge years ago, but repoforge hasn't updated
anything in years.

Unfortunately, porting subversion-1.14 has a lot of dependencies,
While it's theoretically possible to take fhe subveraion-1.14 from
RHEL 8, there's a missing sqlite version dependency that is resolved
with sqlite-amalgamation that is a pain in the keister. Unfortunately,
Collabnet doesn't elect to publish the SRPMs for their software, which
is a bit of a pain to do. You're welcome to my old tweaked tools at
https://github.com/nkadel/subversion-1.11.x-srpm , which include those
hooks for sqlite-amalgamation.


> My suspicion is that the -devel RPM is only made available to CollabNet's 
> paying customers (which makes sense).
>
> The specific issue we're having isn't actually caused by Subversion. We have 
> configured the Apache httpd component of Subversion to also provide a proxy 
> to a Nexus (NXRM) service providing Maven and Node repository hosting. We've 
> noticed that some users seem to be making use of some kind of massively 
> parallel (like 150+ connections from a single IP) download mechanism 
> (possibly "yarn" - https://yarnpkg.com/). When we receive more than a couple 
> of these they are in effect causing a DoS on the Apache httpd service. This 
> then prevents users from accessing either the Subversion or Nexus services.
>
> As Subversion generally operates via a single connection (for transfer of 
> commits, etc.) this wouldn't be affected by mod_evasive, as I'd only be 
> looking to limit the number of _simultaneous_ connections from a single IP.
>
> The alternative I'd be looking at would be splitting off the Subversion and 
> Nexus services then placing nginx in front of both of them and using that to 
> rate limit.
>
> For now I've tuned the Apache parameters to increase the MaxClients parameter 
> to accept more connections. This seems to have alleviated the issue for now 
> which should give us time to look at alternative solutions.
>
> Thanks for the swift response.
>
> Dg.
>
> -Original Message-
> From: Mark Phippard 
> Sent: 14 December 2021 12:33
> To: Grierson, David (Lead Engineer) 
> Cc: Subversion 
> Subject: [EXTERNAL] Re: CollabNet Subversion devel packages
>
> On Tue, Dec 14, 2021 at 7:00 AM Grierson, David (Lead Engineer)
>  wrote:
> >
> > Hi,
> >
> > I'm running an internal Subversion service making use of the CollabNet 
> > Subversion RPMs to provide this.
> >
> > I'm looking to introduce rate limiting to my Subversion service and so want 
> > to build mod_evasive for use within the Apache component of Subversion, to 
> > do so I need to use apxs to compile this, however the CollabNet packages 
> > don't include the "-devel" RPM and so this isn't possible.
> >
> > Does anyone know where I can get this or will I have to revert to building 
> > from Subversion from source against the system Apache?
>
> In theory if you got a version of the module built against the same
> httpd and apr versions it might work but it would probably be a good
> time to look to change things up. I assume you are on a CentOS/RedHat
> distro? Are the upstream packages new enough to use? For example, if
> you have moved to the RHEL 8.x line then the LTS version of Subversion
> is provided by the distro and would make your life a lot easier.
>
> Do you have any reason to believe mod_evasive will do what you want? A
> Subversion client doing a checkout can look a bit like a DoS attack in
> terms of sending a lot of GET requests in a short timespan.
>
> You could also stick a proxy in front of your server and do the rate
> limiting there. That could be a good way to trial this out too. As you
> could just point a specific client at the proxy to make sure svn
> operations all work OK.
>
> Mark
> 
> This email is from an external source. Please do not open attachments or 
> click links from an unknown or suspicious origin. Phishing attempts can be 
> reported by using the report message button in Outlook or sending them as an 
> 

Re: Install SVN 1.6.11 on RHEL 7.7

[Nico Kadel-Garcia]

Collabnet has the most recent releases of subversion, at
https://www.collab.net/downloads/subversion#show-Linux .

Re: Install SVN 1.6.11 on RHEL 7.7

[Nico Kadel-Garcia]

On Tue, Dec 7, 2021 at 5:16 AM Stefan Sperling  wrote:
>
> On Tue, Dec 07, 2021 at 03:19:45PM +0530, Abhishek Kumar wrote:
> > Dear Team,
> > There is a Planned Linux OS Upgradation of Server from existing version RHEL
> > 6 to RHEL 7.7 where SVN Server(SVN V1.6.11)  setup is done.
> >
> > Kindly provide the installation steps and compatibility for the same.
> >
> > *Existing*
> >
> > SVN Version Linux Version
> > V1.6.11 RHEL 6.10
> > *Planned*
> > SVN Version Linux Version
> > V1.6.11 RHEL 7.7
>
> Subversion 1.6.11 was released in April 2010 (almost 12 years ago!)
> and is affected by numerous security issues listed here:
> https://subversion.apache.org/security/
>
> You should consider upgrading SVN to a supported version, instead
> of upgrading only the RHEL system itself.
>
> For latest SVN source releases, see:
> https://subversion.apache.org/download.cgi#source-releases
>
> For SVN binary packages specific to RHEL, see:
> https://subversion.apache.org/packages.html#redhat
>
> > Looking forward to a quick reply and prompt support.
>
> This mailing list is a volunteer forum. As such, no specific guarantees
> can be made regarding support requests.
>
> Regards,
> Stefan

Some years back, I used to publish updated releases of Subversion for
the repoforge repository. I stepped away from that hobby when the
repoforge admin decided to stop adding new packages. While RHEL 7 has
subversion 1.6 built-in, my more recent RPM building tools are
available at https://github.com/nkadel/subversion-1.11.x-srpm.
Wandisco used to publish up-to-date releases. but with the loss of
popularity of Subversion, people have not spent much energy to
backport current releases to older operating systems.

Re: Migrating Apache Subversion to a new Ubuntu machine - how?

[Nico Kadel-Garcia]

On Tue, Nov 16, 2021 at 6:15 PM Bo Berglund  wrote:
>
> On Sun, 10 Oct 2021 03:42:30 -0400, Nico Kadel-Garcia  
> wrote:
>
> >> PS:
> >> Is it possible to just move the existing hard drive over to the new 
> >> computer and
> >> start it up? Or clone the content to the new computer's drive?
> >> I do have a lot of other stuff that needs migration too...
> >
> >Maybe? You'd need to mount it, and a 10 year old hard drive is
> >questionable at best. I'd use rsync: Ensure that you have SSH access
> >from the new host to the old host, and you should be able to use rsync
> >to copy material and run svnsync efficiently. And look up "svn
> >hotcopy" for copying the basic Subversion configuration for copying
> >over to a new server.
>
> UPDATE: To close this thread
>
> So I have done the migration now and it was basically painless, although time
> consuming because of the way I did it...
>
> 1) I figured out a way to create space on the new PC disk drive from within 
> the
> pre-installed Windows 10. This was the easy part. I left 40 GB for Windows 10
> and got about 450 GB free space.
>
> 2) Then I spent a bunch of time figuring out how to boot both my old PC and 
> the
> new one from USB live media.
> Turned out to be impossible on the old eMachine PC but I *could* boot it from 
> a
> DVD disk with Ubuntu ISO. But no USB drive...

I'd have mirrored that content to a VM on the Windows box. Tastes var,
but I'm glad this worked out for you.

> The new PC uses UEFI so it took a while to get the USB Ubuntu media to boot,
> until I found the correct way to modify UEFI settings to allow it.
>
> 3) Then I ran the Live DVD on my old PC and using GParted I could clone the
> partitons on that to a USB connected hard drive, I also made the partition on
> the target smaller.
>
> 4) Booting the new PC from a live USB with Ubuntu 20 I could install it in
> multi-boot fashion on the new PC in the now freed up space. I let it use just 
> as
> much partition space as is needed for Ubuntu plus a bit more.
>
> 5) Next I started Ubuntu on the new PC and using GParted I copied over the old
> PC Ubuntu partition to the new PC hard disk after connecting the USB disk to 
> it.
>
> 6) Finally once that was done I also updated the GRUB boot loader so it also
> included the old server in the boot menu.
>
> 7) With all that done I could boot into the migrated Ubuntu 18.04 server on 
> the
> new hardware and it did run!
> So I could do the apt full-upgrade to get all new stuff and it announced that 
> it
> was ready for a dist-upgrade too.
> Did that and now the server is 20.04 and all I have checked works fine.

I'm glad this also worked completely in-polace. I've run into older
filesystems with older operating systems that did not behave
gracefully when updated in plac.

> 8) Final stop:
> I now reprogrammed the port forwards on my router to go towards the new server
> rather than the old off-line server.
>
> And the next svn sync operation from the main server came through successfully
> and it is back in operation but on a new hardware system and running Ubuntu
> 20.04 rather than 18.04.
>
> My websites also work fine using the existing LetsEncrypt certificates.

Yay! I admit that I've pretty much given up on HTTPS based access to
Subversion, years ago, and use svn+ssh by preference, partly because
of tendencies of httpd admins to try and build the kitchen sink into
its configuration.

Re: Current project status

[Nico Kadel-Garcia]

On Wed, Oct 27, 2021 at 6:31 PM Luke Mauldin  wrote:
>
> We are considering using Subversion for a project with large binary files 
> since it seems to have some strengths in that area compared to the 
> alternatives. But now that the Apache Software Foundation and most other 
> projects such LLVM and FreeBSD have migrated away from Subversion, what does 
> the future of Subversion look like? Is it still being actively worked on? Is 
> anyone sponsoring it?

For me, subversion still has uses by compelling centralized change
tracking, and by permitting checkouts of very small directories from a
master repo or a designated tag.

Large binaries. just don't put those in source control. Put those
in software packaging.

Re: svn binary packages for macOS

[Nico Kadel-Garcia]

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 can vouch for this in the Red Hat world. I used to publish ports of
Subversion over at repoforge, but the various dependency updates got a
bit out of hand for me to continue after Repoforge ended. And EPEL
refuses to replace any RHEL published tools. Red Hat sometimes
publishes updates as part of their "SCL" or software collections
library, but those can be really finicky to work with.

> 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: Migrating Apache Subversion to a new Ubuntu machine - how?

[Nico Kadel-Garcia]

On Sun, Oct 10, 2021 at 2:03 AM Bo Berglund  wrote:
>
> I am running an Apache Subversion server on an oldish Ubuntu 18.04 LTS server
> and I have realized that rather than upgrading the Ubuntu installation to 
> 20.04
> I should move it to new harware (with Ubuntu Server 20.04 LTS).
>
> The existing server runs on 10 years old (at least) hardware so it is due for
> replacement.
>
> But this installation serves as a backup svn server for a main server in the
> company facilities in another location. The main server does an svnsync across
> the internet each night to keep the two repositories in step.
>
> So I figured the migration is a lot more complex than just taking a repository
> dump and then loading this into a new installation...
> Repository ID:s etc has to be maintained for example.
> The server handles 10 different rather big repositories used for different
> purposes with different aithentication of svn users.
>
> This setup was done back in 2017.
>
> Can I use rsync to move the binary repository files over from one computer to
> the other and then somehow tell the new svn where it is located?

The "Red Bean Book", is very good and goes into this sort of thing.


> On the existing server the repos are located in /var/lib/svn.
> So can I just rsync this tree between the two machines?

Mostly. Ensuring that usernames and permissions are consistent, and
that the old formats are compatible or updated to the new Subversion,
can require attention. If you have to run both at the same time, and
keep them in sync during the switchover, it needs attention.

> And how do I go about configuring the new svn that this is where the reopos 
> are?

The usual way is to use tools like "svn hotcopy"  and "svnsync" to set
them up as a master, and a slave, which you're already doing, to keep
them in sync, to keep servers in sync. Then stop write access to the
master, let svnsync catch up the slave, stop svnsync, and tell your
DNS to talk to the new master instead of the old one.

> I tried googling and found this, which outlines a move, but does not talk 
> about
> replicating users, connections, Apache integration etc:
>
> https://www.petefreitag.com/item/665.cfm

Well, yes. It's too flexible to completely script, because Apache has
gotten way, way too powerful and too flexible to simply "copy". Sure,
a simple setup can be copied, but people get cutesy with it: they set
up reverse proxies, LDAP and local authentication, filters for certain
filenames, complex privileges over branches and tags to enforce
specific workflows, failover behavior, maintenance pages, etc.

> Is this what I should do and how do I make sure the nightly svnsyncs will
> continue working?
>
> What about svn version differences?
>
> Info on my existing server version:
>
> /var/lib/svn$ svn --version
> svn, version 1.9.7 (r1800392)
>compiled Mar 28 2018, 08:49:13 on x86_64-pc-linux-gnu
>
> 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/bosse/.subversion
> * Gnome Keyring
> * GPG-Agent
> * KWallet (KDE)
>
> Grateful for advice / links to howto guides!
>
> (I will need to install Ubuntu server from scratch and then subversion and 
> then
> configure it all...)
>
> PS:
> Is it possible to just move the existing hard drive over to the new computer 
> and
> start it up? Or clone the content to the new computer's drive?
> I do have a lot of other stuff that needs migration too...

Maybe? You'd need to mount it, and a 10 year old hard drive is
questionable at best. I'd use rsync: Ensure that you have SSH access
from the new host to the old host, and you should be able to use rsync
to copy material and run svnsync efficiently. And look up "svn
hotcopy" for copying the basic Subversion configuration for copying
over to a new server.

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

Re: SVN startup questions.

[Nico Kadel-Garcia]

On Tue, Aug 17, 2021 at 5:30 AM A Z  wrote:
>
> Just some basic getting started questions about SVN.
>
> -How can a series of different branches all be merged back into one again?
> By 'adding' their checked out, now finished code content, and then committing
> them in the right order to the trunk, one at a time?

Please study the "svn merge" command. That is precisely what it is
for. A good GUI such as TortoiseSVN will help a great deal.

> -What exactly is a Tag?  I don't understand, what is it, and what
> does it represent?  Why exactly are tags used, when, apparently,
> they are near the same as branches?

Tags and branches in SVN are just copies of content from the master.
They may include only a small part of the master, they may have any
layout people want, and often people get peculiar about this. They are
really just copies of content in folders, typically alongside the
master. People often apply rules such as "no editing or renaming a
tag!!" or "no deleting tags unless you are an admin!"

> -As an SVN administrator, I want a setup where there is a main trunk,
> and all developers start with their own branch, which they may add their
> own branches to, adding and committing their updated code to, progressively,
> on their advancing sub nodes.  Only the administrator (super?) user has the
> ability to commit to the branch, from absolutely anywhere in the tree, to 
> advance
> the trunk.  The administrator then creates a new, latest trunk node, and
> new (commencing) branches from there, all being the same as before,
> all based on the latest trunk node.  Developers may never delete their
> nodes, and must ask the administrator to do so.

What you describe as the "latest trunk node" would be a "release tag".
Review the pre-commit scripts and permissions for popular setups that
do all or nearly all of what you seek.

> Can someone send an example in reply as to how I could configure
> SVN permissions to require this, in relevant .conf file(s)?

The "Red Book" gives explicit examples of how to manage tags in just
this way, at https://svnbook.red-bean.com/ . I'd encourage you to go
to that document first for questions like "what is a tag?"

Re:

[Nico Kadel-Garcia]

On Tue, Jun 22, 2021 at 8:26 AM Yakov Erlich  wrote:
>
> Hello,
>  We have used  SVN repository for several years
> Recently I got an error message "LZ4 decompression failed", importing a file 
> to SVN repository STEMS (please see link for the file.)
> https://drive.google.com/file/d/1oII9tBD8UD_rRuOCBPlbmGTQ90zgLxVm/view?usp=sharing
> I verified all our repositories and found problems.
> Details.
> We use:
>ToroiseSVN 1.14.1.
> Visual SVN: VisualSVN-Server-4.3.2-x64

Reduce the potential sources of error. Can you do the import from the
command line? And are you dealing with issues such as extremely large
commits?

> According to
> https://groups.google.com/g/tortoisesvn/c/5iZ7uIW1C8s/m/24sA3kJyAAAJ
> I run the Test-SvnRepository of my SVN and found problems in 4 repositories:
>   Test-SvnRepository * -Check LocalData
>
> Repository Name : ADuCAD9914  Error:   Svndiff contains a too-large window
> Repository Name : AlteraError:   Svndiff contains a too-large 
> window
> Repository Name : STEMS  Error:  LZ4 decompression failed
> Repository Name : Xilinx Error:  Decompression of compressed 
> data failed: no size
>
> Please help to fix the problems
>   Thanks
>  Yakov Erlich
>
>

Re: [EXT] Re: repository mirroring

[Nico Kadel-Garcia]

On Thu, Jun 17, 2021 at 9:22 AM Mark Phippard  wrote:
>
> On Thu, Jun 17, 2021 at 9:13 AM tatyana irzun  wrote:
> >
> > Hi, Mark
> >
> > How can i enable svnsync logging to debug process?
>
> Please keep replies on list. It is best to keep the audience as wide
> as possible.
>
> I am not aware of any great ways to log from a client other than using
> Wireshark. Assuming you are using http/https there might be a way to
> turn on logging in the Serf library but I do not recall how. It might
> require compiling your own version.

Also, Subversion does not perform well for extremely large binary
commits, especially when many distinct bulky, or mixed bulky and small
text changes, are in the same commit. If you're doing binary release
management as Subversion branches or tags, you may wish to rethink
this approach.

That said, the web servers for Subversion, typically httpd, are often
not configured to handle extremely large transfers well. Consider
enabling svn+ssh: it gets you away from the vagaries of intervening
web proxies and can be considerably more robust.

Re: Problem with Centos 7 RPMs

[Nico Kadel-Garcia]

On Mon, Mar 22, 2021 at 5:40 AM Matthews, David
 wrote:
>
> I been using the Subversion 1.10 RPMs provided by WANdisco on Centos 7.
>
> http://opensource.wandisco.com/centos/7/svn-1.10/RPMS/x86_64/
>
> I have 1.10.6 installed but I can’t upgrade to 1.10.7.
>
> If I try running “yum update” I get an error with package 
> subversion-python-1.10.7-1.x86_64 (WANdisco-svn):
>
> Requires: python >= 3

The heck? I suspect that should be "Requires: python3", due to the
peculiarities of RHEL 7 providing python 3.x as separately named,
parallel packages. This is not an unheard of bit of confusion when
script requirements are updated from python 2 to python 3.

I also wonder why you're using 1.10 when 1.14 is available.

Re: How to work around E000018: invalid cross-device link

[Nico Kadel-Garcia]

On Wed, Mar 10, 2021 at 10:21 AM Zhao Wu  wrote:
>
> To whom it may concern,
>
> Is it possible to put one directory in a repo on a mounted directory? We need 
> this for several reasons:
> 1. sensitive files must be kept on encrypted file system, but to put the 
> entire repo is too slow;
> 2. sometimes we want to test different versions without checking out the 
> entire repo;
> 3. we want to keep large data files in the repo on SSD instead of HDD

No.The "repo" on the server is basically, a database with a list of
all the commits referring to the content of the repo, not a filesystem
that can be split this way. I think you'll need to split the repo into
multiple repos along the lines of the security you want.

Re: How to Prevent SVN commits if the Valid number is not entered

[Nico Kadel-Garcia]

On Mon, Mar 8, 2021 at 10:03 PM Kenneth Porter  wrote:
>
> --On Monday, March 08, 2021 9:29 PM -0500 Nico Kadel-Garcia
>  wrote:
>
> > He's asking for a "pre-commit" hook. Piping little wrappers into your
> > local environment doesn't scale, doesn't automate, doesn't prevent
> > someone else using "TortoiseSVN" from overriding the desired filter,
> > etc., etc.
>
> I assumed he was running a server on Windows and that's why his pre-commit
> hook was a Windows batch file rather than a shell script. (My own server is
> on Linux+Apache so the pre-commit hook is based on the sample shell script.)

Ahh. I thought you were suggesting an SVN wrapper to use instead of
the Subversion command in his local environment. My apologies for
misunderstanding your suggestion.

Re: How to Prevent SVN commits if the Valid number is not entered

[Nico Kadel-Garcia]

He's asking for a "pre-commit" hook. Piping little wrappers into your
local environment doesn't scale, doesn't automate, doesn't prevent
someone else using "TortoiseSVN" from overriding the desired filter,
etc., etc.

There are many Google accessible answers, but perhaps our hero can
start with a classic example at
https://stackoverflow.com/questions/16751653/unable-to-generate-output-from-svn-pre-commit-hook
.

Re: Connection was forcibly closed

[Nico Kadel-Garcia]

On Fri, Mar 5, 2021 at 9:53 AM Renzo Rosales  wrote:
>
> We have a few remote users who are unable to run "svn up" to an internal 
> server in specific paths in a repository but can access others. The error is 
> "svn: E730054: Error running context: An existing connection was forcibly 
> closed by the remote host." The server is in the US and some of the users are 
> in Russia, they communicate with the server over a VPN not using NAT. If they 
> use Putty to create a SSH port forward to the server, they can run svn up 
> without error.
>
>
>
> The rule that allows traffic to traverse the VPN does not have any network 
> filtering in place. I know this server has an OS release and software dated 
> from 2011 and 2012 (details below), the httpd access logs don't show any 
> issues (HTTP code 200 and 207), the error log is bare and does not show a 
> relevant entry that shows why a sync was blocked or not permitted.
>
>
>
> What are some suggestions on where I can look to better troubleshoot the 
> issue? Would a packet capture help me identify what is going on? If so, what 
> should I look for in the capture?

Fedora 15? That is 10 years old. Don't even waste time trying to tune
this, you need to update your base OS for any exposed server, and your
exposed httpd and subversion. Don't waste your time tuning your
obsolete versions until you've done the basic server updates. If you
still have the problem after that, you should be able to get help
tuning a version that is still supported.

That said, HTTP and HTTPS connections are often "helped" by proxies
that are not tuned for really bulky transmissions such as uploading
oversized Subversion commits, especially because many proxy owners
want to *block* their clients from uploading bulky content and
actively hinder long connections. If you're faced with such proxy
difficulties, use svn+SSH rather than HTTPS.

Nico Kadel-Garcia

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)

[Nico Kadel-Garcia]

On Tue, Feb 23, 2021 at 3:15 PM Branko Čibej  wrote:
>
> On 23.02.2021 17:46, Daniel Shahaf wrote:
> > If a cron job needs authentication, its credentials need to be stored
> > somewhere, either in plaintext or in "as good as" plaintext.  I think
> > storing the passwords in unobfuscated plaintext was a deliberate
> > decision, informed by CVS's design choices in this regard, but I wasn't
> > around in the early days.
>
> It was deliberate. Reading those passwords requires access to the
> filesystem, so an attacker either has the affected user's credentials --
> in which case they probably have access to any encrypted password store
> as well -- or they're root, and in _that_ case all bets are off anyway.

Sadly, with docker, VM's, filesystem snapshots ,and home directories
on NFS shares exported to the world at large without Kerberos
authenticaiton (which I saw a bunch of computer science professors at
MIT insist on, until finally MIT's IT group stepped on them for it and
shoved them behind NAT), it's too easy to steal such credentials.

> Note that recently operating systems have gone in the direction of _not_
> letting root do everything without extra checks, so maybe the second
> assumption needs to be reconsidered.
>
> In any case, encrypted or otherwise protected password stores have
> master passwords that have to be stored somewhere for unattended
> operation, so that's just moving the problem one level of indirection away.

No. They don'.t. A session can be unlocked with which the live user or
service user can make a successful connection. The private key lives
in RAM, not on disk, and the key needs to be unlocked at user login or
at system start. This was what the old "keychain" perl script provided
along with ssh-agent.

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

[Nico Kadel-Garcia]

Sorry for message without content, re-sending with content.

> On Mon, Feb 22, 2021 at 3:25 PM Yasuhito FUTATSUKI

> > If you want to use ssh key other than default key or alternative tcp port
> > other than 22, you can use them by overriding ssh tunnel setting with 
> > SVN_SSH
> > environment variable or config file, etc. (Of course, if you want to use non
> > standard port for ssh connection you also need to change configuration of
> > sshd on server side).

No. SSh keys without passphrases are much like Post-it notes with
passwords on them, or stored passwords in Subversion. Tools that can
write to a source control without anyone unlocking the key are quite
dangerous.

It's straightforward to use ssh-agent to unlock and store access to
the key after a server is booted, but requiring a console to set up
*once* and save long-term. The old "keychain" tool works quite well
for this, and can enable ephemereal access to a live ssh-agent as
needed. For automated build tools like Jenkins, they can even store
the private key internally, encrypted with the SSH server's
encryption, and restricted to certain Jenkins "folders" for project
specific access. I use this approach regularly for Jenkins and source
control.

SSH access is also vulnerable to changing host keys in DHCP based
environments. Do look up SSH hostkeys and the keyword "/dev/null" to
find many notes about how to disable this, including ones I've been
publishing for decades.

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

[Nico Kadel-Garcia]

On Mon, Feb 22, 2021 at 3:25 PM Yasuhito FUTATSUKI
 wrote:
>
> Hello,
>
> On 2021/02/23 2:40, 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.
>
> For this purpose, I'm just using svn+ssh:// with dedicated user on
> server side and public key authentication with empty pass phrase.
>
> e.g. svn+ssh://svn-ag...@svnhost.example.org/repo/
>
> On svnhost.example.org, authorized_key file for user svn-agent could be:
> [[[
> # only for svn agent via ssh. all lines shoud be started with following
> # command and option specification:
> command="/usr/bin/svnserve -t -r /base/path/to/repo 
> --tunnel-user=root-on-hostA",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty
>  ssh-ed25519 (public key A) r...@hosta.example.org
> command="/usr/bin/svnserve -t -r /base/path/to/repo 
> --tunnel-user=root-on-hostB",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty
>  ssh-ed25519 (public key B) r...@hostb.example.org
> ...
> ]]]
>
> Cf.
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
>
> If you want to use ssh key other than default key or alternative tcp port
> other than 22, you can use them by overriding ssh tunnel setting with SVN_SSH
> environment variable or config file, etc. (Of course, if you want to use non
> standard port for ssh connection you also need to change configuration of
> sshd on server side).
>
> Cheers,
> --
> Yasuhito FUTATSUKI 

Re: storing password on a server

[Nico Kadel-Garcia]

On Thu, Feb 11, 2021 at 7:55 AM Andreas Stieger  wrote:
>
> Hi,
>
> > 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?
>
> You can use an unattended configuration of Gnome Keyring, Kwallet, GPG-Agent. 
> Or client certificates for which passphrase caching is allowed.

Or "ssh-agent" with svn+ssh.

Re: GITLAB to Subversion

[Nico Kadel-Garcia]

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?

Gitlab is not git, and if you're having trouble there, I suspect
you'll have problems educating personnel and encouraging good workflow
with Subversion as well. I've had good success with migrations from
Subversion to github. I've not seen anyone try the reverse.

If you have to do this, the "git svn" command should be useful to
permit you to import from a git repository and export to a Subversion
repository. It won't bring the access control or support complex
desired layouts of branches, tags, releases, and partial repos that
Subversion may support more easily.

Re: Can I authenticate to Subversion using ssh?

[Nico Kadel-Garcia]

On Tue, Jan 19, 2021 at 5:03 AM Daniel Sahlberg
 wrote:
>
> Den tis 19 jan. 2021 kl 10:47 skrev David Aldrich 
> :
>>
>> Hi
>>
>> We run a Jenkins job that lists the branches and tags of a certain svn 
>> repository by running 'svn ls'.
>>
>> The command, of course, requires svn authentication and so a password must 
>> be provided.  Jenkins has a svn plugin which allows it to check out from svn 
>> repositories, using stored credentials, before running a job.  As far as I 
>> know, the job itself can't access those credentials. The job script could 
>> provide the password but that is very insecure. I have gotten around this in 
>> the past by using gnome keyring, but I find that very hard to install on a 
>> headless server, so I have a problem of how to provide the password.
>>
>> So my question is: is it possible to authenticate to svn, i.e. run svn 
>> commands, using ssh key-based authentication instead of using a password?
>>
>> If so, can you point me in the right direction please?
>
>
> This is possible to tunnel the connection through SSH in which case you only 
> need to authenticate the SSH connection (for example using keys). However it 
> require some support/configuration on the server side so it depends on the 
> server.
>
> The process is fairly well described in the Subversion book: 
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html

It does require some thought. It can be noticeably easier to support
than httpd and mod_dav based access, especially when a webserver is
already in place and doing a lot of production critical work.

Re: looking for svn consultant to help solve setup/config problem

[Nico Kadel-Garcia]

On Thu, Dec 3, 2020 at 4:53 PM Joe Strout  wrote:
>
> I've got a svn server running on a linux VPS.  It works, but it is often
> very very slow... like, 15 minutes to commit a 5 MB file.  Often it
> times out completely, and we have to svn cleanup and try again.

Which Subversion verison? Which Linux operating system? And how big is the repo?

One of the difficulties with Subverison is the difficulty of expunging
bulky old commits, even from branches or files that have been deleted.

> There is nothing else running on that virtual machine, and we've checked
> with the hosting company, and they claim they are not throttling our
> bandwidth.  I believe it's probably something wrong with our
> configuration.  Also we're connecting via https, because that's the
> protocol I'm most familiar with, but some other protocol might be better
> (I know the http layer brings its own limitations).  I lack the time,
> and mostly lack the background, to figure this out myself.

HTTPS has advantages of being readily available, well supported, and
rarely throttled. It has the disadvantage that it's often intermingled
with a lot of other peculiar web setups.

> I'm looking to hire somebody who knows this stuff like the back of their
> hand, to spend a few hours checking our setup, maybe helping us switch
> to another protocol, and generally making svn run like the champ that I
> know it can be.

Can't take it on, I have a job. But if you provide a few details, such
as the Subversion releases and the *size* of the repository in
question, it might provide some hints.

> (For what it's worth, I use command-line svn on Macs, and others on the
> team are using TortoiseSVN on Windows.)

Right, you have contemporary clients. Do you have shell access to the
Subversion server itself to audit it for the subversion repositories,
their size, and their subversion version? Those are the questions a
sensible consultant would want to ask.

> Thank you,
> - Joe
>
> --
> Joe Strout
> Luminary Apps, LLC
> http://www.LuminaryApps.com

Re: FW: Stack Overflow Question

[Nico Kadel-Garcia]

‪On Sun, Oct 11, 2020 at 8:57 AM ‫احسان عبیدی آشتیانی‬‎
 wrote:‬
>
> Hi
>
> We have a problem with your Subversion program. Please answer this question:
>
> AnkSVN error on updating solution: Can't write to connection: An operation 
> was attempted on something that is not a socket

Copied from my Stackoverflow comment:

Ankhsvn is abandonware. It's not had a "daily update" since 2017. I
suspect your problem is there, and you need to look for a supported
tool to replace it.

Re: Note from Vibin Bruno to your Facebook Page Subversion.

[Nico Kadel-Garcia]

On Tue, Sep 22, 2020 at 4:09 PM Vibin Bruno  wrote:
>
> Kindly help in resolving the below vulnerabilities
>
> On Mon, Sep 21, 2020, 02:06 Vibin Bruno  wrote:
>>
>> Hi Team,
>>
>> Our security team has raised below vulnerabilities in SVN.
>>
>> 1. Concurrent login allowed in SVN console - same user can login to the 
>> console same time using two machines.

This is not a vulnerability. It's a feature. Sessions using SSH keys
or credentials may be automated for continuous integration systems to
simultaneously permit dozens or hundreds of simultaneous sessions.
It's not a Subversion problem per se, it's built into the transport
mechanisms such as SSH sessions for svn+ssh, the svnserve daemon, or
the httpd daemon for mod_svn access. It's not built for
single-threaded operation, though I suppose with httpd you could set
it up that way.

>> 2.
>> Brute Force attack - user should be locked after 3 incorrect login attempts.

That's a back end authentication, typically built into the Kerberos
based authentication of tools like Active Directory or other LDAP and
Kerberos systems, not a Subversion issue which httpd and svnserve and
SSH access can use. I suggest that you find whoever is telling you to
resolve these issues and enroll them in some courses on how password
based authentication normally works.

>> Kindly help us in resolving the above vulnerabilities.

These are not Subversion issues. They are authentication back end
issues, most of them easily configured for a desired policy. Who is
calling these "vulnerabilities"? It's like saying that having a window
that opens is a vulnerability, it's how the systems normally work.

Nico Kadel-Garcia

>>
>> Regards,
>> Micheal
>> 867405

Re: SVN 1.4 doesn't run on Windows 2019 core

[Nico Kadel-Garcia]

On Tue, Jul 14, 2020 at 6:32 AM Neil Sleightholm  wrote:
>
> I have found the issue, it wasn’t specially Windows 2019 core but could 
> happen on any version and isn’t an SVN bug. The TortoiseSVN 1.14 installer 
> was removing libapr_tsvn.dll and libaprutil_tsvn.dll on upgrade but not a 
> clean install, repairing the installing will fix it and according to the link 
> below it will be fixed in patch soon.
>
> https://stackoverflow.com/questions/62392862/missing-tortoisesvn-context-menu-after-upgrading-to-1-14-0

The title about subversion 1.4 was also a bit confusing. The
Subversion 1.14 embedded in TortoisSVN is, well, a bit of a different
issue: I wondered where the devil you were getting version 1.4 from.

Re: upgrading from repo format 1

[Nico Kadel-Garcia]

On Sat, Jun 27, 2020 at 9:06 AM Ben Elliston  wrote:
>
> I was a very early SVN user. I have a repo last timestamped January
> 2003 that I want to get files and data out of. When I run svn upgrade,
> I get:

The year is pretty irrelevant. But the version of subversion on your
old server is, and the modern subversion may not support the obsolete
format.

What version of subversion on what operating system was your original
server? And what are you tyring to upgrade to?

> svnadmin: E165005: Expected repository format '3' or '5'; found format '1'

See above. There are obsolete versions of subversion on various
obsolete operating systems, which may be possible to virtualize easily
to gain access ot old software rather than recompoiling.

Re: CentOS 8 Python bindings - opensource.wandisco.com

[Nico Kadel-Garcia]

On Sat, Apr 11, 2020 at 3:21 PM Jarkko Hyvärinen
 wrote:
>
> Hi
>
>
>
> I have installed Subversion 1.10.6 and python bindings (subversion-python) to 
> CentOS 8 server from opensource.wandisco.com repo. My goal is to get Trac and 
> Subversion working with CentOS 8.
>
>
>
> After installation I encoutered two problems with python bindings:
>
>
>
> If I run > ’python2 -c "from svn import core"’
>
> then ’ImportError: No module named _core’ raises
>
> If I specify PYTHONHOME and PYTHONPATH > ’PYTHONHOME=/usr 
> PYTHONPATH=/usr/lib64/python2.7/site-packages/libsvn/ python2 -c "from svn 
> import core"’
>
> then ’ImportError: /usr/lib64/libsvn_swig_py-1.so.0: undefined symbol: 
> PyUnicode_FromFormat’ raises
>
>i.  It 
> seems that our CentOS 8 server has ’PyUnicodeUCS4_FromFormat’ instead of 
> ’PyUnicode_FromFormat’
>
>
>
> Is there currently any workaround to this without building Subversion from 
> source cod

Use python 3. Python 2 was partially, and poorly, abandoned for RHEL
8 and it's being phased out of RHEL 7 painfully and slowly. Take  good
look at the Fedora SRPM's if you wnt to backport to RHEL 8. It's
tricky business. I used to publish the rpmforge RPMs for Subversion,
and backporting got *paindul* due to various library dependencies
which notably exceeded those of the OS.

Re: Upgrade of SVN server from RHEL 6 to RHEL 7

[Nico Kadel-Garcia]

On Mon, Mar 30, 2020 at 10:07 AM Dheeraj  wrote:
>
> Hi
>
> I use SVN as a configuration management tool in our premise. The application 
> configuration file for the software comes from SVN (we have many instances of 
> apps running and is managed by multiple users)
> I have done the upgrade of SVN server from RHEL 6 to RHEL 7.
> I use kerberos authentication for the SVN setup. I have completed the sync of 
> repos to the new server.
> I have an alias svn-server.come pointing to existing server  and want to 
> point to the new server.
> What all precautions should I take, so that it wont hamper my production.
> Once I do a migration will it have any impact on commit/svn up etc?

I think you're already in trouble. RHEL 6 was obsolete, RHEL 7 is
pretty long in the tooth, and RHEL 8 is available and working. RHEL 8
has Subversion 1.10 built in. Save yourself a lot of pain in a what
you say is a Kerberized environment by at least upgrading to
Subversion 1.10.

I used to publish Subversion backports for current releases to RHEL,
but the last one was https://github.com/nkadel/subversion-1.11.x-srpm
.

Re: Remove revision range from repository

[Nico Kadel-Garcia]

On Thu, Dec 5, 2019 at 5:00 AM Josef Wolf  wrote:
>
> Hello,
>
> I need to permanently remove a range of revisions from a repository, which are
> not the latest.
>
> None of the working copies have such a revision checked out (I guess, that
> might be a show-stopper).

I'd urge you to to lock the old repository, build a new subversion
repository using "svnadmin dump", "svndumpfilter", and "svnadmin
load". Then switch your users to the new repository. Thatwill make
clear to your clients that are, in fact, using a different repository
with a different history and avoid confusion. Subversion is *very
picky* about deleting history, and there are philosophical and
security reasons to hinder the alteration of history as you are
looking for.

It sounds like you really want the "obliterate" feature to delete
accidentally committed sensitive files, which has never been
successfully done.

> I know, I can do:
>
> # svnadmin dump /original/repo -r0:1234  > /path/to/dumpfile_1.dmp
> # svnadmin dump /original/repo -r2345:HEAD --incremental > 
> /path/to/dumpfile_2.dmp
> # svnadmin create /new/repo
> # svnadmin load /new/repo <  /path/to/dumpfile_1.dmp
> # svnadmin load /new/repo <  /path/to/dumpfile_2.dmp
>
> But that would renumber the revisions of the second load command.

Why are you using "--incremental" ?

> Is there any way to insert empty revisions, so that the revision numbers would
> be stable?
>
> BTW: I guess, I'd need to set the uuid to the uuid of the old repository if I
>  don'w want existing working copies to get into trouble?

The way you fix this is to *not use any* existing working copies. Make
people check out a new copy with the new uuid. You have zero control
over whether a working copy has those deleted revisisions.

I went through this with a bad commit in a source tree for a stock
exchange, and the cleanup when I failed to switch repos wasn't pretty.

Re: Limit on Number of Users

[Nico Kadel-Garcia]

On Fri, Oct 18, 2019 at 3:29 AM Ryan Schmidt
 wrote:
> On Oct 17, 2019, at 14:27, Shamoon, Danial wrote:
>
> > I’m using These pages:
> >
> > 
> > 
> >
> > Do these come with the free version?  And thanks for your quick reply!
>
> No, those pages say "Subversion Edge" which is a separate product:
>
> https://www.collab.net/products/subversion
>
> The open-source free Subversion does not come with a web interface like that.

Subversion Edge is from CollabNet, who employ some core Subversion
developers and make a pretty good commercial product. If you need
commercial support, I'd talk to them. And for licensing help, I'd
certainly talk to them.

Re: Trying to build svn 1.12.2 from tarball

[Nico Kadel-Garcia]

On Wed, Sep 4, 2019 at 9:21 AM swdev  wrote:
>
> I downloaded serf-1.3.9 and built it using
> scons APR=/home/jonny/subversion APU=/home/jonny/subversion 
> ZLIB=/home/jonny/subversion OPENSSL=/home/jonny/subversion 
> PREFIX=/home/jonny/subversion
> I then ran a scons check and got the following
> There were 14 failures:

If you're going through this many layers and layers of work and
debugging, it's time to seriously reconsider your project. Unless
someone is paying you hourly, what is justifying this much to work to
personally build the latest greatest? Can't you use the most recent
packaged version of the code, or reach out to their authors and ask
about their build environments?

The layers of building up the dependency trees are why I basically
gave up on doing my own Subversion RPM updates after 1.11 came out.
Jugglinig dependencies became pretty awkward.

Re: Trying to build svn 1.12.2 from tarball

[Nico Kadel-Garcia]

On Tue, Sep 3, 2019 at 10:20 PM Daniel Shahaf  wrote:
>
> swdev wrote on Tue, 03 Sep 2019 13:40 +00:00:
> > SERF (from get-deps.sh)
> > 
> > cd serf
> > # clean the build
> > scons -c
> > scons APR=/home/jonny/subversion APU=/home/jonny/subversion
> > ZLIB=/home/jonny/subversion OPENSSL=/home/jonny/subversion
> > PREFIX=/home/jonny/subversion
> >
> >
> > APR, APR-UTIL, ZLIB and OPENSSL all built and installed successfully
> > and passed their own tests.
> >
> > When building SERF, I ran into the following errors
> >
> ⋮
> > Any ideas as to how I can build SERF?
>
> Try asking on the Serf mailing list, d...@serf.apache.org (serf doesn't use a 
> separate users@ list).

And try including what operating system you're starting from. Porting
current releases of Subversion to RHEL became a hell of a lot more
work than anyone was paying me for, which was nothing, so I gave up
some years back. If you need my last remnants of build tools, you
might look at httpg://github.com/nkadel/ for various obvious
subversion releases.and sanitized get-deps.sh.

> Good luck,
>
> Daniel

Re: Decompression of svndiff data failed

[Nico Kadel-Garcia]

Your history is toast. Stop burning cycles. Lock your working server, Take 
clean working copies of the important branches if you can get them, the clean 
working copies, import them to a new server, and start with a much lighter 
working repository.

And *stop* putting binaries in the same repository as source code. History is 
usually much more important for source, binaries harshly burden all source 
control systems, and even the smallest errors corrupt them irretrievably. If 
you *must* store binaries, be sure to commit them in entirely distinct commits 
from the source code, to avoid precisely this problem,

Sent from my iPhone

Re: Remote renames create subtree mergeinfo

[Nico Kadel-Garcia]

On Tue, Aug 27, 2019 at 12:42 PM  wrote:
>
> FWIW, I found the explanations in these two emails from the same thread to be 
> easier to understand as a user:
> https://svn.haxx.se/users/archive-2010-11/0408.shtml
> https://svn.haxx.se/users/archive-2010-11/0466.shtml
>
> This sounds like yet another UX flaw caused by the constraints of 
> subversion's characteristic "flexibility" afforded by its nearly-complete 
> agnosticism regarding repository branching and tagging structure. As I use 
> git more and more for all of my daily development, I continue to run into UX 
> problems like this that are made so much less helpful and more surprising, 
> all in the name of that ultimate "everything is just a sub-tree" flexibility. 
> I am coming to strongly believe that this design paradigm is SVN's fatal flaw 
> keeping it from being the best long-term centralized VCS competitor to git & 
> other DVCSes.

You are a decade late for that discussion. Enforcing  other system's
architecture on top of Subversion would break the very reasons people
still use it.

Re: Questions about a script for regular backups

[Nico Kadel-Garcia]

On Thu, Aug 22, 2019 at 9:52 AM Anton Shepelev  wrote:
>
> [replying via Gmane]
>
> Andreas Stieger:
>
> >The dump format is not the best option for backups. The
> >restore time is much too slow as you need to recover from a
> >serialized format. In many hand-baked scripts the dump
> >method misses point-in-time recovery capabilities, ->
>
> Why should I need those if SVN repositories store the
> complete history?

Because, on a bulky repository with bulky binaries, it is *butt slow*,
you can't easily prune the bulky binaries, and you will inevitably
have split-brain during time between the dump and the next dump/load.
Split-brain Is Not Your Friend(tm).

Re: SVN repository("db") permissions has been reverted after performing the commit

[Nico Kadel-Garcia]

You need to get off RHEL 6. The subversion there is now outrageously old, and 
cannot be gracefully upgraded to a supported release. I know because I tried, I 
used to publish the repoforge packages for subversion. That said I’d check your 
subversion for known bugs, the umask for the httpd user or svnserve daemon 
owner or svn+ssh access, and system problems like failing storage. 

Sent from my iPhone

> On Jul 24, 2019, at 1:20 AM, ramesh penumalli  wrote:
> 
> Dear Team,
> 
> We have  installed scm-manager ( V1.6) on our RHEL6  server  and configure 
> SVN repositories. When we tried to commit the code into any  svn repository, 
> then permissions of  the files "current" and "txn-current"  under the folder 
> "db"  of  the repository are changing to 600 (-rw-.)  from 774.
> 
> Due to this permissions issue, the SVN repository is failing to connect 
> corresponding repository in Fisheye and then users are unable to see their 
> code reviews in Fisheye and Crucible servers.
> 
> I would your quick help to find the root cause of the issue and the 
> resolution steps to resolve the query. 
> 
> Kindly let me know in case if you would need any information to resolve this 
> issue.
> 
> Thanks and Regards,
> Ramesh Penuballi

Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?

[Nico Kadel-Garcia]

On Sat, Jul 20, 2019 at 2:54 PM Daniel Shahaf  wrote:
>
> Stefan Sperling wrote on Sat, 20 Jul 2019 09:51 +00:00:
> > But as a user I find it infuriating when software I use contains
> > artificial restrictions like this. We should assume our users know
> > what they are doing. Subversion is not a web browser.
>
> I'm not entirely sure I'm convinced by this logic.  Let's take OpenSSH for 
> example:
>
> [[[
> % ed .ssh/known_hosts
> g/^hermes/d
> s/^[^ ]*/hermes.apache.org/
> w
> q
> % ssh hermes.apache.org
> @@@
> @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
> @@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> Someone could be eavesdropping on you right now (man-in-the-middle attack)!
> It is also possible that a host key has just been changed.
> The fingerprint for the ECDSA key sent by the remote host is
> SHA256:gJUlDrKOTnUQ/lAx6eM4Ylq6z/5ere2tJoLEgrfM++A.
> Please contact your system administrator.
> Add correct host key in /home/daniel/.ssh/known_hosts to get rid of this 
> message.
> Offending ECDSA key in /home/daniel/.ssh/known_hosts:26
>   remove with:
>   ssh-keygen -f "/home/daniel/.ssh/known_hosts" -R hermes.apache.org
> ECDSA host key for hermes.apache.org has changed and you have requested 
> strict checking.
> Host key verification failed.
> zsh: exit 255   ssh hermes.apache.org
> ]]]
>
> The error message does not give a way to continue the operation, but it
> does tell you what command to run if you would like to proceed anyway.
> This way, the buck stops with the user, but the program makes it quite
> clear that this is an abnormal situation and caution should be
> exercised.
>
> Should we do something similar (but without the all-caps?  That's why
> I proposed writing a command that takes a certificate on stdin and marks
> it as trusted.

OpenSSH is an interesting example. The "known_hosts" file has been an
active detriment to DHCP based environments, where the same machine
may be rebuilt with the same hostname but a different IP address or
different hostkeys, for decades. The easy solution is to discard the
use of known_hosts, as documented all over the web, but summed up best
by these entries in /etc/ssh/ssh_config or in $HOME/.ssh/config

Host *
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
LogLevel ERROR

This trick is most useful in environments where people use svn+ssh and
the IP address of the Subversion server may change at unpredictable
times. It's also very useful for Jenkins, and Ansible, tasks that may
reach out to a Subversion server and don't want to have the
known_hosts fuss on a regular basis. known_hosts, like SSL certificat
signatures, has its security uses. But it has often proven a burden
rather than a blessing.

Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?

[Nico Kadel-Garcia]

On Fri, Jul 19, 2019 at 7:41 AM Pierre Fourès  wrote:
>
> Hi all,
>
> I have a script accessing an old svn server whom SSL certificate have
> expired a long time ago. Up to now, I was permanently accepting the
> certificate on the first run of the script and then everything was
> sailling smooth. I reinstalled a couple of months ago a new box where
> this script was intented to run and the (p)ermanently option seems not
> provided anymore.

Negotiating certificate trust can be fun. Can you sidestep the whole
issue by switching to svn+sh? Or get new, signed certificates?

> Thankfully, I still have the "old" running box to double-check, and
> the (p)ermanently option is still present. Both boxes are Debian
> Buster (but was installed as unstable, before the official release).
> The (p)ermanently option was also present in svn on previous versions
> of Debian.
>
> I can notice that the versions of svn changed between my old and new
> box from 1.10.2 to 1.10.4. Nonetheless, I gave a look at the
> change-log [1] and it doesn't seem specified this option has been
> removed. I also gave a look on openssl version and it went upgraded
> from 1.1.0h to 1.1.1b, but I have no clue to evaluate if the removal
> of the (p)ermanently option is linked or not the openssl upgrade.
>
> If some of you have an hint and an half to explain how and why this
> option disapeared, that would be really nice. I wonder if it was meant
> or not, to see where I'm headed.
>
> More over, I would really appreciate if someone could share a solution
> to still permanently accept the certificate on the new box, as for
> now, I can't use this box and the old one should soon be
> decommissioned.

Stefan has correctly pointed out ways to get your client, at run-time,
to accept failed certificates. But what is stopping you from replacing
the certificate?

> Best Regards,
> Pierre
>
> [1] https://svn.apache.org/repos/asf/subversion/tags/1.10.4/CHANGES

Re: Not able to delete a repo from the CLI for Subversion

[Nico Kadel-Garcia]

On Fri, Jun 7, 2019 at 8:39 AM Mark Phippard  wrote:
>
> > On Jun 7, 2019, at 8:15 AM, Miller, Christopher M CIV USARMY MEDCOM AISR 
> > (US)  wrote:
> >
> >
> >
> > I'm cleaning up Subversion repos that got spread out by accident and going 
> > to upgrade Subversion from v 1.6.11 to a newer version on a new RHEL7 VM.
> >
> > There are repos that were created that are either no longer used or were 
> > created haphazardly. The daemon is on and I can grep successfully from the 
> > CLI.
> >
> > I'm trying to use the following command via the CLI to delete a repo:
> >
> > svn delete -m "delete repo that is no longer needed" 
> > file:///data/svn/dept_A/test
> > svn: 'file:///data/svn/IMO' isn't in the same repository as 
> > 'file:///data/svn/dept_A/test'
> >
> > http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.delete.html
> >
> > I've also tried to use the ip address too and got this error message:
> >
> > svn rm svn://192.168.5.49/dept_A/test -m "delete repo"
> > Authentication realm:  
> > 678af798-5732-4a81-9cfb-4040117c6091
> > Password for 'user':
> > svn: 'svn://192.168.5.49/dept_A' isn't in the same repository as 
> > 'svn://192.168.5.49/dept_A/test'
> >
> > I was able to delete another repo via TortoiseSVN with no issues, and leave 
> > a comment. However I would feel more comfortable doing the cleanup the CLI.
> >
> > Can someone advise me on what I'm doing incorrectly or is there another way 
> > to do this?
>
> Subversion does not provide an API or command to delete a repository.  To 
> delete a repository you need direct access to the filesystem and you simply 
> remove the folder for the repository.  TortoiseSVN can only delete a local 
> repository where it has this sort of access.  It is not possible to do it via 
> the server protocol.
>
> Mark

In particular, it would delete the history of the repository.
Subversion design is focused on the idea that *no client* can delete
history.

Re: SVN server ( (28)No space left on device: AH00023: Couldn't create the watchdog-callback mutex )

[Nico Kadel-Garcia]

On Fri, May 10, 2019 at 3:14 AM Venkatakrishna Thumma
 wrote:
>
> Hi Team,
>
>
>
> Sometimes our SVN servers is going down and if we verify the logs we are 
> seeing below issue. But server has enough space.

Why do you think it has enough space? Is it running out of space on
the filesystem where the SVN repository lives? Are there, perhaps,
bulky files or log files that have been deleted but still take up
space on disk? This is a classic problem when allocating space on
"/var" for both Subversion and log files. And one bane of Subversion
is bulky commits of binary files, which do not compress well and are
not easily optimized as a "diff" with a teext fource file.

Is the filesystem on which the Subversion repositories live running
out of inodes? This can be reviewed with the "df" command on Linux or
UNIX systems.

Do you monitor your servers for space use? Good monitoring tools like
Nagios can really be your friend for noticing these issues before they
get out of hand.

What OS are you using for your servers, what version of Subversion,
and how do you have the filesystem laid out? What partition is your
Subversion server on?

We might be able to give good advice, but you'd need to provide a lot
more information.

Nico Kadel-Garcia

> Can someone please help us in resolving the issue.
>
>
>
>
>
> [Mon Feb 18 03:36:05.063291 2019] [auth_digest:notice] [pid 31489] AH01757: 
> generating secret for digest authentication ...
>
> [Mon Feb 18 03:36:05.063627 2019] [ssl:warn] [pid 31489] AH01873: Init: 
> Session Cache is not configured [hint: SSLSessionCache]
>
> [Mon Feb 18 03:36:05.065530 2019] [ssl:warn] [pid 31489] AH01909: 
> 443:0 server certificate does NOT include an ID which matches the 
> server name
>
> [Mon Feb 18 03:36:05.067477 2019] [lbmethod_heartbeat:notice] [pid 31489] 
> AH02282: No slotmem from mod_heartmonitor
>
> [Mon Feb 18 03:36:05.067654 2019] [core:emerg] [pid 31489] (28)No space left 
> on device: AH00023: Couldn't create the watchdog-callback mutex
>
> [Mon Feb 18 03:36:05.067735 2019] [:emerg] [pid 31489] AH00020: Configuration 
> Failed, exiting
>
> [Mon Feb 18 04:20:12.619767 2019] [ssl:warn] [pid 22058] AH01909: 
> 443:0 server certificate does NOT include an ID which matches the 
> server name
>
> [Mon Feb 18 04:20:12.621528 2019] [suexec:notice] [pid 22058] AH01232: suEXEC 
> mechanism enabled (wrapper: /usr/sbin/suexec)
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks & Regards
>
>
>
> --
>
> Venkatakrishna Thumma |  V3OPS Group
>
> Email ID :  vthu...@vitechinc.com
>
> --
>
>
>
>
> This e-mail message and any files transmitted with it may contain 
> confidential and proprietary information and are intended solely for the use 
> of the individual or entity to which they are addressed. Any unauthorized 
> review, use, disclosure or distribution is strictly prohibited. If you have 
> received this e-mail in error please notify the sender by reply email and 
> destroy all copies of the original message. Thank you for your cooperation.

Re: Any recommendations when migrating Subversion to a new RHEL7 VM? (UNCLASSIFIED)

[Nico Kadel-Garcia]

On Sun, Apr 7, 2019 at 3:07 AM Miller, Christopher M CIV USARMY MEDCOM
AISR (US)  wrote:
>
> CLASSIFICATION: UNCLASSIFIED
>
>
>
> Hello, in the next few days, I'm going to be moving a Subversion repo from 
> RHEL5 to RHEL7 and version of Subversion (1.6.11 to 1.7.14-el7).
>
>
> Here are some high level steps that I am going to take:
>
>
> * Move dumps from older server to new server
> * load the dump again into a new repository
>   $ svnadmin create /path/to/repo
>   $ svnadmin load /path/to/repo --force-uuid < repo.dmp
>
>
> How do I tell what type of Data Store the old Subversion Server is using?

You don't care.

> Do anyone have any recommendations on what Data Store to use?  Or will it 
> need to be the same as the old version?
>
> Thanks

Use the default created by the "svnadmin create" command.

Re: File capacity limitation in theory in SVN

[Nico Kadel-Garcia]

On Wed, Mar 20, 2019 at 7:53 AM Mark Phippard  wrote:
>
> Redirecting this to the users@ list where it is more appropriate.
>
> On Wed, Mar 20, 2019 at 7:33 AM sosogh  wrote:
>>
>> Hi list
>>
>> There are about 1.65T , 2.72 million files ，274 thousand folders in Samba.
>> It consist of any file types : txt , bin , pic , audio , video and so on .
>> We are considering moving it from samba to SVN.
>> And the data may grow larger and larger .
>> We wonder that is there file capacity limitation in theory in SVN?
>> or if the data is too large , will it cause any downgrade performance ?
>> Thank you !
>>
>
> There are no size limits.  That said ...
>
> *  Subversion is not a good choice to use as a file server for the simple 
> fact that you can not ever really delete anything.  Do not use Subversion 
> unless you are doing this to have version control and to store the history of 
> all files forever. That is what Subversion exists to provide.

Amen. This.. is unlikely to work well. Be prepared to fracture it
into a whole lot of distinct Subversion repositories if you want it to
perform well at all. *Nothing* will work well for a single repository
of 2.72 million files with 274 thousand folders, which hints that each
folder contains more than 1000 files and certain folders will contain
far more.

> * While there are no limits on number of files or total size, when you start 
> adding these files and folders to your repository I would strongly recommend 
> that you break it up into a lot of commits and not just one really big 
> commit.  If you do one large commit then you get a single giant revision in 
> the history and whenever you run commands like svn log that look at the 
> history it has to return this massive commit that can make those commands not 
> as nice to run as they are under normal circumstances.

Also, amen.

Re: svn problem

[Nico Kadel-Garcia]

On Wed, Mar 6, 2019 at 12:52 AM Ryan Schmidt
 wrote:

> On Feb 10, 2019, at 03:18, Chagai Nota wrote:
>
> >> Also did you try with working copy on the local computer instead of CIFS 
> >> share?
> > It’s not CIFS share its NFS share I didn’t try because the working copy 
> > most to be on share drive because e we have also grid system.
>
> There are known problems when using a Subversion working copy on a network 
> drive. You should use a local drive for Subversion working copies.

Not everyone has that option, whether because their work systems
demand that all work be done on a network drive for backup reasons, or
because local filesystems may not be large enough for a Subversion
working copy full of bulky binaries.

Re: svn problem

[Nico Kadel-Garcia]

On Tue, Feb 5, 2019 at 1:38 AM Chagai Nota  wrote:
>
> in network share
> yes every time he open new working copy after some period its happen
> bur other users no
>
>
>
> נשלח מסמארטפון ה-Samsung Galaxy שלי.

The network share is a CIFS share, and the local Subversion is old?
Older versions of Subversion had very poor performance on CIFS.

Re: Old repo backup, checkout current, lost repo, create new repo?

[Nico Kadel-Garcia]

On Mon, Dec 10, 2018 at 9:10 PM Tom Browder  wrote:
>
>
>
> On Mon, Dec 10, 2018 at 19:45 Nico Kadel-Garcia  wrote:
>>
>> On Mon, Dec 10, 2018 at 5:56 AM Tom Browder  wrote:
>> >
>> > On Mon, Dec 10, 2018 at 12:10 AM Nico Kadel-Garcia  
>> > wrote:
>> > > On Sun, Dec 9, 2018 at 6:31 PM Tom Browder  wrote:
>> > ...
>> > > > Given that history will be lost, does anyone see any problems with my 
>> > > > recovery plan?
>> > ...
>> > > If you have working copies and you don't care about history, why are
>> > > you spending any cycles on doing anything with hotcopy? You've lost
>> > > history anyway, why keep any of it?
>> >
>> > Cycles aren't important, but the size of the data is. Transferring the
>> > working copy from scratch would take a LONG time, while the bulk of
>> > the data are already there in the hotcopy.
>>
>> Under what possible conditions wound importing a single snapshot of
>> the current working copy, without history, take more time than working
>> from a hotcopy to overlay the changes on top of that hotcopy?
>
>
> I don’t know, Nico, I am a real novice at this. Your first answer didn’t help 
> because I didn’t know the ramifications of what I was trying to do.
>
> The original data, from just six months ago, was about 27 Gb, which took a 
> very long time to upload from my home computer to my remote server.  Since 
> the only hotcopy, done shortly after the repo was loaded, there has been very 
> little change, so if I could start with the hotcopy and somehow synch my 
> working copy without pushing 27 Gb again, life would be better.

??? An import of the copy of the working data has no history. Is the
*data* 27 GB, with no .svn content, 27 GB ? What in the devil are you
putting in source control?

I'm not objecting to your situation, just really confused by the
content you are dealing with.

Re: Old repo backup, checkout current, lost repo, create new repo?

[Nico Kadel-Garcia]

On Mon, Dec 10, 2018 at 5:56 AM Tom Browder  wrote:
>
> On Mon, Dec 10, 2018 at 12:10 AM Nico Kadel-Garcia  wrote:
> > On Sun, Dec 9, 2018 at 6:31 PM Tom Browder  wrote:
> ...
> > > Given that history will be lost, does anyone see any problems with my 
> > > recovery plan?
> ...
> > If you have working copies and you don't care about history, why are
> > you spending any cycles on doing anything with hotcopy? You've lost
> > history anyway, why keep any of it?
>
> Cycles aren't important, but the size of the data is. Transferring the
> working copy from scratch would take a LONG time, while the bulk of
> the data are already there in the hotcopy.

Under what possible conditions wound importing a single snapshot of
the current working copy, without history, take more time than working
from a hotcopy to overlay the changes on top of that hotcopy?

> So, again, would my plan work to re-establish my repo and work flow?

Yes, any of your solutions could work.

> Thanks.
>
> -Tom

Re: Old repo backup, checkout current, lost repo, create new repo?

[Nico Kadel-Garcia]

On Sun, Dec 9, 2018 at 6:31 PM Tom Browder  wrote:
>
> I have three svn repos I recently (6 months ago) moved to my private, remote 
> server. Due to life and negligence, I only have one svn hotcopy of two of 
> them made immediately after the move.
>
> A week ago the disk with the three repos failed.
>
> I have current copies of each repo’s trunk (I’m not not using branches) and 
> want to know the best way to get the repos back in place and working again.
>
> I am the only user, and I use the svn+ssh access to the repo completely owned 
> by myself. History is not terribly important.

Sounds like time to simply start new repos with your three projects.
Import the contents of the local working to new trunks, and move on.

> From what I can find in various docs, I think the easiest way to recover is 
> to copy the 6-month-old hot copy to the original path and resume working from 
> there as usual (plus make sure my backups work in the future!). For the other 
> I will just recreate the repo from scratch.
>
> Given that history will be lost, does anyone see any problems with my 
> recovery plan?

If you have working copies and you don't care about history, why are
you spending any cycles on doing anything with hotcopy? You've lost
history anyway, why keep any of it?

> Thanks for any advice.
>
> Best regards,
>
> -Tom
>
>

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

[Nico Kadel-Garcia]

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

If that tool supports using an upstream git repository on a Subversion
client. maybe? If that could be accomplished in some reasonable
amount of time? But I'd be *extremely* leery of connecting Subversion
clients, which rely on the mothership being the sources of all change
revisions, to an upstream git server. As distasteful s it may be to
Subversion fans, I'm saying the time is better spent in most
commercial or development environments learning to use git-svn so you
can get used to a git workflow and use it, as needed, to talk to the
Subversion servers. It also permits cloning and local development of a
Subversion repository without asking permission to write branches. It
is, in fact, what I used the last time I submitted patches to
Subversion itself. (Which has been a long time, I admit, my suggested
patches have never been that critical.)

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

[Nico Kadel-Garcia]

On Sun, Dec 9, 2018 at 1:27 PM Branko Čibej  wrote:
>
> On 09.12.2018 19:14, Thorsten Schöning wrote:
> > Guten Tag Thorsten Schöning,
> > am Mittwoch, 21. November 2018 um 15:23 schrieben Sie:
> >
> >>> Thanks for following up. Our engineers have been able to reproduce
> >>> the error on our CI system and are working on a fix.
> > Another two weeks have passed without any hint to the status of this
> > problem from GH and I don't have the feeling that they are really
> > working on this.
> >
> > Does anyone have any other infos? If not, does the SVN-team has any
> > plans to release their workaround mentioned in the following ticket?
> >
> > https://issues.apache.org/jira/browse/SVN-4789
>
> So, as I said in one of the mails referred to in that issue ... I'd
> really prefer not to do that. Yet on the other hand, that GitHub->SVN
> bridge is useful to users who're not locked into the gitficionado world.
>
> My current thinking is that if GitHub can't fix their protocol emulation
> by the time of the planned Subversion 1.12 release, we'll have to
> seriously consider including this patch.
>
> But I'd still rather not ...

I've reviewed the directions at
https://help.github.com/articles/support-for-subversion-clients/ , and
it's a fairly ugly hack, and work to do the integrated checkouts. The
last person I met who used it switched, with my help, to using git,
and using git-svn for access to their local Subversion repositories so
that they could commit working changes locally before submitting them
to the upstream Subversion repository. I recognize that this is *not*
the standard Subversion workflow, but I understood his desire to
publish upstream only the changes he wished to submit.

I'm afraid that the Subversion gateways to github.com are a niche
market, and not one likely to get eager support from github.com
without a compelling business reason to support them. The learning
curve to use git effectively is pretty steep, but the market for
Subversion-only users has been shrinking profoundly over the last
decade.

Re: Can SVN pull request same as GIT?

[Nico Kadel-Garcia]

On Sat, Dec 1, 2018 at 4:00 AM Stefan Sperling  wrote:
>
> On Fri, Nov 30, 2018 at 07:19:06PM -0500, Nico Kadel-Garcia wrote:
> > git pull requests perform a merge in the local repository. What you'd
> > need to create for this is a local repository, not a working copy, and
> > the working repository becomes part of a distributed source control
> > system. Those already exist, so I'd discourage you from trying to
> > re-invent that wheel and bolt it onto Subversion.
>
> Sorry Nico, I don't see your point at all. I don't even understand
> what argument you're trying to make here. Note that "repository"
> and "working copy/tree" are rather fuzzy concepts as long as we're
> talking about more than one version control system at a time.
> It would be better to phrase an argument around a specific use case.

I should have been more clear about a "git pull request", which
usually includes an attempt to request a merge in someone else's
upstream repository. For that to to work as a request, they need to
*your* distinct repository to perform the merge *from*, and that means
exposing the merge source repository to the merge target repository.
That gets pretty hairy and would take a complete restructuring to
support.

By working copy and repository, I meant to use Subversion language.
History lives in, and can be updated in, a repository. Since
Subversion supports only a working copy for a user to submit changes
to a central repository, it is not a distributed source control
system.  If I have a local, working copy in which I a merging chnages
from varoius 3rd party repositories, and not necessarily publishing
them back to any of my source repositories, I am maintaining my own
repository, and trying to re-invent distributed source control systems
on top of Subversion.

> So regarding what Nathan is actually asking about:
> Surely people can commit changes to branches and those branches can undergo
> code review with some frontend which reads diffs from an SVN repository.
> And surely some bot can run 'svn merge' when programmed to do so, just
> like all the bots which run 'git merge' or 'git rebase'.

That is not what I heard. I heard trying to pull in the changes from
one repo, push them to the other, and back. That means not just diffs,
but preserving history for the changes. In theory, one could do things
to do that with history, but it would pretty much have to be done
commit-by-commit to preserve log history, and the individual changes
would have to be *committed* upstream one at a time to bring over the
history of any set of chnages from some arbitrary repository. That
seems like a lot of work, and the local working copy (in Subversion
terms) would have to know about and maintain knowledge of two upstream
repositories and their histories to avoid replicating commits and
applying changes twice, changes that would have to be examined for
duplication.

If you're willing to generate diffs and submit diff patch request to
bring in changes from a second upstream Subversion repository over to
a first upstream repository, OK, that's workable. But that can be done
from two working copies, and doesn't require a single working copy in
userland that knows in detail about both upstream repositories.

> Note that we use such a workflow in SVN itself: When we backport changes
> to stable branches and a merge conflict occurs, we prepare a branch.
> Voting happens in a file called STATUS, and once the change is approved,
> a bot known as 'svn-role' will merge it. See the log here for example:
> http://svn.apache.org/viewvc/subversion/branches/1.11.x/STATUS

But that is a branch, with its changes recorded in the single upstream
repository. There is no split brain between repositories to resolve.
The identity, contents, and order of every individual change is there
already. Resolving that with the individual changes and change history
of another repository is well, that's where I'd expect life to get
both difficult and dangerous.

> Handling merge conflicts is the hard part; generally an automatic merge
> must be aborted and a human needs to resolve the conflict.
> Git has historically had an advantage because SVN could not merge through
> renames unless guided through the whole process by the user, which is of
> course incredibly tedious. But that problem is being addressed by SVN's new
> interactive conflict resolver, and a scriptable frontend for this resolver
> exists which could be used to automatically resolve some types of conflicts:
> http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svnconflict/
>
> So I fully agree with Brane; SVN provides all the tooling required, and
> people building code review tools just have to make clever use of it.

Resolving conflicts is often unsafe to handle automatically. It's
an important part of any merging proc

Re: Can SVN pull request same as GIT?

[Nico Kadel-Garcia]

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

git pull requests perform a merge in the local repository. What you'd
need to create for this is a local repository, not a working copy, and
the working repository becomes part of a distributed source control
system. Those already exist, so I'd discourage you from trying to
re-invent that wheel and bolt it onto Subversion.

Re: Can SVN pull request same as GIT?

[Nico Kadel-Garcia]

On Thu, Nov 29, 2018 at 10:31 PM 钱海远(Nathan) 
wrote:

> Dear Sir,
>
>
>
> We want to develop a feature like git pull request .
>
>
>
> But it is not easy to develop. Svn has only one server , how to store the
> patches? If build failed , how to revert working copy. How to resolve the
> conflict.
>
>
>
> Git is a better , it can support pre-commit code review, pull request by
> default. Is subversion able to develop these features in the future?.
>
>
>
> We like subversion ,we build a lot tools for subversion, like the
> pre-commit code review、issue plugin、code count、svn multisite (same as
> Wandisco’s svn multisite plus) ,but it’s became hard and hard, is it time
> for us to give up svn?
>
>
>
 This seems infeasible. The working copy in which the merges would occur
does not exist in the Subversion workflow. It's a case where git-svn could
work well, as long as you avoid the boobytraps such as difficulties merging
metadata, such as "svn:keywords" or ".gitattributes" or features like
submodules.

Re: Removing data from subversion

[Nico Kadel-Garcia]

On Wed, Nov 28, 2018 at 6:42 AM Ahtesham Kazi  wrote:
>
> Greetings,
>
> I have read that subversion does not allow deleting obsolete not required 
> data.
> Is there a way we can fork from some point onwards ?

Kind-of sort-of. There's a lot of discussion in the Red Book and
mailing list. To prune content, you'll be committed to switching to a
new Buversion repository. Pruning in place is *dangerous*, it's one of
the oldest requested features, and as best I can tell it's never going
to happen.

The fastest and simplest is to snapshot a working copy of the limited
content that you want and make a new repository, with no history. That
is least likely to include bulky content from commits that touched
multiple branches. Second fastest, if your Subversion content is not
complex or heavily dependent on svn: settings, is to use git-svn to
import the desired branch and only the desired branch, apply "git gc
--aggressive" to the git repo, and use "git-svn" to export it back up
to an entirely new Subversion repository. This works surprisingly
well, though it can get quite confused about "svn:keywords" and
similar attributes.

The trickiest is to do a dump, exclude, and reload into a new
repository. That's better able to preserve the history, unsullied,
with really good provenance of subtle tuning like "svn:keywords". But
I've personally given up on the approach. Subversion is aimed at
conserving history, and the history of embedding bulky content
accidentally or embedding keywords or embarrassing software errors
accidentally and very reasonably wanting them *out* of the repos is
why I've used the other approaches.

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

[Nico Kadel-Garcia]

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

Can this be entirely sidestepped by using svn+ssh:// access instead of
HTTPS:// ? I'm not currently using any Subversion based access to
github, but it might provide a short-term workaround if it's
supported.

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

[Nico Kadel-Garcia]

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

They've been good about support: I also bet they have a lot of recent
staff turnover with the purchase of their company by Microsoft.

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

[Nico Kadel-Garcia]

On Mon, Nov 5, 2018 at 6:28 PM Dr. Rolf Jansen  wrote:
>
> > Am 05.11.2018 um 20:43 schrieb Stefan Sperling :
> >
> > On Mon, Nov 05, 2018 at 08:21:20PM -0200, Dr. Rolf Jansen wrote:
> >> and of course the GitHub server does support HTTP/DAV.
> >
> >> # svn co https://github.com/cyclaero/ContentCGI.git/trunk ContentCGI
> >> svn: E170013: Unable to connect to a repository at URL 
> >> 'https://github.com/cyclaero/ContentCGI.git/trunk'
> >> svn: E175003: The server at 
> >> 'https://github.com/cyclaero/ContentCGI.git/trunk' does not support the 
> >> HTTP/DAV protocol
> >
> > There is a problem at Github's end with SVN 1.11.
> >
> > See the thread titled "Problems accessing GitHub's SVN-bridge with SVN 1.11"
> > on this very mailing list: 
> > https://svn.haxx.se/users/archive-2018-11/0008.shtml
>
> In the meantime, I saw this thread.
>
> > There is a problem at Github’s end with SVN 1.11.
>
>
> Reading the whole thread, my impression is that there is another issue with 
> the Robustness Principle of software design on Subversion’s end. See: 
> https://en.wikipedia.org/wiki/Robustness_principle.
>
> I won’t hold on my breath, until the Subversion Developers and the GitHub 
> engineers sorted out their animosities. I put the patch shown below to 
> /usr/ports/devel/subversion/files/patch-zz-DAV-robustness.local on my FreeBSD 
> system, and then I reinstalled the port - problem solved. Happy discussions!
>
> Best regards
>
> Rolf

May I suggest never simply expanding a comment to take out a chunk of
live code ,such as you've done in your patch? If you have to take out
a chunk of live code, add a *separate* coment about why you're doing
it, and add a distinct set of comment marks around it. This will make
merges *much* cleaner for the future.

> --- subversion/libsvn_ra_serf/options.c.orig2018-02-25 10:22:55.0 
> -0300
> +++ subversion/libsvn_ra_serf/options.c 2018-11-05 20:50:29.431635000 -0200
> @@ -403,7 +403,7 @@ options_response_handler(serf_request_t
>
>/* Bail out early if we're not talking to a DAV server.
>   Note that this check is only valid if we've received a success
> - response; redirects and errors don't count. */
> + response; redirects and errors don't count.
>if (opt_ctx->handler->sline.code >= 200
>&& opt_ctx->handler->sline.code < 300
>&& !opt_ctx->received_dav_header)
> @@ -413,7 +413,7 @@ options_response_handler(serf_request_t
>   _("The server at '%s' does not support the HTTP/DAV protocol"),
>   session->session_url_str);
>  }
> -
> +  */
>/* Assume mergeinfo capability unsupported, if didn't receive 
> information
>   about server or repository mergeinfo capability. */
>if (!svn_hash_gets(session->capabilities, SVN_RA_CAPABILITY_MERGEINFO))
>

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

[Nico Kadel-Garcia]

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

Can you switch to using TortoiseGit locally, and avoid the extra
compatibility layers? It would take decisions about your workflow to
do this, but I've found its built-in git-svn toolkit to be effective
and robust for upstream Subversion repositories even where I needed to
retain contact with upstream Subversion repositories..

> I've asked about that problem on SO[1], which revealed that the switch
> from 1.10 to 1.11 really is the problem. Downgrading resolves the
> problem.
>
> Do you have any idea what could be the root cause? Is there something
> that needs to be configured specially?
>
> Thanks!
>
> [1]: https://stackoverflow.com/a/53132753/2055163
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
>
> Telefon...05151-  9468- 55
> Fax...05151-  9468- 88
> Mobil..0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>

Re: Question About Package...

[Nico Kadel-Garcia]

The command "sudo yum install subversion"; should proved the default
subversion for your operating system. If you want a more recent one, at
last check, the company "wandisco" provides quite recent releases. If you
decide you want to build your own, which I don't recommend for the faint of
heart, there are my own RPM building tools over at
https://github.com/nkadel/ . But my tools are for fun, they're not
production grade.

Nico Kadel-Garcia

On Fri, Oct 12, 2018 at 12:46 PM Gerardo Hernandez Sanchez <
gerardo.hernan...@officedepot.com.mx> wrote:

> Hi Everyone,
>
>
>
> I hope you are fine. Can you help to know if exist package available to
> install “Subversion” on Oracle Linux Rel. 7.5.
>
> I think, I sould try to install RH Package.
>
>
>
> But I don’t sure, Can you provide me your feedback about it.
>
>
>
> Thank you.
>
>
>
> Kind Regards.
>
>
>
> Gerardo HS.
>
>
>
> Gerardo Hernandez Sanchez
> DBA
> Office Depot de México
> gerardo.hernan...@officedepot.com.mx
>
>
>
> --
>
> Este correo electrónico (incluyendo cualquier archivo adjunto) puede
> contener información privada, confidencial o protegida. Si recibió este
> correo electrónico por error, por favor elimínelo del sistema sin copiarlo
> y notifique por correo electrónico al remitente para que nuestros registros
> puedan ser corregidos.
>
> This e-mail (including any attachments) may contain information that is
> private, confidential or protected. If you received this e-mail in error,
> please delete it from your system without copying it and notifiy sender by
> reply e-mail, so that our records can be corrected.
>
>
>
>

Re: svn_load_dirs doesn't support filenames with @ in

[Nico Kadel-Garcia]

On Tue, Aug 21, 2018 at 6:43 AM, Daniel Shahaf  wrote:
> j...@beniston.com wrote on Tue, 21 Aug 2018 09:40 +0100:
>> This patch adds @ to the end of the filename, to make it work.
>
> Thanks jon.  Committed with tweaks in r1838539.
>
>> --- svn_load_dirs.pl.in.old.txt 2018-08-21 09:33:02.557893300 +0100
>>
>> +++ svn_load_dirs.pl.in 2018-08-21 09:33:12.339005700 +0100
>>
>> @@ -1203,6 +1203,12 @@ while (defined (my $load_dir = _next
>>
>>  print $handle $property_value;
>>
>>  close($handle);
>
> Your MUA seems to have mangled the patch.  The easiest way to avoid this
> is to send patches as attachments named *.txt.
>
> Cheers,
>
> Daniel

Sending attachments for other people to open can get well, it can
get confusing, and it makes the patch tough for people to review
without downloading the patch. Is there any compelling reason not to
do *both*? And, since it's a patch file, not to send it as a
"filename.patch" attachment?

Re: Best way to correct directory error?

[Nico Kadel-Garcia]

On Sun, Aug 12, 2018 at 4:46 AM, Bo Berglund  wrote:
> On Sun, 12 Aug 2018 03:26:38 -0400, Nico Kadel-Garcia
>  wrote:
>
>>In practice, I may have a long-term better idea for you. Split the
>>projects, each into their own much smaller repository with only its
>>own history. This is also the only good chance you'r likely to get, to
>>*discard* inappropriate binary files, files that accidentally were
>>stored with passwords, and seriously obsolete branches.tags, or even
>>projects altogether.
>
> Our SVN repositories are organized in a similar way as the previous
> CVS repositories were. I migrated the lot back in January and I had to
> decide on the organization back then. We had about 10 CVS repositories
> each with a lot of modules (= top level directories). Each repository
> had different permission settings to allow some employees access while
> denying all others.
> To implement a per-project repository in SVN would lead to a
> management nightmare as far as I could tell, first during migration
> and second in operation when developers would add their projects to
> SVN.

Do you really think so? I've grown very reluctant to mix many projects
into one repository. It only takes one mistake to commit 50,000
somewhat bulky files into a branch, copy or merge *one* file from that
commit into the master before you clean up, and burden the whole back
end database, and every checkout of master with that overwhelming
commit message. Smaller, more modular projects can be a very large
advantage in source control systems. I saw it a year ago? When
someone started loading their python "virtual environments" into a
repo,  Hilarity ensued when someone didn't rea;oze tjat "pip install"
will merrily replace your core python if it detects the right version
dependencies.

> How could I enforce the permission restrictions in such a scenario?
>
> So this is why I have this structure:
>
> repository1
>   |- project1
>   ||- trunk
>   ||- tags
>   ||- branches
>   |- project2
>   ||- trunk
> etc...
>
> repository2
>   |- project3
>   ||- trunk
>   ||- tags
>   ||- branches
>   |- project4
>   ||- trunk
> etc...

I hope you don't mind that I numberd the projects individually in your
list. svnserve.conf supports having multiple groups, or admins, with
matching read and write access. It's possible to write a group for
each department, or a group for the sys-admins, that retains
administritive privileges for a set of repositories or all
repositories. Where it can get trick is when you want the people who
can *read* project1 to always, without extra fuss, include everyone
who can write half of the other projects.

Fortunately, read and write are handled distinctly, and modern LDAP
and NIS and other network compatible group privileges can *contain*
groups in other groups. So the project owner the group that owns, say
everyone in that oveseas qa group, gets write access in the
"offshoreqa" group. That group can be assigned read access to any or
all other projects individually or as part of a hierarchy of groups
and privileges. I don't recommend getting too cutesy with this. But
most of us need to control access privileges anyway, and spreading it
out to multiple svnserve.cnf files mans they can be managed
distinctly. Different project, different config file, which may match
others but doesn't have to. And my attempt to update permissions for
repository1 doesn't accidentally screw up access to all its underlying
projects.

Re: Best way to correct directory error?

[Nico Kadel-Garcia]

On Sat, Aug 11, 2018 at 10:41 AM, Bo Berglund  wrote:
> A collegue has put a project into our SVN server. The server is
> organized such that every project is a top level directory.
> This shall contain subdirs trunk, tags and branches.
> Trunk is where the sources for the project live.
>
> Now he has put his project sources into:
> /Projectname/trunk/Projectname
>
> What is the best way to fix this so it will reside in
> /Projectname/trunk instead?
>
> - Check out /Projectname/trunk and receive subdir Projectname
> - Move to trunk on client
> - svn mv Projectname/* ./*
> - svn ci -m "log message"
>
> Or after checkout:
> - Move to trunk/Projectname on client
> - svn mv * ../
> - mv ..
> - svn ci -m "log message"
>
> I don't want to mess up the repository, so that is why I am asking

You can, in theory-arrange the content, ideally doing it one project
at a time. by moving the components with "mv" commands. I'd also
suggest doing the trunk, then the branches, then the tags, each as
their own distinct commit.

In practice, I may have a long-term better idea for you. Split the
projects, each into their own much smaller repository with only its
own history. This is also the only good chance you'r likely to get, to
*discard* inappropriate binary files, files that accidentally were
stored with passwords, and seriously obsolete branches.tags, or even
projects altogether.

Re: Migration a Git archive to subversion

[Nico Kadel-Garcia]

On Tue, Jul 10, 2018 at 11:30 AM, Martin Sauer  wrote:
> Hello,
>
> I want to migrate my git project archive to subversion. In the internet I
> can't find only infos about migrate from subversion to git.
>
> Can you tell me how I can migrate my projects to svn?
>
> Thank your for your help.
>
> BR
>
> martin

Migrating from git to Subversion is fairly unusual. I'd encourage you
to think carefully about what you're achieving. Since "git-svn"
exists, it's usually feasible to push from a live, local git
repository to a Subversion "master". Re-assembling the branch and tag
history, however, is more awkward. Do you need anything more than the
master pushed?

Re: Perforce to Subversion

[Nico Kadel-Garcia]

On Thu, Jun 14, 2018 at 10:24 AM, Brady Cottam <
brady.cot...@biofiredefense.com> wrote:

> Can anyone tell me if you can import data from Perforce into Subversion
> with any ease?
>
>
>
> Thanks
> Brady
>
>
>
*Data* is trivial. *History* especially older and contorted history as
projects got re-arranged or accidentally mislaid, or chunks re-arranged,
*that* can be hard. The tool you're looking for is called "p4tosvn", and
there have been many variants. One of the dirtier ones, that allows
scrubbing idle or no longer used hisstory, is at
https://matschaffer.com/2009/11/migrate-from-perforce-to-svn/. That
actually uses the built-in git tools to pull from p4, and to export to svn.
That gives you the chance, if you want it, to delete obsolete branches or
bulky unwanted binaries and get them out of hte history.

Re: Problem with svndumpfilter

[Nico Kadel-Garcia]

On Thu, Jun 7, 2018 at 3:04 AM Stefan Sperling  wrote:
>
> On Wed, Jun 06, 2018 at 03:12:20PM -0400, Alfred von Campe wrote:
> > I’m trying to remove two sensitive directories from a repo so we can have a 
> > 3rd party work on it.  I first dumped the entire repo, and now I’m trying 
> > to remove two directories from one particular branch.  But svndumpfilter 
> > keeps failing as follows:
> >
> > $ svndumpfilter exclude branches/develop/dir1 branches/develop/dir2  < 
> > repo.dump > repo-nodir12.dump
> > svndumpfilter: E23: Invalid copy source path '/branches/develop/dir2'
> >
> > I’ve tried this both from a full incremental dump of the repo as well as a 
> > non-incremental dump of the repo starting from the revision that 
> > branches/develop was created.  It always fails after the exact same 
> > revision.
> >
> > Is there anything I can do to work around this issue?
> >
> > Alfred
>
> Yes, you can update to 1.10 and use svnadmin dump --exclude
> instead of using svndumpfilter.
> See 
> http://subversion.apache.org/docs/release-notes/1.10.html#dump-include-exclude
>
> An alternative that works with earlier releases is to set up svnsync
> replication and configure authz access rules for the sync user which
> forbid read access to the paths you want to exclude. svnsync will deal
> with missing copy sources by translating copies into additions.

There is also a fairly nasty and somewhat hazardous trick I've used
effectively a few times to clean up a historically messy SVN layout.
Import it to git with git svn, trim debris branches and tags and
out-of-band content ruthlessly, use "git gc --aggressive" to flush
loose objects or branches *from the history*, then export that with
git svn into a new Subversion repository.  There are risks: git
doesn't handle keywords the same way Subversion does, for example, so
the transfer needs to be reviewed cautiously for svn:keywords and
svn:ignore and svn:eol handling. But when you've a messy Subversion
layout where people dumped oddly named branches or parts of branches
in weird locations, or embedded bulky binary files accidentally and
left copies scattered around the history, it can be an invaluable
cleanup tool. It also doesn't require access to the Subversion server
to run "svnadmin dump", and it can be updated from the current running
Subversion master.

Part of the key is the use of the "git gc --aggressive" tool to flush
history of pruned content. Yes, this flushes history, and is
considered a sin, Sin, ***SIN*** for those who consider a complete and
pristine history of the entire source tree the whole point of a source
control system. But in practice. most branches and tags are
pointless after long enough. and it only takes a few accidental
commits of bulky binaries or of inappropriately imported content to
clutter and even legally encumber a source control system. Like
pruning any history, it needs to be done cautiously or important
material can be lost..

Re: Reference to non-existent node

[Nico Kadel-Garcia]

On Tue, May 22, 2018 at 2:36 PM Davor Josipovic  wrote:

> >  Now that is interesting. 40k doesn't seem to be such a large amount of
data for modern computers. Very slow and fragmented hard drive? Or perhaps
there's something else going on that is manifesting this way?

> The HDD is indeed on the slowside, and together with low memory...

> But I think this also show how I/O intensive SVN is. On the client side,
for each committed file, one copy is placed in .svn folder, and an other
copy in a temporary folder (which is deleted after file transfer in v1.9).
So for each file committed, a double copy is made client-side. This
temporary copy is really necessary?

I think it shows how I/O intensive using 40,000 small files is. Especially
if they are in the same directory, many filesystems get increasingly
unhappy as they try to manage that many files in one directory.

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

[Nico Kadel-Garcia]

What version of subversion is running on your old server? The built-in
version for CentOS 7 is only subverison 1.7, which is now pretty out of
date. Updating CentOS to version 1.9 or later turns out to be *very*
painful due to the the dependencies not available in RHEL 7.

Re: Questions About Backup Repository

[Nico Kadel-Garcia]

On Sun, May 6, 2018 at 9:38 PM, <hong.zh.zh...@icbc-axa.com> wrote:

> Dear
>
> We use TortoiseSVN to manage the code,and backup repository with svnsync.
> We backup repository to remonte servicer with svnsync.
> When edit anyone in the remote repository,the remote repository will be
> breakdown and never to be used again.
>

Never permit this if you expect scnsync to maintain a current copy of the
master repository. This is called "split-brain", and any working copies
from that modified svnsync repository should be considered corrupt.
Unfortunately, tracking down all the working copies can be very difficult,
since even logging on that server doesn't necessarily reveal who and what
made copies, especially local "file:///" based working copies.

We have no idea to revert it only to created a new remote repository.
> Is there any idea to revert the damaged repository ?
> Please  recommend some current ideas for me to backup the repository.
>

Create an entirely new svnsync based repository from scratch. Discard the
old one, and replace it.

It may be possible to simply delete all recent transactions from the
svnsync copy if you can identify when the inappropriate changes were made
on the new repository, especially if you have a good record of what the
last appropriate committed transaction was. But it's generally not worth
the work, and much safer to make a new svnsync repository from the old
master.

The big risk, I think, is not one that you can solve by fixing the damaged
svnsync repository. It's that you may have corrupted working copies based
on that corrupted svnsync copy. I'd strongly consider discarding whatever
URL you used to use for the old svnsync copy and switching to a new URL, to
help prevent any confusion about what the new valid read-only svnsync
repository is.

Nico Kadel-Garcia



> Hopes your replay.
> Thanks so much.
>
>
>
>
>
> *张虹*
> 信息科技部 科技管理处
> 工银安盛人寿保险有限公司
> 上海市黄浦区安澜路8号6楼
> <https://maps.google.com/?q=%E4%B8%8A%E6%B5%B7%E5%B8%82%E9%BB%84%E6%B5%A6%E5%8C%BA%E5%AE%89%E6%BE%9C%E8%B7%AF8%E5%8F%B76%E6%A5%BC=gmail=g>
> 电话：021-60392672
> 邮箱：hong.zh.zh...@icbc-axa.com
>