On Thu, Jun 8, 2023 at 2:54 AM Colcord, Scott via users <users@subversion.apache.org> wrote: > > 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. >
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
