On Fri, Jun 2, 2017 at 7:15 AM, Alfred von Campe <alfred_at_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.
Received on 2017-06-02 14:25:54 CEST