Hello everyone. I've been following subversion development for more than a
few months now and decided to use the Google Summer of Code to jumpstart
active involvement. I did turn in my SoC Application but feel I may have
shot myself in the foot since I did not have much time to work on it due to
school at that time. Regardless of my acceptance, I intend to work on this
project this summer (though I cannot devote as much time to it if I am not
selected).
This is the gist of my proposal for Svnserve Logging, but first some
comments.
* General Comments
How familiar should I be with the task before trying to describe it? My
design description is mostly bottom-up, looking at what changes would need
to be made and where, without completely defining what they would be since I
currently have only taken a cursory glance at the subversion code. I
described that the first task would be to gain a close understanding of it.
For future reference (and future Summers of Code), how much familiarity with
the code/project is recommended/required when writing the proposal?
* Description (taken verbatim from
http://subversion.tigris.org/project_tasks.html)
Issue #2409: Operation and error logging for svnserve
Subversion 1.3.0 added support for operational logging in mod_dav_svn. That
is, logging what actual client-side operations are performed on a
repository, rather than just logging the endless flow of WebDAV requests.
Support for this kind of logging, as well as error logging, needs to be
added to the standalone svnserve daemon. This requires some work in the APR
library, which would provide the actual logging facility.
* Detailed Design Description
As mentioned above, my design layout below is mostly just an overview, with
some questions and comments added to encourage discussion on the dev@ list
and to show I have some idea what I am talking about (hopefully). The rough
patches can be filled in as discussion occurs.
1. Understand operation of Svnserve
Other than the existing Doxygen generated documentation and inline developer
comments (and possibly in the unavailable/old design document), I do not
think there is any documentation of the design of svnserve (or of anything
else(?) except for webdav/deltav info in
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=259&expandFolder=259&folderID=254).
I need to understand it myself and I would very much like to make the
documentation/diagrams I create available to all. File formats can be
decided at a later time.
2. Logging API Design Decisions
2.a. Design Decisions
Decide if we need a logging framework (such as log4j or the Java™ Logging
APIs) or something simple. Also, if we are interested in putting logging in
the svn client as well (not that I have heard it discussed, but just
something to think about for another time), we may consider creating a more
general/reusable framework that can be used for both. Otherwise, we may get
by with something simpler.
What do we want to log? My first thought would be to define 3 types of
messages: errors, warnings, and informational. Which types do we want to log
and/or should it be configurable? Also, I would it break down into what
subsystem (for lack of a better word) is giving the message? (eg repository
access, network, etc). Should we track which subsystem gives the message and
make it configurable by the user which subsystems get logged?
2.b. Changes to existing implementation
i. Add and process arguments relating to logging passed on command line
ii. Add and process arguments relating to logging in the svnserve.conf
file
iii. Update build tests (run_tests.py and anything else?)
iv. Anything else?
3. Initial Implementation of Svnserve Logging API as text file output
a. I would assume that the log file format would match the log file output
of the Apache error log output unless a compelling reason is given.
b. Message strings and Dates/Times will need to be localized. Some (?)
error messages will be re-useable from the existing mod_dav_svn errors.
4. Platform-specific implementations of API
An added bonus but not a requirement for this project (so that failure to
complete it will not count against me). If this is wanted the design can
take this into account from the beginning. Since most operating systems have
logging capabilities (such as the Event Log in Windows and /var/log in
*nixes) we could take advantage of them (as mentioned
ttp://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=103395 and
elsewhere). I would need to update the automated tests again, with platform
specific automated tests also (are there even any right now?) and update
argument processing of svnserve to enable the ability to choose between
generic and platform specific output.
* Information about Me
4th Year Computer Engineering major at California State Polytechnic
University, Pomona. I have had an internship at a major aerospace company
for the past 4 years doing web-based database-backed applications, along
with some simulations and various tools in various programming/scripting
languages. Likes include SlashDot, BoingBoing, code refactoring, reading
novels, version controland learning anything/everything. Dislikes include
television, screaming kids, and sparse user/developer documentation.
- David Mahakian
--
Mobile Internet - E-Mail und Internet immer und überall!
GMX zum Mitnehmen: http://www.gmx.net/de/go/pocketweb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 16 03:57:14 2006