RAD Game Tools License Concern - Immediate Action Required

CyanWorlds.com Engine Project Management
Christian Walther
Member
Posts: 294
Joined: Sat Dec 13, 2008 10:54 am

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Christian Walther » Sun Dec 09, 2012 6:24 pm

Progress on the history rewriting: I have now arrived at something that I think could be the final solution. I want to run some more tests on it before I commit to it, but I don’t want to make you wait any longer.

The converted CWE-ou repository is at https://bitbucket.org/cwalther/cwe-ou-nobink.
The converted H-uru/Plasma repository is at https://github.com/cwalther/Plasma-nobink.
The script that does the conversion is at https://gist.github.com/4246319.
  • The three problematic Bink files [Edit: and their headers] are eliminated.
  • A single common root for the OU fork and the H-uru fork is established, with committer name a'moaca' intact everywhere.
  • The empty .hgignore file that was in the first few OU revisions is removed, to match the first revisions of H-uru. On the H-uru side (predominantly Git used) it would only be in the way and I would have to fabricate a commit that removes it at some point, and on the OU side (predominantly Mercurial used) it is useless as long as it is empty as well, the commit that introduces real ignore rules is now simply turned from a “modify” into an “add”.
  • The corrupted merge commit that wouldn’t round-trip-convert successfully with Hg-Git is fixed.
  • Empty commits that would convert differently with Hg-Git depending on the Mercurial version are eliminated.
  • As a consequence, everything now round-trip-converts correctly with Hg-Git.
  • The second “leg” on the H-uru fork and the bridge commits on top of it, introduced to establish a common ancestor between OU and H-uru, is eliminated as it is not necessary anymore.
  • Git commits that move or rename files are annotated with rename information for Mercurial, to enable merges across them to succeed in Mercurial. This is particularly important for the move from MOULOpenSourceClientPlugin/Plasma20/Sources to Sources, where this purpose was previously served by the bridge commits now removed, but I figured it couldn’t hurt to do it in the few other cases too.
    Note: In those other cases, the rename information is not always perfect:
    • The fixed similarity threshold (75% is an experimentally found compromise) leads to some false positives as well as false negatives.
    • To exactly emulate what Mercurial would do, the rename information of a merge should be exactly the sum of the rename informations from the second parent back to the common ancestor (what happens with respect to the first parent is exactly the total of what happened up to the second parent). This is not always the case here, because sometimes in the topic branches files are modified after being moved, making them more dissimilar or more similar and causing them to rise above or drop below the similarity threshold.
    In the interest of easy complete automatability, and under the assumption that it is unlikely that anyone will actually make use of that additional rename information, I have left it that way. However, it wouldn’t be hard to replace this by a hand-tweaked perfect version, by hardcoding the hand-tweaked information in the script rather than computing it on the fly. Opinions welcome.
I would appreciate thorough reviews of this, as we (hopefully) won’t get a second opportunity to get it right. Check if you arrive at the same result by using my script, and check if file trees and commit metadata match what you expect.

While this script could in theory be used by everyone to convert their repositories, it is a hassle because it requires you to have Mercurial, Git, Hg-Git, and backups of both CWE-ou and H-uru/Plasma. Therefore my next planned step is to try to write scripts that make that easier by pulling part of the solution from the published repositories rather than constructing everything from scratch.
Last edited by Christian Walther on Tue Dec 11, 2012 1:56 pm, edited 1 time in total.

User avatar
rarified
Member
Posts: 786
Joined: Tue Dec 16, 2008 10:48 pm
Location: Colorado, US

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by rarified » Sun Dec 09, 2012 6:54 pm

An impressive list of accomplishments Christian! I can't think of anything you've missed with regards to normalizing the two SCMs. I'll look at the repository when I'm back.home this afternoon, and perhaps work on the build file fixes.

/
One of the OpenUru toolsmiths... a bookbinder.

User avatar
Hoikas
Member
Posts: 284
Joined: Fri Jun 03, 2011 8:38 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Hoikas » Sun Dec 09, 2012 9:52 pm

That looks most excellent to me; however, I think we should bite the bullet and seal the deal by filtering out plLayerBink.h, plBinkPlayer.h, and plBinkBitmap.h so that RAD will have nothing else to complain about.
Image

User avatar
Mac_Fife
Member
Posts: 1227
Joined: Fri Dec 19, 2008 12:38 am
Location: Scotland
Contact:

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Mac_Fife » Sun Dec 09, 2012 10:09 pm

On the face of it, that would seem prudent, given that RAD came back on files that were previously not considered to be a concern.
Mac_Fife
OpenUru.org wiki wrangler

Christian Walther
Member
Posts: 294
Joined: Sat Dec 13, 2008 10:54 am

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Christian Walther » Sun Dec 09, 2012 10:15 pm

That would be a trivial change to the script. I haven’t checked yet whether that would make things more difficult to get to compile again (any Bink-unrelated things defined in those headers that are used elsewhere?), but if it doesn’t, that’s fine with me.

By the way, it can’t hurt to double-check that I have actually accomplished the accomplishments I claim :).

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 » Mon Dec 10, 2012 4:40 pm

I've done a quick look over of the git version - nothing jumps out at me as horrible. I'll try to build it sometime over the next couple of days, but probably Hoikas or Deledrius would be better bets if you want it built sooner than later.

User avatar
Hoikas
Member
Posts: 284
Joined: Fri Jun 03, 2011 8:38 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Hoikas » Mon Dec 10, 2012 9:12 pm

Uhm, I already proved that compiling a filter-branch of plLayerBink.cpp won't compile. Fixing any compile issues is gonna be trivial though as we already planned on converting everything over to vp8. What CW is really interested in, I think, is ensuring that other people can arrive at the same histories. I would oblige, but I do not have an up to date backup of the cwe-ou repository.
Image

User avatar
Hoikas
Member
Posts: 284
Joined: Fri Jun 03, 2011 8:38 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Hoikas » Tue Dec 11, 2012 1:43 am

The script doesn't work for me.

Code: Select all

adamj@gehn:~/test$ sh binkbegone.sh cwe-ou Plasma
binkbegone.sh: 3: test: xcwe-ou: unexpected operator
Output files/folders exist.
OK to delete? (y/n) y
+ rm -rf old-hg uncorrupt-git uncorrupt-hg filemap1 filemap2 filtered-hg filtered-git
+ set -x
+ set -e
+ hg init old-hg
+ cd old-hg
+ hg pull -r e106bb4cef24 cwe-ou
abort: repository cwe-ou not found!
Where "cwe-ou" and "Plasma" are directories that contain the respectively named repositories.
Image

User avatar
Marten
Member
Posts: 174
Joined: Fri Dec 26, 2008 1:19 am

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Marten » Tue Dec 11, 2012 4:34 am

Re: the error on line 3... I understand == to be a bash-ism. If you're going to use bash-isms, start the script with #!/bin/bash. Otherwise, fix to a single equals sign (guaranteed compatible for string comparisons through all versions of bourne shell).

Of course, that doesn't address real problem, which is the failure to pull cwe-ou.

If cwe-ou and Plasma are sitting in the same folder as the script, perhaps the correct command might be "binkbegone.sh ../cwe-ou ../Plasma", given that the pull command is going to be run from a subdirectory of the folder that the script is located in?

(Long term, it might be slightly more intuitive if the script included the necessary "../" itself.)
The music is reversible, but time is not.

User avatar
Hoikas
Member
Posts: 284
Joined: Fri Jun 03, 2011 8:38 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Hoikas » Tue Dec 11, 2012 5:05 am

Branan pointed me in the right direction... I had to change my command to "bash ~/test/binkbegone.sh ~/test/cwe-ou ~/test/Plasma". There are a number of things I'm good at, but shell scripting is absolutely not one of them. Still, shouldn't the shebang line be #!/bin/bash?
Image

Post Reply

Return to “Management”

Who is online

Users browsing this forum: No registered users and 2 guests