Backporting H-uru changes to OU

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

Re: Backporting H-uru changes to OU

Post by Hoikas » Thu Jun 14, 2012 12:26 am

Hmm... It appears that if I strip the last build revision, the next build fails :shock:

I guess Jenkins doesn't like revisionism :/
Image

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

Re: Backporting H-uru changes to OU

Post by rarified » Thu Jun 14, 2012 12:38 am

Oops :oops:

My fault; I had a command shell open in the directory that Jenkins was trying to delete on the Windows build VM. Jenkins should be able to deal with stripping, but it recognizes the cloned repository needs to be rebuilt which is why it tried to delete it.

I got out of the way and started a new build. 8-)

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

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

Re: Backporting H-uru changes to OU

Post by Hoikas » Thu Jun 14, 2012 12:41 am

:lol:

I think I've done that a good many times... "Why isn't this directory deleting?! RAR!" and it happens to be the directory I have opened in the command prompt.
Image

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

Re: Backporting H-uru changes to OU

Post by Christian Walther » Fri Jun 15, 2012 7:48 pm

Alright, I finally managed to write about what I did to port the cursors/PNG/client resource manager from H-uru/Plasma to CWE-ou.

The first step is straightforward: pull the respective revisions from Git into Mercurial using Hg-Git. (Up to the state I needed, these converted commits are published in my Bitbucket fork. I would recommend pulling as much as possible from there rather than converting it yourself, for reasons previously mentioned.) The second step is to rebase them from their original location on the H-uru side of the commit graph onto the tip of CWE-ou, and that’s where things get more complicated.

I first tried to use hg rebase for that. Rebase works by using Mercurial’s merging machinery and therefore takes advantage of the file move information that was recorded in rev. 612e9b5921e2. However, it does not deal well with the whitespace and line ending differences, resulting in lots of merge conflicts. These could be resolved using a more capable merge tool, but they are so many that it would need to be well automated, which I did not attempt. It also asks a number of questions about “local changed <some file> which remote deleted” that I was surprised about but didn’t investigate further.

The other rebasing tool in Mercurial is hg transplant, which is more simple-minded and works by applying patches, hence not taking into account the moved files. By itself, it therefore fails as well, but it allowed me a hybrid approach of using hg transplant to transfer the commit metadata, while taking care of the commit contents myself.

To that end, I cooked up a script that reads a unified diff taken from H-uru/Plasma (from standard input or a file named on the command line) and transforms it so that it applies to CWE-ou (writing the result to standard output). The transformations it applies are:
  • prepend MOULOpenSourceClientPlugin/Plasma20/ to paths starting with Sources/
  • convert spaces to tabs
  • convert line endings from LF to CRLF.
It is used to transplant revisions one by one as follows:
  1. Update to the destination revision, make sure you have no local modifications, and preferably no unversioned files that clutter up the hg status view (the hg purge extension helps with getting rid of those).
  2. Try to transplant the revision in question:

    Code: Select all

    hg transplant <sourcerev>
    The transplant will fail due to the mismatching file paths, but it will have stashed the commit metadata somewhere we can later get it back from using hg transplant --continue.
  3. Apply the converted patch (hg import --no-commit instead of patch -p1 should work too):

    Code: Select all

    hg export <sourcerev> | hurutooupatch.py | patch -p1
    If that still fails, you need to examine the .rej file generated and compare it to the original file. The mismatch is probably due to some other H-uru change that is not in CWE-ou, e.g. uint32_tUInt32, or something else that wasn’t automatically converted by the script. Fix that by either applying the change by hand, or by saving the converted patch to a file, editing it, and applying it with patch again.
    (If you need to make substantial changes, it’s probably better to do them in a separate commit under your name, rather than misattributing them by sticking them into the ported commit that will retain the original authorship information – Mercurial does not have separate committer and author info like Git does.)
  4. Once you have cleanly applied all changes (including manual porting work like translating changes to CMakeLists.txt into changes to MSVC projects), complete the transplantation, making the commit:

    Code: Select all

    hg transplant --continue
(These examples assume a Unix shell. Trying it on Windows is left as an exercise to the reader.)

The current version of the script also contains experimental code that attempts to convert commit metadata generated by git format-patch into the format expected by hg import, but that does not work reliably yet. For now, only use it to convert diffs.

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

Re: Backporting H-uru changes to OU

Post by rarified » Fri Jun 15, 2012 8:30 pm

Awesome! Much of that I did by hand when transferring changes using patches.

Thanks!
One of the OpenUru toolsmiths... a bookbinder.

User avatar
Lyrositor
Member
Posts: 156
Joined: Sun Feb 05, 2012 10:58 pm
Contact:

Re: Backporting H-uru changes to OU

Post by Lyrositor » Sun Jun 24, 2012 7:48 pm

Rarified, if it's not too late to ask, I'd like to have choice of build type once more on the foundry. Thanks!
Lyrositor
Explorer #16601888
To D'ni, or not to D'ni. There is no question.
Image

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

Re: Backporting H-uru changes to OU

Post by rarified » Sun Jun 24, 2012 10:09 pm

Lyrositor wrote:Rarified, if it's not too late to ask, I'd like to have choice of build type once more on the foundry. Thanks!
Your build configuration has been updated to use the batch files again. You can set the build type in your build-allclient-solution.bat batch file.

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

User avatar
Lyrositor
Member
Posts: 156
Joined: Sun Feb 05, 2012 10:58 pm
Contact:

Re: Backporting H-uru changes to OU

Post by Lyrositor » Sun Jun 24, 2012 10:12 pm

Thanks.
Lyrositor
Explorer #16601888
To D'ni, or not to D'ni. There is no question.
Image

Post Reply

Return to “Management”

Who is online

Users browsing this forum: No registered users and 1 guest