Infrastructure/First Steps with your Contributor Account: Difference between revisions

From KDE Community Wiki
m (31 revisions imported)
(Replace "Contributor account" with "Developer account" for consistency)
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{warning|This page is yet to be reviewed for changes required by the migration to Git.  Information and commands on this page may no longer be valid and should be used with care. Please see the [[Development/Git|KDE Git hub page]] for more details. }}
* This page is now here: [[Infrastructure/Get_a_Contributor_Account | Get a Developer account]].  
 
* To now what to do with an account, see: [[Get_Involved#Ways_to_contribute | How to contribute]]
{{improve}}
This tutorial is about what to do when you are a fresh owner of a new contributor account for KDE.
 
== Notations ==
* ''SVN'' is used to describe an SVN server, mostly KDE's non-anonymous or anonymous SVN servers.
* The lower case word ''svn'' is used to describe the program named svn, which the user can use to access SVN.
 
== Preliminary ==
 
This tutorial assumes that you have [[Infrastructure/Get a Contributor Account|applied for a KDE Contributor account as described here]] and that you have received a positive answer with the information associated with your new account.
 
== Read First! ==
 
Now you have a KDE Contributor account.
 
Please note that the answer email will have an explanation about how to use the account. (This explanation is also the file [http://websvn.kde.org/trunk/kde-common/svn/svn_instructions.txt?view=markup kde-common/svn/svn_instructions.txt].) It contains also topics not discussed here. So please read this email.
 
In case of conflicting instructions, please follow those of the '''email''', not the ones of this tutorial.
 
== Changed URLs ==
 
Until now, you have worked with one of the anonymous servers. Now that you have a KDE Contributor account, you will not use that anonymous server anymore. Therefore the base URL to the SVN server changes for you.
 
For the standard anonymous SVN of KDE, it was: {{path|svn://anonsvn.kde.org}} assuming that you have not used an anonymous SVN mirror. If you have used another anonymous SVN server for KDE, then please use its URL instead.
 
{{Note|If you are unsure which SVN anonymous server you have used, use the <tt>svn info</tt> command to get the server URL.}}
 
Now the new base URL for your access to the KDE SVN server will be:
svn+ssh://[email protected]/home/kde
There is no need to specify a username, the server will work that out from your ssh key
 
== Changing The URLs of the Modules of Your Local SVN Copy ==
This only applies if you have local copies of SVN files that were taken from an anonymous SVN Server, otherwise skip this.
 
To use the KDE SVN server instead of one of the anonymous SVN servers, you need to tell each module of your local SVN copy that you want to change the server. SVN does this with the command
svn switch --relocate
 
Assuming that you are processing the kdelibs module, you have to use:
svn switch --relocate svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs svn+ssh://[email protected]/home/kde/trunk/KDE/kdelibs
 
For other modules than kdelibs (or for branches or for tags), you have to change the relative module path; similarly, if you used another anonymous server.
 
Be careful on what URLs you type, as SVN will only replace the exact old URL by the exact new URL. So if you mistype one of the URLs, it will not work later. (If you have already fallen into this pitfall, it is not a problem, just use relocate again to replace the wrong URL with the right one.)
 
You will be asked to accept the SSL certificate on the first attempt to access the server.
 
<syntaxhighlight lang="bash">
$ svn switch --relocate svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs svn+ssh://[email protected]/home/kde/trunk/KDE/kdelibs
The authenticity of host 'svn.kde.org (195.135.221.74)' can't be established.
RSA key fingerprint is 86:f3:66:06:20:74:81:d0:1b:b4:2f:25:03:f7:8e:fb.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'svn.kde.org,195.135.221.74' (RSA) to the list of known hosts.
</syntaxhighlight>
 
Ensure that the fingerprint matches that in the document [http://techbase.kde.org/Getting_Started/Sources/Using_Subversion_with_KDE#The_KDE_repository_structure Using Subversion with KDE]. (Normally, the SHA1 fingerprint is used for HTTPS.)
 
== First Test ==
 
The following steps are described using the command line tool <tt>svn</tt>. Personally, I find it better to start with it, as you know immediately where the problems are. Of course, after you have made your first test, you may use whatever tool that you prefer.
 
Then you should be ready to start. The best test is to try to update a small directory. So change to a (small) directory of your local copy of KDE and type: <syntaxhighlight lang="bash">svn update</syntaxhighlight>
 
Alternatively, if you have no local copies installed, you can just checkout a module.
<syntaxhighlight lang="bash">svn checkout YOUR_URL</syntaxhighlight>
Obviously, replace YOUR_URL with the correct path.
 
Now you can use the SVN commands on KDE's main SVN.
 
{{note|If you know CVS, you will perhaps wonder that there is no <tt>cvs login</tt>, Subversion has chosen not to have such a way to login. The login is done at the first connection, where authentication is needed.}}
 
== Default Editor ==
 
This section is only useful if you plan to use the <tt>svn</tt> program. If you always plan to use a GUI front-end, you can skip this section.
 
When committing, <tt>svn</tt> wants some text for commenting the commit. You can either specify it directly with the <tt>-m</tt> parameter or by a file with <tt>-F</tt> or <tt>--file</tt>. If you do neither of both, <tt>svn</tt> will run an editor to ask for a comment.
 
* TODO: improve this section
* TODO: better ask the user to modify the svn configuration files?
 
This editor is taken either from the svn configuration files or if not defined there from the environment variables: first <tt>$SVN_EDITOR</tt>, then <tt>$VISUAL</tt>, then <tt>$EDITOR</tt> depending which one is defined.
 
So maybe you should check your environment variables:
<syntaxhighlight lang="bash">
echo $SVN_EDITOR
echo $VISUAL
echo $EDITOR
</syntaxhighlight>
 
Check that their settings suit you for your work with svn. If they do not suit you, check your file {{path|~/.bashrc}} and add something like:
<syntaxhighlight lang="bash">export SVN_EDITOR=mcedit</syntaxhighlight>
Here it sets mcedit, replace it with your favorite editor. Of course you can set <tt>$EDITOR</tt> instead if you want to change the default editor for you.
 
Be careful that if you do not set a command line editor but one that needs X-Window, you will need to run svn always in a X-Window terminal. It might suit you, it might not. Your choice!
 
== Subversion Configuration ==
 
For proper of ''svn status'' and ''svn diff'' on KDE sources, you might want to follow the instructions from [http://developer.kde.org/documentation/other/developer-faq.html#q1.5.2 the developer FAQ] for setting up {{path|~/.subversion/config}}.
 
== Committing ==
 
Now a few words about how to commit.
 
First be sure that the code that you want to commit is right. If you are not certain about a patch, or have some doubts, consider perhaps sending your patch to the relevant mailing list or to the relevant developer if you know who he is.
 
Also when committing, please give a useful message with the commit. Think about what you would like to find in, say, two years. (One day, you will probably find out that meaningless commit entries like "Fix" or "Here too" are going to drive you crazy when you have to debug a problem.)
 
Good code is not always only about questions like: "Does the code compile?" The code must also fit in what is planned. For example if a new code fixes just one little bug but the maintainer of the code is currently doing a re-write, he will perhaps not be pleased that something has been committed, because he will have to fix all conflicts between the newly committed code and his new code.
 
So the best is to communicate (if possible early) to avoid any surprise. A surprised developer is highly at risk of giving a rude answer or at least not a pleasant answer. This is avoidable by communication. Of course, a developer might ask to leave the code alone. Please respect that! (Of course, it does not mean that you should not argue.)
 
== Commit-Digest ==
 
The [http://www.commit-digest.org KDE Commit-Digest] is a weekly overview of the commits to KDE's subversion server. Now that you have a SVN account, you will probably see your own name in there soon!
 
The digest features a small statistics section. To improve the accuracy of those, you should add some information, like age or country, about yourself, which you can do [http://commit-digest.org/data here].
 
== Commit-Filter ==
[http://commitfilter.kde.org/ Commit-Filter] is a service which allows you to monitor folders (or authors) in SVN for changes, and have each commit's diff emailed to you. This is very useful if you are interested in getting involved in a certain sub-project of KDE and want to keep up with its development.
 
Please use reply-to-all when responding to those emails.
 
== Links ==
 
; Subversion
: [[Getting_Started/Sources/Using_Subversion_with_KDE|Using Subversion with KDE]]
 
;i18n
:[[Development/Tutorials/Localization/i18n|What is i18n and how to use it]]
 
; I18N/L10N
: [http://developer.kde.org/documentation/library/kdeqt/kde3arch/kde-i18n-howto.html KDE Programmer's i18n howto]

Latest revision as of 13:47, 21 April 2016