Warning, /kdevelop/kdevelop/plugins/subversion/Architecture.txt is written in an unsupported language. File is not indexed.

 The code length of subversion plugin seems to be very long, but it's just because
 there are many kind of actions in subversion. If we separate and investigate
 one action, the architecture is simple.
 
 1. The GUI part
 
 For each context menu item a slot is called and creates a SvnBlameJob. This
 job is then started and will do the actual work on its own. Depending on the type
 of action it fetches the results and displays them in a GUI
 
 1a. Directly using the IBasicVersionControl Interface
 
 this is no different that 1., except that there's no slot. The caller of the IBVC
 interface is responsible for starting the job, connecting to its signals, delete
 it and fetch any results to display or work with them.
 
 2. The Jobs
 Each job has an SvnInternalJob subclass that does carries out the actual action
 in a separate thread. Both are connected in various ways, using queued connections,
 to fetch additional information (like ssl certificate trust, login/password) and
 to provide the result of the job.
 
 The Job classes use VcsJob and thus KJob as parent so their progress can be monitored
 with KJob Monitors in KDE.
 
 3. InternalJob subclass
 
 Executes the action requested usually by converting the parameters into
 types that are understood by the svn C++ client API and then just executing
 a call to svn::Client::XXX. Depending on the type of action a result is converted
 back to Qt types and send via a signal to the parent job (which is the KJob subclass)
 
 The threading is done via ThreadWeaver so queueing of jobs is done instead of
 spawning a new Thread for each and every action.
 
 4. Finishing
 
 When the internaljob's run() method is exited ThreadWeaver emits an appropriate signal
 which is connected to the Job subclass. This in turn changes its state and emits
 the appropriate KJob signals by calling the KJob methods for that.
 
 If the Job class received a result it will immediately emit a resultsReady signal and
 as soon as the result is fetched via fetchResults will remove the fetched results.