Community
Participate
Working Groups
Build 3.4M4 Would it be possible for compare to perform against an existing patch ? My usecase is that I am working on a massive patch, which takes me for days to develop. I am exporting patches frequently, and sometimes I'd like to see the difference from last patch... I don't think I can do it today. Szymon told me I could export multiple patches, then revert to HEAD, apply 1st patch again, then try to apply 2nd patch and see there the differences... This is possible, but lots of pain, also it is not as simple as comparing to HEAD today, which doesn't break my workflow (I can still be in the middle of debugging code, or running tests etc...). Really, all I want to find out is: what did I change since last time I saved the patch.
The other case is working with contributors who provide subsequent versions of a fix every couple days. It would be nice if I can compare the latest version of such a patch with the previous.
Exactly, there is always the solution of releasing patches in a branch and work from there, but this would force into releasing (think EPL licensing) already. Also, releasing/branch comparison doesn't help when working on a plane...
Assuming that both patches apply cleanly to the target, an implementation of this could use the WorkspacePatcher to determine the effects of both patches and then compare them to each other to see what the difference between the two patches are. There would still be a fair bit of work to do to implement it but we could reuse a fair amount of code fromt the Apply Patch wizard.
My usecase is that I save patches along the road, while doing my development. So at some point I have more changes in my workspace, and I'd like to see what changes were made since last time I saved a patch. I am not starting with a clean workspace, and 2 different patches (which is a different usecase to me). Think of the guy on the plane who cannot return to clean workspace, since no CVS connectivity.
Well, that about makes it about as difficult as it could be ;-) One thing you could try is to attempt to apply the previous patch and choose to reverse it. Any parts that haven't been changed will be hidden and all you'll see is that parts that have been changed. If we can improve the unmatched Hunk edited (bug 196228) that may go a long way in improving this scenario. I woudl recoomend that we focus on improving the unmatched hunk handling and then try out some secnarios using patch reversal to see how they look. Philippe, the next time you find yourself in need of this, please try reversing the patch to see how well it works for you (i.e. live scenarios always provide a better indication then those thought up by the developers).
I am not sure I would take the risk of applying reverse patches, when far from a CVS repo. Compare is a non destructive operation.
Sorry, what I meant was to open the Apply Patch wizard to preview what the effect (i.e. the wizard shows a preview and doesn't have an effect until the Finish key is pressed). I was merely suggesting that you may be able to get what you want using the existing Apply Patch wizard by opening the Apply Patch wizard to show the preview for the old patch and then enabling the Reverse patch option. The preview in the wizard would then show only those areas where the old patch could not be successfully reversed which would indicate that they were changed since the old patch was created. Anyway, I just realized that, although this would allow you to see some of the changes made since the old patch, it would miss any changes since the old patch in areas that were not touched by the old patch. This makes me think we would need to revert to what I described in comment 3. Another alternative would be to write a straight patch comparison but, of course, this wouldn't work in disconnected mode since we wouldn't be able to create the patch for the latest changes without contacting the server. Either of the cases could be made possible in disconnected mode if we cached the base contents for any modified files.
I was about to say that what I usually do is compare two patches (and not only me - see bug 210627). But what I can see from the discussion, Philippe might not be interested in doing that. First of all, he doesn't want to generate the patch, he just want to see what changed since last time the patch had been saved (comment 0). The second thing has been mentioned by Michael (comment 7): "we wouldn't be able to create the patch for the latest changes without contacting the server". At the same time we need to keep in mind that this is not an isolated issue (see bug 198149). The other kind of requests I've been seeing around is an option to create diffs from various comparisons (other than workspace vs repository). So, maybe we should use a diff mechanism which wouldn't be dependent on any connection (it would be "local"). Michael, do you think is achievable and/or reasonable? The other question is: Philippe, will this kind of comparison (the latest saved patch vs patch for the current workspace generated by the "local" diff) be helpful in your case?
It depends what you mean by achievable. I would say that to cache the base contents of all modified files and to generate diffs from that without contacting the server would take at least one milestone of work for a developer (i.e. to do the initial implementation and shake out any issues, etc). Given the current team size, that means that the implementation would need to span at least two milestones since there is always maintenance work and other things to be done during a milestone. Also, that time wouldn't include the patch comparison itself which I would put at maybe 1/2 a miletone.
Re: comment 8. Yes, I believe this is what I am looking for. Note that this is only a request for enhancement, nothing critical. I wanted to log it as an idea for the future. By no mean, did I intend to make it a 3.4 requirement.
(In reply to comment #9) I agree, that "local" diff is not a quick fix and probably we should consider some support in Resources for caching the base contents. However it would help us to solve this and some other issues that were mentioned in the comment #8. I would raise a bug for the "local" diff. Other issues, including this one, could depend on it. As Philippe said, it is not critical, however we can think about it as a good candidate for next versions.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
