On Fri, Jun 2, 2017 at 7:15 AM, Alfred von Campe <alf...@von-campe.com> wrote: > On May 31, 2017, at 11:18, I wrote: > > After many years of development, we have over 100 entries in the > svn:mergeinfo property of our trunk. I am thinking about manually editing > the property to remove entries for all branches that have been deleted or > are no longer used (and should be deleted). I am hoping that once I merge > trunk into the other active branches, the cleanup of that property will also > propagate to the other branches. > > So my questions are: > > Is this safe to do? > Will the changes to the properly be merged to all other branches over time > as one would expect? > > > Has anyone ever done this? Are there any negative repercussions? Inquiring > minds (well, maybe it’s just me) want to know… > > Alfred
I suspect you're going to hurt yourself if you try this sort of stunt. Not that it might not work in theory for some cases, but it's not tested and is against the basic "never, never, never, and did I mention never alter history" approach to Subversion. What I think you *can* do is an "svnadmin dump | svndumpfilter exclude (obsolete branches) | svnadmin load" to another Subversion repo, and switch to that repo to have a modified history. That's the only officially supported way to flush obsolete content. There are some alternatives that I've personally found effective, that are not so well supported. Using "git-svn" to get the content to a git repo, deleting content *there*, running a "git gc --aggressive" to clear content, and then pushing the content back up to another Subversion server has been effective for me. But it tends to lose svn:properties settings, and it makes many Subversion admins twitch and shudder and break out in hives when they realize you're using git to provide features that violate the basic "never delete history" of Subversion design philosophy.
