I work on a large repository (2 million plus commits, 600k files, 70GB
total size) where trunk commits are frequent and happen by the minute. Our
repository has been around for so long our mergeinfo is unreliable. We've
had some major upgrades to our server over the past 10 years. We used to
merge at root until our repository got so massive we had to shift over to
subtree merges. After years of subtree merges our mergeinfo is all over the
place.
When a new project comes up we branch from trunk and keep that branch alive
for months, sometimes years at a time, which requires regular merges from
trunk back into our branch. Before we merge our branch back into trunk we
run diffs to confirm changes made on the branch. However, with commits
frequently happening on trunk those diffs are only relevant immediately
after we've merged trunk into our branch. We don't have the flexibility of
locking trunk every time we want to run a diff. Note that we are diffing
from the point of branch copy (--stop-on-copy) to the HEAD of the branch.
We are running subversion server 1.9.7 with subversion client 1.14.0. I've
searched for answers to this question, and perhaps I've been using
incorrect terminology or framing the question wrong. Here goes:
Without running third party software, is there a reliable way to determine
which of the commits on our branch are merges coming in from trunk? The
docs say that mergeinfo can be unreliable for a variety of reasons. We
could always parse standardized commit messages in our logs, but hiding
critical data like that in our commit messages just doesn't seem like a
reliable approach.
Thanks in advance,
wispan
Received on 2020-09-18 03:30:00 CEST