Chuck Robey wrote:
> James Richard Tyrer wrote:
>> First I admire your enthusiasm. Do not take offense at my rather direct
>> engineer's analysis.
>>
>> Dotan Cohen wrote:
>>> Here is a very simple bug, that I want to learn to submit patches with:
>>> https://bugs.kde.org/show_bug.cgi?id=188383
>>>
>> I have to warn your that there have been major arguments about this
>> issue and I have rather strong opinions about it. We won't worry about
>> my opinions but expect to run into some resistance.
>>
>>> I have googled KDE Development and found lots of tutorials from KDE 2
>>> and KDE 3, and lots of tutorials about setting up what seems to be a
>>> very complex and error-prone development environment. However, as one
>>> can simply view the code online [1] I would like to work this way. I
>>> looked around the websvn tree for the file(s) that contain the string
>>> "Other Tabs" from the bug in question, but I could not find them. So I
>>> have these two questions:
>>>
>>> 1) How does one go about finding the correct file(s) to modify?
>> This is probably part of the Konqueror code:
>>
>> KDEBase:Apps:Konqueror
>>
>> in SVN. You can find the relevant files using "Find File" looking for
>> "*.*c*" with a string in: "Context::Containing Text" or use Grep
>> (command line) in Konsole.
>>
>>> 2) How does one make a diff file?
>> First, you need to checkout and build the KDEBase module from SVN:
>>
>> svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase
>>
>> Well actually, you need to install subversion, the GNU C/C++ compiler,
>> and CMake. I would suggest reading the relevant (user/client) parts of:
>>
>> http://svnbook.red-bean.com/
>>
>> Now, having found what needs to be changed:
>>
>> 1. Change it.
>> 2. Compile and install.
>> 3. Test to see that it works like you want (if not go back to #1)
>> 4. Execute: "svn status" to see that all is well
>> 5. Execute: "svn up" to see that there is no conflict
>> 6. Execute: "svn diff" to see your patch.
>> 7. If you want a patch file, Execute: "svn diff > file.diff
>> 8. Post your patch to the "kde-devel" (subscribe to it) mailing list
>> with the Subject starting with "[PATCH]" or attach the diff file to
>> the bug and label the attachment as a Patch.
>>
>> So, that is a basic outline. I expect that you might have further
>> questions.
>>
>
> Nothing you say here is wrong, but I thought it would make sense to *some* folks
> to describe one part a bit more closely (with the idea that this is gonna be
> bait for would-be coders via Google). I'm not criticizing here, please note that.
>
I intended this as a basic outline and thought that he would probably
have more questions when he actually got down to doing things.
> First, there are a group of different forms that diff can be coaxed into
> producing. They all do actually work, but some forms are easier for humans to
> read, and more obvious to catch errors in, than others forms, so a convention
> has been formed for a lot of projects (certainly, this includes FreeBSD and KDE)
> to require that all diff runs to use the "unified" form. Among other
> parameters, just include -u to diff (as opposed to -c for context type, or even
> the default kind which is the "edit" form. Both the "edit" and "context" diff
> outputs will get you yelled at (even though they work), and if you run them on
> purpose (just so you can view the outputs yourself) I think the reason that
> folks want you to use the unified diff will be obvious to you (as a human,
> supposedly...).
>
> The 2nd point which I think might be confusing is the order that you give the
> files to diff on the command line in. One is called the original, the other is
> our changed data. If you're not using a system like KDE, or FreeBSD, or
> anything that wraps your diffs for you so you are more likely to get it correct,
> then you need to worry a bit more about file order, because you're going to be
> giving the diff command directly. First, you want to have a copy of the form
> of the file you're going to be changing, before any mods go into it. My habit
> is to copy the original of any file I'm intending to modify to a file of the
> same name, but with a suffix of ".orig" Well, the the point I'm going to make
> is, that the order that you give the files to diff is very important. In KDE,
> where svn is handling your diff calls for you, you can ignore this point, but if
> other systems, the trick to remember is, to always give the file original form
> to the diff first, and after that, the modified file. You mustn't get the order
> incorrect, because if you do, "patch" is going to ask you if your patch might be
> reversed. So, if you get that response from "patch", remember you always give
> the original file first, THEN the modified file. The output is what patch has
> been created to read, directly.
I have been using the internal subversion: "svn diff" command lately
rather than the command line utility. It only has one type of output,
although you can use the diff command line utility with it -- at least
the fine manual says you can (I have never tried it).
You are correct that you need to give options when using the command
line diff utility. IIRC, "diff -Naur <old_file> <new_file>" is the
preferred form and the output file should have the extension 'patch'.
--
JRT
Linux (mostly) From Scratch
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
