Page 4 of 8

Re: RAD Game Tools License Concern - Immediate Action Requir

Posted: Sun Dec 09, 2012 6:24 pm
by Christian Walther
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.

Re: RAD Game Tools License Concern - Immediate Action Requir

Posted: Sun Dec 09, 2012 6:54 pm
by rarified
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.

/

Re: RAD Game Tools License Concern - Immediate Action Requir

Posted: Sun Dec 09, 2012 9:52 pm
by Hoikas
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.

Re: RAD Game Tools License Concern - Immediate Action Requir

Posted: Sun Dec 09, 2012 10:09 pm
by Mac_Fife
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.

Re: RAD Game Tools License Concern - Immediate Action Requir

Posted: Sun Dec 09, 2012 10:15 pm
by Christian Walther
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 :).

Re: RAD Game Tools License Concern - Immediate Action Requir

Posted: Mon Dec 10, 2012 4:40 pm
by branan
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.

Re: RAD Game Tools License Concern - Immediate Action Requir

Posted: Mon Dec 10, 2012 9:12 pm
by Hoikas
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.

Re: RAD Game Tools License Concern - Immediate Action Requir

Posted: Tue Dec 11, 2012 1:43 am
by Hoikas
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.

Re: RAD Game Tools License Concern - Immediate Action Requir

Posted: Tue Dec 11, 2012 4:34 am
by Marten
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.)

Re: RAD Game Tools License Concern - Immediate Action Requir

Posted: Tue Dec 11, 2012 5:05 am
by Hoikas
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?