Backporting H-uru changes to OU

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

Backporting H-uru changes to OU

Post by Hoikas »

It's finally my Christmas break, so I have a bit of free time to devote to backporting some of the more valuable H-uru changes to the OU repo. I know that several of them would be greatly appreciated by the users. But, before I begin, I'd need a somewhat concise explanation of how I would go about backporting the changes to OU. Is there some hg-git magic that I need to do, should I be cherry-picking into a git branch and doing patch magic, or any other number of things? I'm no VCS expert, and I tend to forgo most all tools in favor of relying on my own abilities. In other words, I'd need a hobbyist level explanation ;)

Also I have been considering maintaining a list of patches for backporting along with the rationale and perceived level of effort in doing so. Given that I've been pretty well involved in most of the H-uru changes, this wouldn't be that difficult of a task. Is there any interest in that sort of thing from you guys?
Image
User avatar
rarified
Member
Posts: 1061
Joined: Tue Dec 16, 2008 10:48 pm
Location: Colorado, US

Re: Backporting H-uru changes to OU

Post by rarified »

Hi Hoikas,

I didn't see this till I was ready to retire so this is just a brief synopsis.

What I've done so far is to keep a Git clone of H-uru's repo, do 'git diff' for the changesets related to a particular fix, and see if that will apply to the current head revision of the OU repo. Some tweaking is to be expected (use a patch program that ignores line separator differences if you have one). Keep things in a patch format, and point me at it when ready. Then we'll make it available as a proposed change so everyone can see the diffs and comment there. When everyone is happy, we'll apply it directly to the OU repo.

There is only one Big Rule: keep each feature or fix to a separate change. If you need a separate patch for dependencies (maybe functionally unrelated to the fix) let's do the dependency separately. We'd like to test incrementally, not have to tease apart problems post-build.

Is that enough for you to start planning?

Thanks for the offer! We'd be very interested in the patch list.
_R
One of the OpenUru toolsmiths... a bookbinder.
User avatar
Hoikas
Member
Posts: 344
Joined: Fri Jun 03, 2011 8:38 pm

Re: Backporting H-uru changes to OU

Post by Hoikas »

I put together a list of patches on the wiki. I opted to only do python patches at the moment since I am ill-prepared to test any Plasma changes to the OU repositories because lack a copy of Visual Studio 2003*. In the patch list, I included some basic notes and my thoughts on how difficult merging the change will be.

I suppose that the best workflow for me will be to reset my git repository to revision e049025fb8b7cdb5487d20d8d3969e561a23a4be, which is relatively similar to MOULSCRIPT-ou b50160517f5b. From there, I'll cherry-pick, squash, and maul commits into something that will resemble clean changesets. Then, it'll be a fairly easy matter to diff, patch my own fork of MOULSCRIPT-ou, and submit a pull request.

* I am hoping to actually not need VS 2003. I have a copy of VS 2005, so perhaps I can add VS 2005 support without breaking the VS 2003 build. Or maybe I will be really lucky and VS 2005 will just work.
Image
User avatar
rarified
Member
Posts: 1061
Joined: Tue Dec 16, 2008 10:48 pm
Location: Colorado, US

Re: Backporting H-uru changes to OU

Post by rarified »

Hoikas wrote:* I am hoping to actually not need VS 2003. I have a copy of VS 2005, so perhaps I can add VS 2005 support without breaking the VS 2003 build. Or maybe I will be really lucky and VS 2005 will just work.
Would you like to use the foundry Jenkins build engine to build from your repository with VS2003 and the same tools and process we use internally? I could easily set that up for you.

_R
One of the OpenUru toolsmiths... a bookbinder.
Christian Walther
Member
Posts: 317
Joined: Sat Dec 13, 2008 10:54 am

Re: Backporting H-uru changes to OU

Post by Christian Walther »

While I have explored some of the possibilities, I have no fail-safe recipe and still need to experiment in the concrete case. All I could offer in terms of help would be to experiment together on IRC or the like.

CWE: If you don’t care about preserving commit metadata, then, as rarified says, generating patches with git diff or git format-patch and then applying them using hg import or patch may be the easiest way. I don’t remember if hg import has an option to ignore whitespace, and it can get tedious if your change touches a lot of files, because hg import will not account for moved files and you will have to patch each file explicitly. If you do care about preserving commit metadata, I would recommend using hg-git to take the revisions into Mercurial and moving them around there (while Git has more robust support for rebasing/cherry-picking, doing it in Mercurial is required because of the moved files), as mentioned in my earlier monologues. I recently did this the other way around with Skoader’s untextured avatar fix and IIRC succeeded by using hg transplant to move the revision back to the common ancestor and then hg rebase to move it forward on the other branch.

Python: The two branches (MOULSCRIPT-ou default and H-uru/moul-scripts master) have no common ancestor (although the file trees of their respective initial revisions are identical), so what you can do with Mercurial is limited. Git deals better with this situation. On the plus side, there are no indentation differences and moved files, so both the patch method (losing commit metadata) and working completely in Git (preserving commit metadata) work well.
User avatar
Hoikas
Member
Posts: 344
Joined: Fri Jun 03, 2011 8:38 pm

Re: Backporting H-uru changes to OU

Post by Hoikas »

Good post. Before I took a slight break, I tried backporting the Jalak column fix without preserving commit metadata. I found that sufficiently difficult. I will likely attempt to use hg-git once I relearn Mercurial. Git has me spoiled at this point ;)
Image
Deledrius
Member
Posts: 99
Joined: Sun Dec 28, 2008 6:29 pm

Re: Backporting H-uru changes to OU

Post by Deledrius »

Sorry I haven't gotten to this sooner! I'd like to set up the PRs for some commits and I was hoping someone (CWalther?) could help me with the best way to do it. Are the suggestions in this thread still valid? I'd like to conserve the metainformation as much as possible.

So far, I have made my own clone of CWE-ou (should it be CWE-ou-minkata instead?) on bitbucket. What is the preferred way for me to do whatever the equivalent is of cherry-picking these over into the correct OpenUru repo? What method is generally used for this currently?

Here's a list of the ones I expect are small, simple, and needed (for my reference as much as yours ;) )...


For the JPEG corruption fix:
(Original PR: https://github.com/H-uru/Plasma/pull/35)
Containing - https://github.com/Deledrius/Plasma/commit/f50bef9


For the cursor exclusivity fix:
(Original PR: https://github.com/H-uru/Plasma/pull/54)
Containing - https://github.com/Deledrius/Plasma/commit/ead1eb5
Additional Commit - https://github.com/Deledrius/Plasma/commit/eb4935d


For the incorrect client area sizing fix:
(Original PR: https://github.com/H-uru/Plasma/pull/62)
Containing - https://github.com/Deledrius/Plasma/commit/33f649a


For the potential python image crash fix:
https://github.com/H-uru/Plasma/commit/6910b4b
Note: although MOULa currently doesn't support anything aside from JPEGs, that won't stop malicious or negligent clients from uploading them, and this crash will happen as soon as someone opens a KI when they've been sent anything other than JPEG, or enter an Age with an Imager containing the same. Even an imageNode set to the existing type kNone will do this.
User avatar
rarified
Member
Posts: 1061
Joined: Tue Dec 16, 2008 10:48 pm
Location: Colorado, US

Re: Backporting H-uru changes to OU

Post by rarified »

I'd recommend cloning CWE-ou, and basing your commits from there. -ou-minkata is really a scratch repository to hold merged fixes while they are being tested on the shard. We never push back to -ou from -ou-minkata.

Since the Minkata repository is always based on a changeset from the -ou repository, it should be easy to preserve your metadata during the merge process (and when finally performing the pull operation).

_R
One of the OpenUru toolsmiths... a bookbinder.
Christian Walther
Member
Posts: 317
Joined: Sat Dec 13, 2008 10:54 am

Re: Backporting H-uru changes to OU

Post by Christian Walther »

Sure, I can help you, and talk a bit about what I’ve been doing lately to get other changes across. I do have some new experiences compared to my last post above. I have to ask for a bit of patience though – since these things will be going into the next round of Minkata testing, I would like to focus my efforts on completing the current round first, especially since a “deadline” for that has appeared now. If I forget about it by then, ping me on IRC or anywhere!

If you wait until then, that also means that you will be able to base your commits on the then-current CWE-ou head rather than the current one that will soon be very outdated when we merge all the stuff that’s currently on Minkata into it.

This list looks good, will be nice to have these things in. 8-)
Deledrius
Member
Posts: 99
Joined: Sun Dec 28, 2008 6:29 pm

Re: Backporting H-uru changes to OU

Post by Deledrius »

Christian Walther wrote:Sure, I can help you, and talk a bit about what I’ve been doing lately to get other changes across. I do have some new experiences compared to my last post above.
I thought you might, since it's been a while and you've done a lot of work since then!
Christian Walther wrote:I have to ask for a bit of patience though – since these things will be going into the next round of Minkata testing, I would like to focus my efforts on completing the current round first, especially since a “deadline” for that has appeared now.
Deadlines are the best motivators. ;)
Christian Walther wrote:If you wait until then, that also means that you will be able to base your commits on the then-current CWE-ou head rather than the current one that will soon be very outdated when we merge all the stuff that’s currently on Minkata into it.
So you're saying I should wait until after the 21st to do the work integrating them, since these are too late to make it into the current patchset staging for Cyan? That's no problem. I just had some time now and since I saw a deadline coming up I thought I should get at least these rather important crash fixes in since there's no telling when (or if) the next set might end up heading out to Cyan.
Christian Walther wrote:This list looks good, will be nice to have these things in. 8-)
Thanks, I think they're isolated enough it should be relatively simple to get them in, and tested. (Also, most of them are fairly old and well-tested already on Gehn as well)
Post Reply

Return to “Management”