Missing merges in boinc-parentmap / meaning of mappings

[brevilo]

It seems there are a number merges missing. This is what I found so far:

• merges from trunk to 6.8
  • 20242 20243
  • 19046 23630
• merges from trunk to 6.10
  • 19046 19047
• merges from trunk to 7.0a
  • 25477 25478
  • 25503 25504

Related: 555eb12#commitcomment-2399501

To be continued...

[brevilo]

I don't yet fully understand the possibilities and limitations of the parentmap feature arising from the different merge semantics in svn and git. Consider revisions 23916-23918 for instance: it seems as if in 23916 Charlie implemented a certain feature/workaround in branch boinc_core_release_6_12. This feature then got merged to tag boinc_core_release_6_12_34 in 23917. It got also merged to trunk in 23918. This brings me to the following questions:

1. What's being merged? I would expect that adding a parent to a git commit results in a git merge, that is, the whole branch gets merged, not just a specific changeset as it might have been the case in svn. That could be wrong if the source branch contains other commits not yet merged into the destination branch (and not intended to).
2. What's the source for the merge into trunk in the example above anyway? Branch boinc_core_release_6_12 or tag boinc_core_release_6_12_34? If in fact the whole branch is merged (see 1) then this could make a difference (in general, not necessarily in the example above).
3. How does git-svn handle all this...?

[romw]

1. Diff(s)/Delta(s) depending on which termonology you want to use.
2. Just a single commit
3. I donno

[romw]

23917 isn't considered a merge by SVN. It was just a manually applied patch/commit without the merge meta data.

[romw]

Same with 23918. It was just a manually applied patch/commit without the merge meta data.

[romw]

So the answer to 3 is three seperate commits without any links to a common diff

[brevilo]

Diff(s)/Delta(s) depending on which termonology you want to use.

Rom, I was talking about the general question of what happens when one adds an additional parent mapping to a given commit. Since I presume that svn merges are semantically different compared to git's merges, we might not be able to just add a parent and expect the same outcome as one finds in svn history.

Just a single commit

Same here. I do know what was committed in those revisions. My question was how do I tell from where the seeming merges originated. In this particular example there had not been any actual merges so it's obvious that I can't find any hints to their source.

---

But again, these questions are about general thoughts. I'm wondering which of the seeming merges I come across I really need to (should) add. See revisions 19046, 19047 and 23630 for a similar case as the example above. I also can't find a merge source for the latter two, so I assume they are regular commits as well.

Also the following question comes to mind: should we be adding those parents, even in cases like two examples? We could be improving history if my full-merge presumption is wrong (I doubt it)... Needs to be tested...

[brevilo]

By the way: did BOINC use svn 1.5 or above? I couldn't find any svn:mergeinfo properties so far...

[brevilo]

Here's an example for the problem I see, related to my first question: in revision 16066 David merges a feature Frank committed in his workspace at revision 16065. However, I presume adding a parent in git will also include the changes of 16064 in the merge as it's the parent of 16065 and not yet merged since the last merge (parent mapping) in 16055. Such a merge would change history...

In this case it's indeed ok to include 16064 as it fixes a regression introduced by the merge in 16061. But nevertheless, history will be altered as the regression was fixed eventually in trunk in 16086.

There could be other examples where the difference in merge semantics will cause actual code changes, not "just" history changes (which are already bad enough).

---

Update: I just verified, using boinc-v2.git, that my presumptions (see question 1) are indeed correct. History is and will be changed (content might be changed, see above!) by such merges.

[romw]

BOINC does at present use SVN 1.5 or better. I think we started out at an earlier version. You'll probably find svn: mergeinfo stuff related to my commits in the 6.12 and 7.0a branches.

[brevilo]

Yet another observation: these parent mappings seem to create only "virtual merges". They seem to add the parent-child relation only, without changing the merges themselves.

Example: in revision 15679 David merges Adam's pymw feature. By adding a parent relation to 15660 Nicolas established the merge from Adam's workspace into trunk. However, Adam's workspace also included an unrelated commit in revision in 13661 that would also be merged, in fact, it is indeed part of the history (commit graph) of boinc-v2.git. But, it's content isn't reflected by the "merge" result in 15679. It simply doesn't contain 13661's change, despite now being part of the history! Well, part of the history that is: neither git blame nor git log sched/db_purge.C are aware of that change. The same applies to 15660 itself, one of the parents of that very merge!

Bottom line: parent mapping doesn't modify anything but just creates virtual (!) branch relations. While this might be helpful to follow history it might also create some confusion as one might look at what seem to be an actual (git) merge, but which isn't. Not sure what to make of this...

This is important as it would leave question 1 to be answered with: "nothing". It would also mean that the parents I suggest in my first comment would be just fine and we wouldn't have to worry about actual sources or accidental merges of unwanted commits. Hm, this would also explain why Nicolas added some inaccurate mappings without being actually concerned...

Can someone, ideally Nicolas, confirm my conclusion(s)?

[brevilo]

There are certainly many more parent mappings to added. I'll leave it you to identify and add them if needed.

[romw]

As far as I know this has to meet your standards before you sign-off on it, is it up to your standards?

[brevilo]

Why does it have to meet my standards? It's your code and your migration, thus it should meet your standards.