On Sun, Jan 21, 2024 at 3:08 PM Nathan Hartman <hartman.nat...@gmail.com> wrote: > > On Sun, Jan 21, 2024 at 12:06 PM Daniel Sahlberg > <daniel.l.sahlb...@gmail.com> wrote: > > > > Hi, > > > > I'm trying to do a catchup merge between two branches (incidentally within > > the Subversion website tree) but I fail and I don't have enough > > understanding to know what is wrong. > > > > I have a working copy from https://svn.apache.org/repos/asf/subversion/site > > > > In $WC/staging/, I run: > > [[[ > > $ svn merge ^/subversion/site/publish > > svn: E195016: Reintegrate can only be used if revisions 1812681 through > > 1915353 were previously merged from > > https://svn.apache.org/repos/asf/subversion/site/staging to the reintegrate > > source, but this is not the case: > > subversion/site/publish > > Missing ranges: > > /subversion/site/staging:1898163-1898164,1898168,1898183,1899002,1899183,1899186,1899621,1905961,1905965,1909457 > > ]]] > > > > The listed revisions all seem to be authored directly in staging and not > > yet merged to publish (related to the upcoming 1.15 release). > > > > What has gone wrong and what can we do to get back into a working state? > > > > Kind regards, > > Daniel Sahlberg > > > I also saw this when trying to reconcile staging and publish during > the 1.14.3 release. I also thought this was an error, but after > further examination I came to the conclusion that the message was > correct. I can try to look into it later, but if you'd like to > experiment with it first, I suggest looking at 'svn mergeinfo > --show-revs eligible' of both branches and seeing what those unmerged > revs are. I did this when I worked on the release and IIRC this is > what I found: > > There are two different issues here (from what I remember): > > (1) Some time ago, there were some typos that I found in one of the > release note pages and I subsequently grepped and fixed in multiple > places on the staging branch. Those typos were also present in the > 1.15 release notes, which are present in staging but not in publish. > Unfortunately, when I fixed the typos (including in the 1.15 release > notes), it didn't occur to me that they could not be merged cleanly to > publish until publish also gained the 1.15 release notes. > > (2) svn-role updates the "upcoming changes in the next release"; since > release(s) were made in the meantime, many of those "upcoming" changes > are no longer listed -- svn-role deleted those texts. So, if you try > cherrypicking those commits across the branches, I think you'll see > text of old "upcoming changes" being added, and eventually being > deleted again; the sum total is that no textual changes should remain > once they're all merged, except text about the few backported changes > that happened in the last 3 weeks. > > To get past the error, I think you can identify which revisions from > that "missing ranges" list we don't actually need to merge from > publish to staging (all svn-role "upcoming changes" up to the 1.14.3 > release) and do a --record-only merge; that will add those revs to > staging's mergeinfo without changing any text. I think that should > eliminate most of the complaint. If any revs remain, we can look into > those and see what happened. Alternatively, if you don't feel > comfortable with a --record-only merge, you could cherrypick them > one-by-one and watch the text being added and subsequently removed. > > All that is from memory; hopefully I remember correctly. I'll try to > look into it later... > > Hope this helps, > Nathan
Okay here's what's going on: You wanted to catch staging up to publish. Subversion wants the reintegrate source (in this case, publish) to be strictly newer than the destination (in this case, staging). This means we can do a bunch of work on publish and merge it to staging; then we can do a bunch of work on staging and merge it to publish. In effect, we alternately make one branch newer and then reintegrate it to the other, and then vice versa. But, since we have some long-lived items in staging that have not yet been merged to publish (namely, the not-yet-released 1.15 release notes), publish is no longer strictly newer than staging. (Indeed, I examined all the revisions it complains about and all of them happened on the staging branch and involve the 1.15 release notes file.) This is why we fail the checks that happen before the merge takes place and we see the error. This is touched upon in the 1.18 release notes: https://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate Note: In my previous message I mistakenly said that some svn-role revisions were involved; I remembered incorrectly and in fact no such revisions are mentioned in the error message. What can we do? We could choose to do nothing. On the publish branch, 'svn merge ^/subversion/site/staging' merges cleanly, so we can make changes on staging (without first catching up to publish) and then cherrypick those individual changes to publish. (By cherrypicking, we'd avoid merging the not-yet-released 1.15 release notes). Eventually, 1.15 will be released, the revision range mentioned in the error message will be merged to publish, and the problem will go away. We'll be able to reintegrate from publish back to staging again. Or, on the publish branch, we could catch-up merge from staging. That is what the error message is asking us to do. It would solve the technical issue of the error, but comes with the (desirable? undesirable?) side-effect that the not-yet-released 1.15 release notes would become visible on the (published) Subversion website. Maybe that's okay: Interested community members might be more likely to read about new upcoming features (streamy checkouts, pristines on demand, etc) and could provide early feedback or get involved in other ways. If we like that idea, I would suggest to separate visually between "not yet released" and "released" release notes to avoid confusion. Perhaps a picture is worth a thousand words: I committed something like this to staging in r1915365 so you can preview it here: https://subversion-staging.apache.org/docs/release-notes/ (Of course, that means that r1915365 will now be added to the revisions mentioned in the error message.) Thoughts? Nathan
