Here we go!
Paradox wrote:I believe there's still one remaining issue with pulling changes back and forth between the repositories. We can pull changes from bitbucket into github with no problems, but I don't think a path exists to pull changes from github back to bitbucket. I will double check with CWalther if this is the case, but my understanding is that you would also need to apply the same changes we made so that both repositories are compatible.
It’s important to distinguish between the questions of version control system (Git vs. Mercurial) and repository hoster (GitHub vs. Bitbucket vs. OU Foundry) on the one hand, and of code bases (CWE-ou default, H-uru/Plasma master) on the other hand. These two questions are completely independent.
Thanks to Hg-Git, the first question is no problem at all. Revisions can easily and with round-trip fidelity be pushed/pulled back and forth between Git and Mercurial at will, and by extension between GitHub and Bitbucket. Anyone can use whatever tool they prefer or is better suited to the job for any step of their work.
So, “pulling changes from github back to bitbucket”, which is an instance of question 1, is easy. However, I think that’s not what you actually mean. It will just give you the same stuff on both sides. I assume when you say “pull changes from github to bitbucket”, you actually mean “port changes from the H-uru codebase to the CWE-ou codebase”. That’s an instance of question 2, and it can happen in either Git or Mercurial and the result can be published on either GitHub or Bitbucket at your preference. This is where things get interesting.
In principle, the short answer to your question is “no”. No changes are required to the OpenUru.org repositories to publish a change ported from the H-uru codebase in them (other than pushing that revision, obviously). There is an asymmetry between the OU side and the H-uru side, as will hopefully become clear later on.
However, you are correct that porting a change from H-uru to CWE-ou will most likely be more difficult or more work than the other way around. This is just because there has been much more development on the H-uru side than on the CWE-ou side, so porting from CWE-ou to H-uru mostly consists of forward-porting, while moving from H-uru to CWE-ou is mostly backporting. Forward-porting is comparatively easy, it’s basically a merge. Backporting requires cherry-picking or rebasing and is more likely to run into conflicts because there are many opportunities for the change-to-be-ported to depend on changes that came before it in the source development line, but are not present in the target development line.
These things are hard to explain in words, so I made some pictures.
Figure A shows an overview of the current situation. Most of this is present in
https://github.com/H-uru/Plasma and
https://bitbucket.org/cwalther/cwe, parts of it in
https://bitbucket.org/OpenUru_org/cwe-ou and
http://foundry.openuru.org/hg/CWE-ou. (
Edit: see next post for a graphical representation.)
It shows the revision graph with the heads of the two main development lines, which are the
default branch of CWE-ou and the
master branch of H-uru/Plasma. It illustrates that there are two distinct origins, that are however almost identical in terms of file trees (one empty file missing in one). It also illustrates how
The Merge, discussed in topic
Incompatibility of OpenUru.org and H-uru CWE repositories, establishes a common ancestor to the
CWE-ou default and
H-uru master branches. Note that this common ancestor lies on the CWE-ou development line. This is the asymmetry that I alluded to above. The common ancestor is already part of the OU repositories, that’s why no change is required there. It is the
“MOULa build 1.902” revision.
Let’s first consider the situation that someone has done some development based on that common ancestor: left side of figure B. This was the case with my original
cursors pull request, which was my motivation to undertake all this.
This change can easily be ported to either of the
CWE-ou default and
H-uru master branches: it is simply merged with them, as the right side of figure B shows. Note that in the case of the merge to
H-uru master, there is a large number of revisions on the right leg of the merge from the common ancestor, creating ample opportunity for merge conflicts. In particular, the two orange ones labeled as “Preparation for The Merge” in figure A are part of that leg, containing the file moves and whitespace conversions that make up one of the big differences between today’s
CWE-ou default and
H-uru master codebases. It is advisable to do this merge in Mercurial, because the “preparation” revisions include explicit file move information for Mercurial that helps it get over the file moves without tree conflicts, while Git with its after-the-fact file move guessing in my experience is confused by the whitespace changes and fails. There will usually still be content conflicts due to the whitespace changes, but these can be resolved more easily than tree conflicts.
Next, let’s try porting some development based on the current
CWE-ou default to
H-uru master: figure C.
In this case, merging doesn’t work, because that way you would include everything starting from the common ancestor (in this case, one additional revision, the
CWE-ou default tip (hg 2e5a53a / git a2f42c3)). Instead, you need to
cherry-pick or
rebase the desired revisions across (I think the term “cherry-picking” is commonly used for single revisions only, while “rebasing” is the general term). You’re going back by one revision and forward by many here, which has some chance of working without too many conflicts (apart from whitespace), assuming that your VCS safely takes you across the bumps in the “preparation” revisions as above (using Mercurial at least for that part may be helpful).
Finally, porting changes from
H-uru master to
CWE-ou default: figure D.
The procedure is exactly the same here, only that this time you’re going back by many revisions and forward by one, which is more likely to run into conflicts.
I have never attempted either of the last two scenarios, so their treatment is purely hypothetical.
