Tomorrow we will work on it.
Happy new year to you all!
On 28 Dec 2011, at 16:45, Matthias Junker wrote:
I guess KMPProjectBuilder could be hard to test without some refactoring. It takes care
of converting the data which is loaded from the svn repository into a Kumpel model. This
is a bit complicated. I will try to explain a bit in order to get you started:
First the subversion data from the repository is loaded by using the external java
library. This is done with the class KMPProjectLoader. After loading this creates a
KMPProjectBuilder. In the build method the creation of the model is started in several
The first step is building the model for the first svn revision of which you build the
model. This is done in the method createBaseDirectoryTree. A model of the entire directory
tree of that revision is built for that revision.
After that, it incrementally builds the rest of the model using the data of the following
commits. This is done in buildFromLog. The SvnCommit and SvnChangedPath objects which are
created by the log parser exactly represent the data from the svn commit log. They are
used to build the kumpel model.
For each revision, only the delta is modeled. This is a bit more complex than it sound.
When a file or directory history is copied from another history (which also can be from
outside of the current project you are loading), another KMPProjectBuilder is created
which then loads this additional history (see buildAdditionalHistory). The information
whether a history is a copy of another history is stored in SvnChangedPath copyFromPath.
The next step is to cleanup the model. I can't remember much about this step, but it
involves cleaning up duplicated file versions which can occur when directories are
After that, the file content diffs are parsed and assigned to the file versions in the
model. This is done in parseInitialDiffs and parseRegularDiffs.
Maybe these individual phases could be refactored so that they would be testable
individually. It would be definitely be valuable to have at least one test which uses
prefetched svn data and then builds a kumpel model using the builder just as a black box
test. Testing the individual steps might be difficult at the moment, because the building
process loads all data from the filesystem and each step depends on the previous steps.
The model classes should be easy to test. I guess documenting the Builder would be a
valuable thing as well. I could assist you with that. Feel free to ask any questions you
have. I hope this helped a bit to clear things up.
2011/12/28 Felipe González <felipegmch(a)gmail.com>
I am Felipe González a student from Alexandre Bergel. I would like to understand Kumpel
and improve it's overall quality. I will be fully working on it for the next two
Here is what I can see in Kumpel:
- There's no documentation in the classes nor the tests classes
- Almost all test methods hasn't a proper method category
- There's almost no class hierarchy
- The next classes doesn't have any tests:
KMPProjectBuilder is the largest class, but it is almost not tested.
I would like to improve the coverage of Kumpel. Does it makes sense for you to write
tests for this class? Like this, I'll learn about Kumpel and hopefully be able to make
a useful contribution :)
I will put the result of my work in the repository ss3.gemstone.com/ss/CC6403-2011
I will let you know how it goes.
Felipe González Martínez
Estudiante de Ingeniería Civil en Computación
Departamento de Ciencias de la Computación
Universidad de Chile
Moose-dev mailing list
Moose-dev mailing list
Alexandre Bergel http://www.bergel.eu