RAD Game Tools License Concern - Immediate Action Required

CyanWorlds.com Engine Project Management
User avatar
Hoikas
Member
Posts: 344
Joined: Fri Jun 03, 2011 8:38 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Hoikas »

Okay, real problem this time. The script commits suicide at line 82--a commit seems to have disappeared. The merge of skoader's pull request #18 is now 128:97c5091c1a9e. The corresponding commit from the repository backup of cwe-ou I acquired is 129:2a23f5511857.

Distro: Debian [Testing]
Git: 1.7.10.4
HG: 2.2.2

Original History - Filtered History
Image
Christian Walther
Member
Posts: 317
Joined: Sat Dec 13, 2008 10:54 am

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Christian Walther »

Thanks for the testing everyone, we’re getting somewhere!

Re bashisms: I’m not a shell scripting guru either, I just keep banging at it until it works for me :). Using #!/bin/bash is probably the easiest solution for now, as I’m guessing that everyone should have bash available. I’ll probably have to test on Linux sometime too.

Re abort: repository cwe-ou not found!: Doh! I only used the script with absolute paths in the command line arguments… fixed.
Hoikas wrote:A commit seems to have disappeared. The merge of skoader's pull request #18 is now 128:97c5091c1a9e. The corresponding commit from the repository backup of cwe-ou I acquired is 129:2a23f5511857.
Hmm, the disappeared commit is the same “Merged in cwalther/cwe (pull request #2)” that is also missing from Rarified’s CWE-ou-NOBINK. I found where that comes from now: it’s a bug in the convert extension of Mercurial < 2.3, fixed in http://selenic.com/hg/rev/5146de7bce96.

You also have some revisions in a different order than the original CWE-ou, so my identifying the commit to check as “129” was a bit fragile to begin with, I’ve changed that to identifying it by date.

I have addressed all the points above in https://gist.github.com/4246319 now. Please try again, with Mercurial 2.3 or newer.

I have also added removal of the Bink header files (plLayerBink.h, plBinkPlayer.h, plBinkBitmap.h) and updated my reference repositories accordingly. This has the side effect that commit “Remove Bink from the build, unless BINK_SDK_AVAILABLE is defined.” (r5) is eliminated, as well as a few more on the H-uru side, as they would end up empty.

Next steps, probably tomorrow, depending on school work: Writing the simplified conversion scripts, using them to convert my own repositories and CWE-ou-minkata, seeing if I can get both forks to build again based on Hoikas’ bink-fallout work.
User avatar
Hoikas
Member
Posts: 344
Joined: Fri Jun 03, 2011 8:38 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Hoikas »

I remove the debian mercurial package and used easy-install to pull down Mercurial 2.4.1. The HG leg appears to work correctly (despite a python traceback somewhere deep inside the HG code). Now, the script itself seems to be exploding on the git leg. The filtered-get head's SHA is unchanged from that of the H-uru/Plasma master.

bink-fallout was intended to be a complete removal of Bink support, btw. I did that thinking plBinkPlayer.cpp and plBinkBitmap.cpp were fine to continue using. I would advise introducing a new commit somewhere that stubs out plBinkPlayer.h and plLayerBink.h.
Last edited by Hoikas on Tue Dec 11, 2012 5:05 pm, edited 1 time in total.
Image
User avatar
branan
Member
Posts: 84
Joined: Wed Apr 06, 2011 11:35 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by branan »

As soon as you have simplified scripts available for git I'll try to convert the Gehn sources
User avatar
Hoikas
Member
Posts: 344
Joined: Fri Jun 03, 2011 8:38 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Hoikas »

Branan pointed out that line 134 should contain an "= 0" as opposed to "== 0" that fixes the script, but the conversion fails.
Something unexpected happened in the conversion. H-uru/Git revision master "Merge
pull request #229 from Hoikas/locdata-strings" was expected to have id
bfd08f8bc1c33b1807caf3fe4b1edf95fa6be104, got
commit b550416622fb1539182efe4ff02cc6a891664a62
Merge: d261f2d 557bc6a
Author: Darryl Pogue <darryl@dpogue.ca>
Date: Mon Dec 3 23:18:52 2012 -0800

Merge pull request #229 from Hoikas/locdata-strings

LocalizationData String Stuff
Please compare to the published solution to figure out why, or contact Christian Walther.
Full Converted Git History

EDIT: I forked Plasma-nobink and force pushed my filtered-git repository so we can get a visual representative of what's going on.
Image
User avatar
branan
Member
Posts: 84
Joined: Wed Apr 06, 2011 11:35 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by branan »

The difference between Hoikas' and my conversions appear to be related to the generation of the hg move metadata in the commits: https://gist.github.com/37b65c069d79fc450580

I'm still trying to track down the divergence between CWalther's repo and hoikas/me. Nothing looks particularly weird about the commits where the history splits.
User avatar
branan
Member
Posts: 84
Joined: Wed Apr 06, 2011 11:35 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by branan »

Found it. Newline at the end of the commit blob isn't present on both sides. Probably we can add something to the filter-branch to normalize newlines on commit messages - I'll try to find out what git normally does (newline or not). I'm not sure why these particular commits would have that problem - it's possible they were corrupt to begin with, or were created with an ancient version of git and converted by one of our versions during the filter-branch.

Code: Select all

branmac% git cat-file -p f68b225 > branan.blob  
branmac% git cat-file -p b67e904 > cwalther.blob
branmac% diff cwalther.blob branan.blob
6c6
< Fix some casing in the CMake file paths.
---
> Fix some casing in the CMake file paths.
\ No newline at end of file

Also, removing the hg rename information gives Hoikas and I the same history. If we can't reliably generate that info I'd prefer to not include it.
User avatar
branan
Member
Posts: 84
Joined: Wed Apr 06, 2011 11:35 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by branan »

The newline issue has been resolved - it was apparently a Mac vs. Linux issue, and a workaround was found.

Some progress has been made towards figuring out the messed up hg metadata generation as well. It hopefully won't be much longer before we have a portable conversion script.
User avatar
Marten
Member
Posts: 180
Joined: Fri Dec 26, 2008 1:19 am

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Marten »

Hoikas wrote:Branan pointed out that line 134 should contain an "= 0" as opposed to "== 0" that fixes the script, but the conversion fails.
That will work in this case, though technically, "-eq 0" is more correct. Bourne shell is a very wonky thing. Use = for string comparisons (== is a bash alias to =), and use -eq for numeric comparisons.

(If you ever want to test that 01 is equal to 1, = will fail, -eq will succeed.)

The More You Know(tm)
The more you'll question whyyyyyyyyyy...
The music is reversible, but time is not.
Christian Walther
Member
Posts: 317
Joined: Sat Dec 13, 2008 10:54 am

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Christian Walther »

After some heroic battles, we have arrived at a solution that Branan, Hoikas and I can reproduce with various Git versions between 1.7.9.5 and 1.8.0 on Mac OS X, Windows, and Linux – repositories and script linked in original post updated. Only Git 1.7.2.5 on Debian Squeeze still causes differences, but we decided to live with that, as versions that work as expected appear to be readily available.

My next planned steps remain as above.
Post Reply

Return to “Management”