Update: Corrected Typo. Create Patch is a new IntelliJ feature for their upcoming 7.0 release (for which there is an early access version available for testing.) It allows you to take a set of changes and package them up into a patch file, after which it restores each packaged file to it's original version from source control. Then, at any time, you can re-apply your effectively shelved changes by applying the patch.
This allows you to work on a large change, restore everything to its original version and work on a small change, and then go back to working on your larger change.
But, a coworker recently pointed out a more interesting use for this feature. You could work on a large change, shelve the changes, then check out a fresh build the latest version of the code, and then apply the changes, effectively patching the latest version of the code! This is amazing because the thing about large changes is, they usually take a large amount of time to work meaning an active code base becomes a moving target. The way our builds work is sometimes we can't just do an update to get the latest version (because of database upgrade issues) and we have to do a full check out and build. Applying our changes to a fresh build was always a pain because we had to painstakingly copy each file and remember where it went, and then manually merge and/or overwrite each file. What a pain that IntelliJ makes literally a breeze!
The delight is almost too much to bear...
3 comments:
Hi there,
I can understand your excitement. Especially if you lost some of your changes since the changes to the deployment vanished once you ran the build again!
TYPO : I hate to be a silly pointer but you've got a typo at the end
"he delight is almost too much to bare..."
you meant : too much to bear ?
Thank you,
BR,
~A
This sounds really cool, and I plan on checking it out (I'm in IJ 6 user), but I have a question.
How is this different than my revision control system merging any changes in when I check out the latest? Many systems I've used try and merge my local changes with the latest. Would this work better or be used in a different fashion?
Jerry
Jerry,
as I see it, the difference is that you can shelve your changes without being finished. Maybe you were half way through a huge refactor, and someone comes to you with an urgent production bug, where the needed changes are affected by your refactor.
You can shelve your refactor without breaking the build for others, and then pick it up again later.
Michael
Post a Comment