Dojo HowTo -- Rolling Patches (video tute)

add1sun's picture

Hey all, I created a little video on how to roll patches the other night when I had an easy patch to do. It is not the best quality since I didn't really plan it out ahead of time but folks new to patching may find it helpful. I also wanted to show you don't have to be patching "code" but that you can also do patches for documentation. It has been added to the Patches section of the Handbook since you really should read the patch documentation and not just watch the vid. ;)

Here is a direct link to the Handbook page: Video: how to patch. We also have a torrent for it thanks to Shaal (it is 26 MB): http://www.zudeo.com/az-web/download/UQGQUZYFBXC7X2QRI6HGGF7KQ67XBKGE.to....

And, please, be kind - I do realize that the size, subtitles and general cruft are pretty awful. Just concentrate on the content. :)

Comments

In Depth & Spotless!

ambereyes's picture

Kudos!

I actually found it very helpful.

Thanks!


ambereyes.net

empty lines

snufkin's picture

yepp, nice to see it in practice indeed.
one question though: why were those empty lines left in? You said something one should only change the text. Why is that?

Stick to the issue

add1sun's picture

When you are doing a patch you only want to change the things that directly relate to the issue. Whitespace (and formatting) cleanup has nothing to do with most functional code changes. If you went through and cleaned up all of the whitespace in the file at the same time you changed some code, the patch could be very big but only have one substantive change in it. That makes is hard for people reviewing to find the meat of your patch, meaning it is less likely to get reviewed and frankly, it's just annoying. :) Another thing to keep in mind is that if your text editor is set up to automatically remove whitespace for you, then you need to turn that setting off before you do your patches or you could create a mess without intending to.

A great idea is to do the patch with just the code changes you need and submit that to your issue. Then you can go back and do a separate whitespace/formatting cleanup patch where all you do is clean up whitespace problems and put that in a new issue. I know it may sound kinda silly at first but when folks are trying to review tons of code in a day, keeping the code changes discrete to each particular issue you are addressing makes everything more efficient in the end.

Also, whitespace cleanup and general code formatting cleanup patches are a great way to dip your toe into patch rolling without being freaked about the code itself. The coder module is a great tool for even someone new to help with code cleanup. And, of course, you should also read the coding standards in the handbook too if you want to help out with cleanup.

Learn Drupal online at Drupalize.me

clear now

snufkin's picture

I see, that is a totally different perspective for me. Maybe these hints could be inserted into drupal.org/patchandiff? For those (like me), who is completely unfamiliar with large scale maintenance and patching mechanism this is a valuable information, especially since I want my patches to be accepted :) by default I just would've changed the issue, and cleaned up the code, but now i see the reason why not to.

not working those links

aespinel's picture

The link to Video is giving me a page with restricted access... Should I do something else?

The Eclipse IDE makes working

decibel.places's picture

The Eclipse IDE makes working with patches relatively simple Eclipse Help Topic Working with patches

The Subclipse plugin makes version control with SVN easy too. And there is also a Git plugin.

There are also templates you can import for hooks and other api code for D6 and D7

Drupal Dojo

Group organizers

Group events

Add to calendar

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: