On Fri, Apr 24, 2020 at 10:36 AM Alex Wilton
<awilton_at_roboticresearch.com> wrote:
>
> Hello,
>
> This is my first time posting to this mailing list so apologies for any newbie mistakes. I couldn't find a bug report discussing this particular issue and while I'm fairly certain this isn't intended behavior, I wanted to post to users@ just in case there was some strange reasoning for why this is supposed to happen.
>
> I'll give the gist of what the issue is and then I'll post the sequence of commands I used to reproduce the entire issue, with some intermediate diffs to show whats going on.
>
> Essentially, I have a full checkout of trunk containing the following directory structure:
>
> file1.txt
> my-project/fileA.txt
> not-my-project/fileA.txt
>
> Then we have a copy of trunk, called "my-branch" which has everything checked out except for not-my-project.
> We make a sequence of commits in trunks, each of which is followed by a sync merge from trunk to my-branch. The first commit changes "file1.txt" and the mergeinfo reflects a full merge (good). The next two commits involve changes to not-my-project, and the mergeinfo of my-branch reflects these revisions as non-inheritable (so, partially merged. also good). Finally, we make a commit to "file1.txt" again, but when merging that over, the mergeinfo in my-branch suddenly reverse-merges the non-inheritable ranges and merges them as inheritable, despite the fact that these revisions have not had their changes brought in (we still don't have not-my-project checked out). The consequence is that SVN now thinks that my-branch has had not-my-project updated and a subsequent reintegrate merge from my-branch to trunk reverses all of the changes made in trunk to match what it looked like on the creation of my-branch. It does this with no complaints. Here is all of the steps I did to recreate that:
>
Thank you for your analysis and detailed reproduction steps.
Hopefully someone with more knowledge than me about the inner workings
of mergeinfo will be able to chime in here, but my immediate thoughts
in the meantime...
I wonder if the problem still manifests if, in your first steps for
setting up trunk and branch, you were to change this:
$ cd branches/
$ svn up my-branch --set-depth=files
to this:
$ cd branches/
$ svn up my-branch --set-depth=immediates
My thinking is that because the 'not-my-project' directory is not
present at all in the branch working copy, perhaps svn isn't updating
mergeinfo for it when it should, in one of the steps along the way,
eventually culminating in the reversal of 'not-my-project' files on
trunk.
At the moment I can't experiment with this further, but I'll try to do
some testing and digging through the mailing list archives over the
weekend.
Thanks,
Nathan
Received on 2020-04-24 17:38:26 CEST