Incompatibility of OpenUru.org and H-uru CWE repositories

[Christian Walther]

More results: It is probably a bug in Hg-Git, not in Mercurial. Importing the no-op merge from Git appears to create filelogs with disjoint histories that confuse Mercurial’s copy searching. The easy way around this is to do the merge in Mercurial rather than Git. (This means that those who want to take advantage of it need to get (pull/clone) the merge in Mercurial, as going to Git and back reintroduces the problem. But that’s probably what they would to anyway.)

Updated script:

Code: Select all

hg clone https://Foundry.OpenUru.org/hg/CWE CWE-hg
cd CWE-hg
hg up -r 5416f15d37e4
hg branch ou-huru-bridge
hg mv MOULOpenSourceClientPlugin/Plasma20/Docs MOULOpenSourceClientPlugin/Plasma20/Sources .
cd Sources/Plasma/FeatureLib/pfConsole/
mkdir ../pfConsoleCore
hg mv pfConsoleCmd.cpp pfConsoleCmd.h pfConsoleContext.cpp pfConsoleContext.h pfConsoleEngine.cpp pfConsoleEngine.h ../pfConsoleCore
cd ../../../..
cd Sources/Plasma/PubUtilLib/plAudio/
hg mv plOGGCodec.cpp plOGGCodec.h plWavFile.cpp plWavFile.h ../plAudioCore
cd ../../../..
hg ci -m "Replaying the file moves of the H-uru master branch."
cd ..

git clone https://github.com/H-uru/Plasma.git CWE-git
cd CWE-hg
hg bookmark -f -r ou-huru-bridge ou-huru-bridge
hg push -r ou-huru-bridge ../CWE-git
cd ../CWE-git
git checkout ou-huru-bridge
git branch temp ou-huru-bridge
git reset --hard master
git reset --soft temp
git branch -D temp
git commit -m "All other changes of the H-uru master branch, squashed into a single commit to avoid cluttering up the revision graph. Check the other leg of the merge for the actual history."
cd ..

cd CWE-hg
hg pull -r master ../CWE-git
hg pull -r ou-huru-bridge ../CWE-git
hg up --clean -r master
hg merge -r ou-huru-bridge
hg ci -m "Merge the OpenUru.org root into H-uru master."
hg push -r master ../CWE-git
cd ..

This now allows me to port my cursors branch over the “great H-uru reorganization” without tree conflicts. Yay!

I therefore declare this my preferred solution.

Seeing as it requires no action on the part of OpenUru.org, but requires action on the part of H-uru, I should probably propose it over there…

[rarified]

This was supposed to be an easy week at work, but as they say about wishes...

I'll look tomorrow with this; hg-git has a bug in my environment (latest 2.7 python, 1.8.3 mercurial) that is preventing it from cleanly importing. I've been experimenting instead with the Selenic provided 'convert' extension, which not only converts from one repository format to others, but allows arbitrary splicing of ancestry and some other neat operations (such as mapping i.e. fixing commiter names). I thought at the end of last weekend I'd be able to come up with an example during the week; but it had to wait till this weekend. I'll point you (Christian) at it when I've formulated an example and see how it works for you.

_R

[Christian Walther]

I have fixed the bug. With this version of Hg-Git, it now does not matter whether the merge is done in Git or Mercurial (copy detection in Mercurial works either way), and it can be safely pushed/pulled back and forth. (As long as you don’t pull the merge from Git to Mercurial, using the released (broken) version of Hg-Git is fine.)

hg-git has a bug in my environment (latest 2.7 python, 1.8.3 mercurial) that is preventing it from cleanly importing

It works for me (Python 2.6, Mercurial 1.8.3), as long as I give it bookmarks to push…

I've been experimenting instead with the Selenic provided 'convert' extension, which not only converts from one repository format to others, but allows arbitrary splicing of ancestry and some other neat operations (such as mapping i.e. fixing commiter names).

As far as I understand, that extension is for one-way conversion, so I don’t immediately see how it helps with my goal of continuous two-way interoperability (unless it generates the same changesets as Hg-Git, in which case one could have just used Hg-Git to begin with). But I’m curious to see what you come up with.

[JWPlatt]

Seeing as it requires no action on the part of OpenUru.org, but requires action on the part of H-uru, I should probably propose it over there…

Christian, is this working out for you and the GoW? If we have nothing more to worry about on this issue here, we'd like to get on with things.

Also, will a'moaca's attribution be corrected?

[branan]

a'moaca's attribution should be correct in the second root. There's nothing we can do about the first root without rebasing our entire repo, and since at this point we do have non-core developers working on their own product branches that's just not going to happen.

I'm OK with merging in CWalther's current plan. This will allow us to easily pull in any changes Cyan pushes to OU, which is good enough for me. It should also make cherry-picking our commits to merge into OU a bit less difficult now that everything can be in one repo.

I'd still like to see this common merged head be pulled into OU, but since no one responded when I asked for more clarification about the percieved issues in our repo, I guess there's just no interest in that from anyone working on development here at OpenURU. Your loss. Asyncfixes alone is worth whatever hassle there might be in merging outstanding patches against the OU repository - not to mention compatibility with modern VS versions and all that stuff that I've mentioned before.

[JWPlatt]

I'm OK with merging in CWalther's current plan. This will allow us to easily pull in any changes Cyan pushes to OU, which is good enough for me. It should also make cherry-picking our commits to merge into OU a bit less difficult now that everything can be in one repo.

Super. We have our eye on two specific changes MercAngel recommended.

Fix for animated detector regions not actually animating (cleft bucket cloth, Er'cana harvester ladder) by Hoikas
Fix to make Internal Build compile with out errors.

a'moaca' took a look and endorsed (pseudo reviewed?) them. I will take a look also, then do the push. Though with your clearance now on the repo issue, rarified might get to implementing our branch plan sooner and MercAngel or someone could push it themself to our dev branch-to-come from where I would put it on the ou branch and clear with Mark for default (Cyan compatible). Or something very close to that.

[Christian Walther]

JW, in case you’re not following H-uru on GitHub: I put my proposal up there two days ago, and yes, it seems we’re closing in on that.

Branan, are you speaking on behalf of the whole H-uru team, or do you think others might need more time for review? If this is a definitive OK, then I’ll provide the definitive pull request tomorrow morning (if there are no more commits until then, the only change would be the improved attribution to the H-uru team of that one commit).

Rarified, if you’re reading: What’s the state of whatever you’re doing? Are you on the verge of discovering a much greater solution that this would interfere with? If not, then I’d say we go ahead with this.

[branan]

It's been discussed in IRC, and no one raised any objections. I'd say at the very least nobody hates the idea . Let's just get it done. This has taken way too long.

[Hoikas]

a'moaca' took a look and endorsed (pseudo reviewed?) them. I will take a look also, then do the push. Though with your clearance now on the repo issue, rarified might get to implementing our branch plan sooner and MercAngel or someone could push it themself to our dev branch-to-come from where I would put it on the ou branch and clear with Mark for default (Cyan compatible). Or something very close to that.

I didn't ask for my code to be reviewed by non-Plasma developers. Ironically, the only way I would know that any of you (JWP, a'moaca') are programmers is that a'moaca' worked on alcugs and wrote her own MOUL server (and I do respect her for that). However, there have been barely any contributions at all to CWE here. And this is supposedly the hub for Open Source Uru Development? If I had wanted to submit my animated detector fix to this repository, I have no idea how I would have done so--there is still no clear path for contributions nor is the core team here doing any development work.

Take this as my vision of what will happen if things don't change from talk to action: Open source Uru will stagnate and the game we all care about will die. Who will be to blame? No one but ourselves.

PS: It took me 15 minutes to figure out how to register at this forum and figure out how to post.

EDIT: Make part of the post sound less trollish.

[JWPlatt]

Christian, thanks for the link to your repo issue. I recommend that rarified read it too.

rarified did test some things and, really, nothing is better than restoring compatibility directly within the H-uru fork. Thanks, and to Branan too. We still intend to implement three branches from this point forward in the CWE repo - default (Cyan compatible), ou (reviewed fan development from the dev branch), and dev (pushes from developers). I assume if H-uru is compatible, these things won't be a problem. We also plan to do the same in the MOULSCRIPT repo.

If there are any nuances I missed, or gross errors, rarified will elaborate later.