Re: Reintegrate can only be used if revisions XX through YY were previously merged ...

2024-01-22 Thread Nathan Hartman
On Sun, Jan 21, 2024 at 3:08 PM Nathan Hartman  wrote:
>
> On Sun, Jan 21, 2024 at 12:06 PM Daniel Sahlberg
>  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 

Re: Reintegrate can only be used if revisions XX through YY were previously merged ...

2024-01-21 Thread Nathan Hartman
On Sun, Jan 21, 2024 at 12:06 PM Daniel Sahlberg
 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


Re: Reintegrate can only be used if revisions XX through YY were previously merged ...

2024-01-21 Thread Nico Kadel-Garcia
On Sun, Jan 21, 2024 at 12:06 PM Daniel Sahlberg
 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

Merging distinct branches is... one of the things that Subversion is
not best with. I'd suggest using "git-svn" locally to play with, to
see if you can resolve the differences by first merging from the
trunk, then pull in the branches, and *then* push to the upstream
branch.


> Daniel Sahlberg
>