Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> But instead of explaining in detail every time a
> bug is found why this happened, I suggest to simply explain the whole
> thing in the comments.
You are right. But I think, it is useful to document
specific problems and their solution in a mailing
list. After a few days, you can just google for some
keyword and get *some* first information.
I met Karl Fogel at the iX workshop last year and
he turned out to be a strong proponent for this
way of problem solution documentation.
> Yes, I know I'm not the one who should complain about the lack of
> comments - I'm guilty of the same crime. But it would really help if you
> could add some comments explaining some of the classes there.
No offense taken ;) And while I think the classes
themselves (not the methods) are explained in
the code, what is definitely missing is an overall
picture of the storage / representation scheme.
My experience is that the complexity does not
stem from the relatively simply building-block
classes themselves but from their interactions
and implicit assertions / invariants / assumptions.
> > * CStringDictionary stores unique strings and associates them with
> > an ID. The log cache uses these containers to replace string data
> > with simple integer data, i.e. it can operate on fixed-size numbers
> > (indices, tokens) instead of variable-length character streams.
>
> Where does it get the ID from, i.e., how is the unique ID generated?
*All* log caching containers store their data
in an array / vector-like data structure. New
entries will be appended and their ID is just
the index in the respective array. That is why
all IDs are of type index_t.
> CLogBatchIteratorXXX : these classes seem to be not used. What are these
> for?
Their original purpose was to construct the log
for more than one path (and to report overlapping
revisions only one). However, they have been
broken ever since and would not be used anyway.
Removed in r9994.
> CDictionaryBasedTempPath is also not documented, but at least it is used.
It was the last class I needed to get things running ;)
Short description added in r9995.
> The XML classes are AFAIK not used in TSVN but only in the test suite.
> Should be maybe remove those from the library to save a little space?
Technically, yes, we could move them to the test app.
However, this will probably not reduce the size of our
release binary (the linker will eleminate dead code
automatically).
-- Stefan^2.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Jul 8 01:10:39 2007