Removing deleted branches from our mergeinfo

[Stefan Fuhrmann <st...@wandisco.com>]

Hi all,

Our mergeinfo on /trunk as grown to almost 100 branch
entries now. Most of those branches don't exist anymore.

Although we technically could, we will neither merge from
them (using the branch@rev notation) nor resurrect them
in the future. Therefore, I'd like to shave off 15k from our
mergeinfo by removing those unused entries. List below.

Is there a compelling reason not to do it?

-- Stefan^2.

    1.10-cache-improvements
    1.5.x-r30215
    1.7.x-fs-verify
    10Gb
    atomic-revprop
    auto-props-sdc
    bdb-reverse-deltas
    cache-server
    diff-callbacks3
    diff-optimizations
    diff-optimizations-bytes
    dont-save-plaintext-passwords-by-default
    double-delete
    dump-load-cross-check
    explore-wc
    file-externals
    fs-rep-sharing
    fsfs-format7
    fsfs-improvements
    fsfs-lock-many
    fsfs-pack
    fsx
    fsx-1.10
    fsx-id
    gnome-keyring
    gpg-agent-password-store
    gtest_addition
    http-protocol-v2
    in-memory-cache
    in-repo-authz
    inheritable-props
    integrate-cache-item-serialization
    integrate-cache-membuffer
    integrate-compression-level
    integrate-io-improvements
    integrate-is-cachable
    integrate-partial-getter
    integrate-readline-speedup
    integrate-stream-api-extensions
    integrate-string-improvements
    integrate-txdelta-caching
    issue-2779-dev
    issue-2843-dev
    issue-3000
    issue-3067-deleted-subtrees
    issue-3148-dev
    issue-3220-dev
    issue-3242-dev
    issue-3334-dirs
    issue-3975
    issue-4194-dev
    kwallet
    log-g-performance
    merge-skips-obstructions
    multi-layer-moves
    nfc-nfd-aware-client
    node_pool
    performance
    pin-externals
    py-tests-as-modules
    ra-svn-tuning
    ra_serf-digest-authn
    reintegrate-improvements
    remote-only-status
    revprop-cache
    subtree-mergeinfo
    svn-auth-x509
    svn-info-detail
    svn-mergeinfo-enhancements
    svn-mergeinfo-normalizer
    svn-patch-improvements
    svn_mutex
    svnpatch-diff
    svnraisetc
    svnserve-logging
    tc-issue-3334
    tc-merge-notify
    tc-resolve
    tc_url_rev
    tree-conflicts
    tree-conflicts-notify
    tristate-chunked-request
    tweak-build-take-two
    uris-as-urls
    verify-at-commit
    verify-keep-going
    wc-collate-path

Re: Removing deleted branches from our mergeinfo

[Stefan Fuhrmann <st...@wandisco.com>]

On Sun, Aug 16, 2015 at 12:30 AM, Daniel Shahaf <d....@daniel.shahaf.name>
wrote:

> Stefan Fuhrmann wrote on Sat, Aug 15, 2015 at 20:18:53 +0100:
> > Although we technically could, we will neither merge from
> > them (using the branch@rev notation) nor resurrect them
> > in the future. Therefore, I'd like to shave off 15k from our
> > mergeinfo by removing those unused entries. List below.
>
> 15KB of space saving doesn't sound like a noticeable benefit.
>

The "15k" part was just fyi - in case people wanted to
know how big the savings would be.


> > Is there a compelling reason not to do it?
>
> Dogfooding: we shouldn't make changes to our mergeinfo that users cannot
> make too.  Would users be able to make such changes to their own
> repositories?  (without being with the internals of mergeinfo
> implementation)
>

Yes, using the same command that I planned on using:

    svn-mergeinfo-normalizer remove-branches -F $FileWithListOfBranches

If people feel adventurous, they might even do it automatically:

    svn-mergeinfo-normalizer normalize --remove-obsoletes

The whole point of that tool is to help large projects to reduce their
mergeinfo from hundreds of MB to something manageable again.
Enhanced sub-tree mergeinfo elision logic will help them somewhat.
But at >100k mergeinfo per node, eliminating the records of mistaken
merges and simply long-forgotten branches is an important feature,
too. Note that those users run out of memory today during merges
because the total amount of merginfo in memory is > 1GB.

The downside of removing branches from m/i is that they appear
as an "unmerge" in the log. Very few people should actually care
but there might be unintended side-effects. As the Subversion
project and with our straightforward branching scheme, we should
be in the best possible position to fix / deal with those side-effects
if they should occur. So, this would be dogfooding for us.

-- Stefan^2.

Re: Removing deleted branches from our mergeinfo

[Daniel Shahaf <d....@daniel.shahaf.name>]

Stefan Fuhrmann wrote on Sat, Aug 15, 2015 at 20:18:53 +0100:
> Although we technically could, we will neither merge from
> them (using the branch@rev notation) nor resurrect them
> in the future. Therefore, I'd like to shave off 15k from our
> mergeinfo by removing those unused entries. List below.

15KB of space saving doesn't sound like a noticeable benefit.

> Is there a compelling reason not to do it?

Dogfooding: we shouldn't make changes to our mergeinfo that users cannot
make too.  Would users be able to make such changes to their own
repositories?  (without being with the internals of mergeinfo
implementation)

Cheers,

Daniel

> -- Stefan^2.