Maintaining a SVN 1.7 mirror without network access

[Colcord, Scott via users]

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.

 

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.

[Andreas Stieger]

Hello,

On 2023-06-03 00:25, Colcord, Scott via users wrote:
>
> [...] Subversion 1.7 [...] periodically mirror it to a location that

> does not have direct net access

> [...]

>
> the mirror needs to be able to receive one divergent commit after the
> load (this commit alters svn:externals locations to be appropriate for
> the mirror’s network).

> [...]

>
> Is there a way to replace the mirror repo with the contents of the
> dump, without needing to manually delete it first – and ideally
> without needing local rights (perhaps using svnrdump)?  Essentially, I
> want the revisions from the dump file to replace the same-number
> revisions in the repo, rather than appending.
>
> Is this possible?
>

No you cannot do it in the way you described, and your approach is
incorrect. Not for svn, but IT.

For subversion: If you alter the history of the repository in any way,
all working copies will be invalidated. So even if you repeat the steps
described, you will need to get new working copies.

Please separate immutable history from the location-specific
configuration. Either have the network configuration represented in a
location-specific source, such as local DNS or other
network-discoverable data. Or simply do not version location-specific
data that creates a need to change it. Or make the code discover it's
own location and pick one of the versioned configurations. This isn't
even working around a limitation of svn, but good system design.

If you proceed like that, you can use the incremental dump feature which
should make administration faster and more straightforward.

Andreas

[Nathan Hartman]

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

[1] 

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

Cheers 

Nathan 

[Nico Kadel-Garcia]

On Sat, Jun 3, 2023 at 2:33 AM Colcord, Scott via users
<us...@subversion.apache.org> 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?

[Colcord, Scott via users]

Thanks to all for their insights.

On Saturday, June 3, 2023 2:41 PM, Andreas Stieger wrote:
> No you cannot do it in the way you described, and your approach is incorrect. Not for svn, but IT.

Just to be clear, the status quo was not my idea; I'm just trying to work with it.

> For subversion: If you alter the history of the repository in any way, all working copies
> will be invalidated. So even if you repeat the steps described, you will need to get new
> working copies.

Right; the need to re-fetch working copies after an update is understood. It's been annoying but manageable because the mirror is read-only other than the single adjustment commit - I don't need to worry about anyone having pending changes in their working copy on that network.

> Please separate immutable history from the location-specific configuration.

I would love to, but...see below.

On Sunday, June 4, 2023 4:06 AM, Nico Kadel-Garcia wrote:
> 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?

Everything is on a single server with the same name on each network, so I can just use externals paths with no server name needed. However some of the externals required by my project are located at different paths on the mirror's network. For example, /foo/tags/public_10 versus /foo/tags/private_10, or /components/foo vs. /private/components/FOO. These inconsistencies are unfortunately locked in; I do not have the ability to relocate these projects on either network, and I'm not aware of any way to embed more complex logic in the externals checkout process.

My current process for mirror updates involves reloading the repository, running a script that commits the adjustment to svn:externals, and then having everyone re-fetch their working copies. If anyone has any suggestions for how to better manage this situation within the limits I have to live within, I would be happy to hear it.

Thanks,

----Scott

[Johan Corveleyn]

I'd suggest moving towards separate scripts or other tools, outside of
SVN, instead of svn:externals, for stitching things together. For very
simple and straightforward "arrangements", svn:externals might be a
good fit, but if things start getting more complex you're often better
off building something outside of SVN. That way you can implement more
complex logic as much as you want for this.

An example from my own experience: for dependencies between our Java
modules we first started by using svn:externals in some top-level
applications (listing all necessary sub-modules), so you could create
a nice working-copy to have everything. A bit later we implemented a
script to adjust those svn:externals if dependencies changed. But
after a while it became more and more complex, and the svn:externals
started to become a hindrance. So at some point we created a python
script to stitch everything together with plain svn checkout and
update commands etc, and ditched the svn:externals. Things have been
much easier and simpler since then :-).

--
Johan