Unable to proceed after selecting automatic configuration layout on SVN Mirror

There is need to migrate different subfolders under master and branches from SVN repository. But history is not coming properly.
Parent SVN Repo path: /financetech (Attached is the screenshot - SVNParentRepo)
The path /financetech/TDW_Calypso/Workspace/scripts_deployment_linux/HOME/WorkspaceOra/scripts/SDM needs to be the master

Below are the two mappings that we have tried-
SVN URL was set to https://svn.dts.fm.rbsgrp.net/financetech

Mapping 1
trunk = TDW_Calypso/Workspace/scripts_deployment_linux/HOME/WorkspaceOra/scripts/SDM:refs/heads/master

The issue with this mapping is that it is showing only two commits on Git whereas there are several on SVN.

Mapping 2

As per what we understand, in case the folder SDM resided under some other location, automatic layout can detect those paths and add to mapping.
When we select the automatic configuration layout for mappings, it throws error mentioned below-

Command Failed : SVN-Bitbucket-Adhoc / SDM_Scripts2

REPORT of ‘/financetech/!svn/vcc/default’: 413 Request Entity Too Large (https://svn.dts.fm.rbsgrp.net)

Please let us know how we can proceed in this case?

Hello.

The ‘413 Request Entity Too Large’ error occurs when our add-on sends a request which SVN server rejects to process due to the size of that request. SVN Mirror requests SVN log and due to big size of your Subversion repository, this requests gets too large. It can be resolved by clearing limit of the allowed request side and increasing size of XML-based request body for the web-server that hosts the SVN repository. Here are setting for Apache web-server:

LimitXMLRequestBody 8000000
LimitRequestBody 0

You can enable this configuration temporary while SVN Mirror generates configuration for you and then revert this change.

Another solution for this issue is to use another protocol to access the repository, for example, svn+ssh, it’s not prone for such errors.

Regarding the history issue – probably, the /financetech/TDW_Calypso/Workspace/scripts_deployment_linux/HOME/WorkspaceOra/scripts/SDM directory has been created by renaming another directory and that’s why there are only two commits in Git history. The solution is to add mapping for the old directory this one was created from; the automatic configuration should resolve this issue. Or, such a mapping can be added manually; if you have issues creating the mapping please provide us the SVN history (svn log -v) for that directory, we’ll create the mapping for you.

Hi,

We cannot make change at apache level right now. We are attaching the svn logs for the mentioned path that needs to be migrated.
Also, can you please elaborate more with an example for the protocol that you suggested?

Thanks
SDM_scripts.log (73.1 KB)

Hi,

thank you for the log, here is the configuration:

trunk = TDW_Calypso/Workspace/scripts_deployment_linux/HOME/WorkspaceOra/scripts/SDM:refs/heads/master
branches = Workspace_Projects/Workspace_SybaseToOracle/scripts_deployment_linux/HOME/WorkspaceOra/scripts/SDM:refs/heads/old_master

Here are more details about the svn:// protocol:

http://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html

the following describes the ssh tunnelling with svn (svn+ssh):

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

Also, it’s possible to use file:// protocol, but it only possible when the SVN repository is on the same server and filesystem with SubGit.

Hi,

Thank you for the mappings.
For the suggested svn-ssh protocol, it will not be possible to use it because our SVN server and the server where our SVN Mirror resides are on two different datacentres and we do not have ssh enabled between them.
If we try the changes on apache as suggested, Can you please confirm if there would be performance impact on the SVN server due to these changes?

Setting for Apache web-server:

LimitXMLRequestBody 8000000
LimitRequestBody 0

Thanks

Hi,

those settings only set the limit for the requests and don’t affect the performance directly, so there should not be impact to the SVN server.