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.
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.
___________________________________________________
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.
