We are still gathering feedback and it's an open tracker entry. Do you have any specific example files or screenshots you would like to submit for our developers to review?
Apply patch
Collapse
X
-
The best example I have is Eclipse Team/ApplyPatch
https://app.box.com/s/vrh57wrq482kmug9pbbu
If you search Google for "Applying a patch in Eclipse", there are many explanations on how to do this. I don't like the way Eclipse does this. In Eclipse, I have to import the project into Eclipse and then I have to apply the patch to the project. Also, Eclipse shows the Before (before patch) in the Left pane and the After (after patch) in the Right pane. This does not work very well if the patch does not apply cleanly. It would be much more simple to simply display the text from the patch in the left pane at lines defined in the patch. The context portion of the patch should be in a different color to the additions (+) or removals (-). I can visually see why a patch is failing to apply and then use bcompare align to fix problems. The patch file could be file based or folder based patch. If it is file based, then I would select a file in the right pane and then the standard bcompare features should apply. If the patch is folder based (contains patches from more than one file) then I would select a folder in the right pane. Again, the left pane should contain folders with file which I can open in a similar way to comparing folders.Comment
-
1) Thanks. The screenshot appears to be a broken link. Could you give a few more specific examples of how Eclipse should be changed to better meet your needs?
2) I'm afraid I'm not following your current description of what you are looking for: would the Text Compare better meet those needs to show the exact contents of the patch file?Aaron P Scooter SoftwareComment
-
If you right click on the image, you can save or open the image. I just tried it with my iPhone and it seem to work fine.
1) Patch file containing diff for one file:
One the left pane of bcompare, display the patch file as though it was a regular file, but place the text on the lines specified in the patch file. For example (I added a line number with a ] to each line of the patch file), lines 1, 2 and 3 should not be displayed. Lines 4, 5, 6, 10, 11, 15, 16 and 17 are context lines and should be displayed in say black, but positioned on line 179. Lines 7, 8, 12 and 13 should be displayed in Red (removal) and line 9 and 14 should be displayed in Green (additions). The "+" and "-" should not be displayed.
1]--- a/arch/sparc/Kconfig
2]+++ b/arch/sparc/Kconfig
3]@@ -179,12 +179,10 @@ config NR_CPUS
4] source kernel/Kconfig.hz
5]
6] config RWSEM_GENERIC_SPINLOCK
7]- bool
8]- default y if SPARC32
9]+ def_bool PREEMPT_RT_FULL
10]
11] config RWSEM_XCHGADD_ALGORITHM
12]- bool
13]- default y if SPARC64
14]+ def_bool !RWSEM_GENERIC_SPINLOCK && !PREEMPT_RT_FULL
15]
16] config GENERIC_HWEIGHT
17] bool
2) Patch file containing diff for for multiple files:
In bcompare left pane, display folders arch/alpha/mm and arch/arm. In the arch folder add file Kconfig and in the arch/alpha/mm folder add file fault.c and add Kconfig in the arch/arm folder. Double clicking on Kconfig or fault.c should be displayed as I explained in 1) above. The right pane should display to complete project folder. In this case, it is the complete Linux Kernel source code. Similar folder coloring should exist for differences. Perhaps the patch has already been applied. The patch may delete a file or add a file.
diff --git a/arch/Kconfig b/arch/Kconfig
index 80bbb8c..b5fe121a 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -6,6 +6,7 @@ config OPROFILE
tristate "OProfile system profiling"
depends on PROFILING
depends on HAVE_OPROFILE
+ depends on !PREEMPT_RT_FULL
select RING_BUFFER
select RING_BUFFER_ALLOW_SWAP
help
diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c
index 98838a0..ee01270 100644
--- a/arch/alpha/mm/fault.c
+++ b/arch/alpha/mm/fault.c
@@ -107,7 +107,7 @@ do_page_fault(unsigned long address, unsigned long mmcsr,
/* If we're in an interrupt context, or have no user context,
we must not take the fault. */
- if (!mm || in_atomic())
+ if (!mm || pagefault_disabled())
goto no_context;
#ifdef CONFIG_ALPHA_LARGE_VMALLOC
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1594945..70ceee4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -58,6 +58,7 @@ config ARM
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+ select HAVE_PREEMPT_LAZY
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_UID16Comment
-
https://app.box.com/s/s0ubrwdu6qaiot6lf09a
This is a screenshot of me trying to apply a patch using Kompare. You can see the concept but it doesn't seem to work correctly.
Here is an image I found that depicts the concept I want more clearly:
http://blog.dmaggot.org/wp-uploads/2...p_patch_ui.png
I got this image from this article:
http://blog.dmaggot.org/2012/11/patc...-for-kdevelop/
I prefer that the left pane includes all the lines and that the "context lines" line up with the right pane. If there is a "addition line" then the right pane should have a blank line and if there is a "remove line", then the right pane should display that line in red. You may have to add a "patch icon". This would work similar to the copy icon, but it would also reference line color (green would copy and red would delete lines on the right pane). Recall, the colors where derived from the "+" and "-" in the patch file.
BTW, I think you would create a temp file from the patch file and then open it in the left pane so that I can use all the editing features in bcompare.Last edited by John3909; 24-Apr-2014, 05:56 PM.Comment
-
Hello John,
Thanks for the feedback. We have an open entry to upgrade the patch interface and usability, but we won't be able to jump from what we have to handling a case like you've presented. I'll add your notes to our entry on the subject, and we'll review them as we gradually tackle and expand our Patch functionality.Aaron P Scooter SoftwareComment
-
Hi Aaron,
I understand that you guys are busy on so many fronts and you have limited resource, but is there any change we will see this feature implemented in the near future? Do you have any indication of where this feature is in your development list? If this is implemented in the same intuitive way BCompare works, I am confident you will gain a big following from the open source community, especially the Linux Kernel developers. With the number of lines of code added accelerating, merging is becoming more and more difficult to manage. BCompare will be a big time saver and will help streamline the process.
Regards,
JohnComment
Comment