<commit_before>                       Merge-Tracking in Subversion
                       ============================

These notes try to break apart the various sub-problems of
"merge-tracking".  People can mean a whole lot of different things
when they utter that phrase, so this is an attempt to describe various
aspects.

This is NOT a design document.  It offers no solutions or proposals.
It's just a place to enumerate potential problems that need solving.

* Repeated Merge

  Solve the "repeated merge" problem at the level of whole changesets.<commit_msg>* notes/merge-tracking.txt: Add thoughts about what "merge tracking" means.<commit_after>                       Merge-Tracking in Subversion
                       ============================

These notes try to break apart the various sub-problems of
"merge-tracking".  People can mean a whole lot of different things
when they utter that phrase, so this is an attempt to describe various
aspects.

This is NOT a design document.  It offers no solutions or proposals.
It's just a place to enumerate potential problems that need solving.

* Some thoughts about what "merge tracking" means.

  - If you merge rN into some destination (e.g., into branch B), it
    should be possible to query rN itself to ask what destinations it
    has been merged to, and the answer set should contain B.

  - If you merge rN into a branch B, and rN was committed by author A,
    then 'svn blame' should show the changed lines in B as last
    touched by A, even if the merge was committed by you and you are
    not A.  (Hmm, this gets tough to implement when one merges a range
    of revisions simultaneously!)

  - It should be possible to query any path (file or directory) to
    find out what changes (revisions) have been merged under it.  For
    files, "under" just means "into".

  - It should be easy to discover all the paths at which a particular
    node revision (i.e., unique versioned file entity) exists,
    especially in a given revision.  IOW, this is the "what branches
    does this exact version of this file exist in" problem, often
    requested by so-called enterprise-level users.

  - Merge records should be transitive.  Often we merge a bunch of
    changes to a backport branch, tweak them there, then later merge
    the branch into a release line.  Later queries of the release line
    should show that the original revisions are present, and queries
    of the original revisions should show that they went to the
    release line as well as the backport branch.

* Repeated Merge

  Solve the "repeated merge" problem at the level of whole changesets.
{'fraction_non_alphanumeric': 0.06056018168054504, 'fraction_numerical': 0.0, 'mean_word_length': 3.123244929797192, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4789698', 'n_tokens_mistral': 668, 'n_tokens_neox': 632, 'n_words': 393}