Why an xml Patch file format and why unreadable patch data?

Jun 5, 2007 at 12:27 AM
Edited Jun 5, 2007 at 12:34 AM
If I might be so bold as to ask why is the format of the patch not human readable? Granted the patch itself is XML but the contents of the patch appear to be UUENCODED meaning that there is no way to actually review the patch without applying it.

Why not just use the standard diff file format for a patch instead of inventing yet another way to be different from the rest of the world?

Sorry, that might not sound fair but it's very frustrating to see MS/Codeplex inventing yet another way to do something that already has a standard way of being done. If there is actually a good design, usability reason for this it would be nice to see it explained but honestly making yet another opaque datastructure and then wrapping it in XML just seems so, well....missing the point!
Jun 5, 2007 at 2:20 AM
Because we don't have a diff/merge engine yet, we cannot send a patch file. We're actually compressing up and sending the whole file. At the point where we get a diff/merge engine, we'll consider both producing and consuming a standard patch file. You can review what's going into the patch before making it by using the status GUI. You can, of course, also take the patch file you just made and apply it to a clean copy of the source to see the results (again, you'll probably be using the status GUI so you get double-click diffing).

It's UUENCODED because it's binary data. There's no magic in there: UUDECODE it (which .NET does automatically for us), then decompress it with deflate or gzip based on what is indicated.

I know it's not ideal, but having something now is better than nothing. :)
Jun 5, 2007 at 10:40 PM

BradWilson wrote:
Because we don't have a diff/merge engine yet, we cannot send a patch file. We're actually compressing up and sending the whole file. At the point where we get a diff/merge engine, we'll consider both producing and consuming a standard patch file. You can review what's going into the patch before making it by using the status GUI. You can, of course, also take the patch file you just made and apply it to a clean copy of the source to see the results (again, you'll probably be using the status GUI so you get double-click diffing).

It's UUENCODED because it's binary data. There's no magic in there: UUDECODE it (which .NET does automatically for us), then decompress it with deflate or gzip based on what is indicated.

I know it's not ideal, but having something now is better than nothing. :)

Thanks. I agree its not ideal but it is also good to hear that you are open to producing/consuming a standard patch file. :)

I hope I did not offend. Its just with the recent Patent announcement about MS/OSS and the TestDriven.NET thing, MS seems to be doing their level best as an "organization" to drive developers away and I am afraid I was perhaps a bit more, hmm, strident, in my tone that was warranted.

Thanks again.